Forum: PC-Programmierung SQL-Injektion


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Oliver G. (olivergrey)


Lesenswert?

<CODE>SqlConnection con = new 
SqlConnection(ConfigurationManager.ConnectionStrings["techconn"].ToStrin 
g());

            SqlCommand com = new SqlCommand("select * from hs where ac 
between'" + TextBox1.Text + "'and '" + TextBox2.Text + "' and em='" + 
DropDownList1.SelectedItem.Text.ToString() + "'", con);

            DataTable dt = new DataTable();

            con.Open();

            SqlDataAdapter sqlDa = new SqlDataAdapter(com);

            sqlDa.Fill(dt);

            if (dt.Rows.Count > 0)
            {
                GridView1.DataSource = dt;
                GridView1.DataBind();
            }
            else
            {
                GridView1.Visible = false;
            }

            con.Close();<CODE/>

Ist dieser Code mit SQL Server 2008 sicher vor SQL-Injection?

Bitte geben Sie Vorschläge

von Jan H. (j_hansen)


Lesenswert?

Oliver G. schrieb:
> Bitte geben Sie Vorschläge

Vor der Prüfung lernen und nicht währenddessen die Fragen posten.

von JJ (Gast)


Lesenswert?

Oliver G. schrieb:
> n'" + TextBox1.Text + "'and '" + TextBox2.Text + "'

Nein

von Horst G. (horst_g532)


Lesenswert?

JJ schrieb:
> Nein

Ja.

von IUnknown (Gast)


Lesenswert?

Ist er nicht, da der Angreifer die Query kontrolliert

von Stefan S. (chiefeinherjar)


Lesenswert?

Horst G. schrieb:
> JJ schrieb:
>
>> Nein
>
> Ja.

Nein! Doch! Ohhhh!

von Rainer Z. (netzbeschmutzer)


Lesenswert?

Zu spät. 16.00 h. Der Kandidat hat das leere Heft abgegeben.

von Noch ein Kommentar (Gast)


Lesenswert?

Ist doch schon mal ein Fortschritt. Früher bekam man einen Job als 
PHP-Programmierer, ohne das Wort überhaupt mal gehört zu haben.

von imonbln (Gast)


Lesenswert?

Sowohl TextBox1.Text als auch TextBox2.Text sind User kontrollierte 
Eingaben. Ich würde in TextBox1.Text meine Injection packen. Ergo ja SQL 
Injection ist möglich.

Versuche doch einfach selbst mal da eine Injection zu machen das schult 
am besten zum Beispiel könntest du
1
gültiger Ausdruck ' OR 1=1 --

versuchen in TextBox1.Text einzugeben.

von hurzilein (Gast)


Lesenswert?

siehe auch :
https://xkcd.com/327/

von bluppdidupp (Gast)


Lesenswert?

https://www.oreilly.com/library/view/adonet-in-a/0596003617/ch04s04.html

(Ist SQL-Server 2008 nicht auch schon lange End-Of-Life?)

von c-hater (Gast)


Lesenswert?

bluppdidupp schrieb:

> (Ist SQL-Server 2008 nicht auch schon lange End-Of-Life?)

Das interessiert echt kein Schwein. KEIN SQL-Server ist von Hause aus 
gegen SQL-Injection gefeit. Das liegt schlicht daran, dass die Anweisung 
der Injection im Kern völlig LEGALEN SQL-Code darstellt. Der macht 
halt nur Sachen, die der Betreiber des Servers eigentlich nicht zulassen 
möchte, die aber mit den Rechten des Benutzers möglich sind. (Mindestens 
dies, wenn dann auch noch tatsächliche Sicherheitslücken des Servers 
in's Spiel kommen, kann das noch weiter eskalieren.)

Sprich: der Server selber kann und darf das nicht verhindern, denn das 
würde bedeuten, dass er die eigene Sprache nur noch unvollständig 
umzusetzen bereit ist. Er wäre dann schlicht kaputt.

Also muss es die Anwendung richten und alles potentiell Gefährliche aus 
der Benutzereingabe "ausfiltern". Wobei hier mit Ausfiltern gemeint ist: 
Wenn's verdächtig ist, wird die Eingabe schlicht im Ganzen verworfen. 
Das hält die Filter relativ einfach.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Man kann auch einfach alles escapen, was der Benutzer in die Datenbank 
eingeben könnte, dann ist das ebenfalls sicher. Nur vergessen darf man 
halt nichts, man muß bei jeder Abfrage überlegen welche Variablen ein 
Angreifer verändern könnte und welche nicht, im Zweifel alles escapen.

von Εrnst B. (ernst)


Lesenswert?

Ben B. schrieb:
> Man kann auch einfach alles escapen, was der Benutzer in die Datenbank
> eingeben könnte, dann ist das ebenfalls sicher.

Auch nur eine Krücke.
Besser ist es, das SQL-Kommando sauber von den Daten zu trennen.
Hat zwei Vorteile: Ist Sichererer und Schnellerer.

Um beim Code des TE zu bleiben:
1
SqlCommand com = new SqlCommand("select * from hs where ac 
2
between @von and @bis and em=@em", con);
3
com.Parameters.AddWithValue("@von",TextBox1.Text);
4
com.Parameters.AddWithValue("@bis",TextBox2.Text);
5
com.Parameters.AddWithValue("@em",DropDownList1.SelectedItem.Text.ToString());

: Bearbeitet durch User
von Guest (Gast)


Lesenswert?

Noch besser wäre, das SQL Command in eine Stored Procedure zu legen, so 
ist die Abkopplung zwischen SQL Backend und Frontend Applikation 
perfekt.

von c-hater (Gast)


Lesenswert?

Εrnst B. schrieb:

> Besser ist es, das SQL-Kommando sauber von den Daten zu trennen.

Du hast das Konzept einer SQL-Injection offensichtlich nicht wirklich 
verstanden. Das beruht im Wesentlichen darauf, in den "Daten" etwas zu 
übergeben, was so tricky konstruiert ist, das es einerseits wie legale 
Daten aussieht, andererseits aber letztlich zum SQL-Kommando wird.

Ich weiß nicht, was diese "AddWithValue"-Methode im Detail tut. 
Vielleicht enthält sie ja einen Filter, der das verhindert. Vielleicht 
aber auch nicht...

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Solche Konstrukte verhindern, daß Daten wie SQL-Anweisungen behandelt 
werden. Ich hatte überlegt ob ich das mit reinschreiben soll, hab es 
dann aber gelassen weil es kein eigentliches SQL-Statement mehr ist, 
sondern bereits ein halbes Programm. Und für schneller halte ich es 
angesichts des gesteigerten Overheads auch nicht.

: Bearbeitet durch User
von Εrnst B. (ernst)


Lesenswert?

c-hater schrieb:
> Ich weiß nicht, was diese "AddWithValue"-Methode im Detail tut.

solltest du nachsehen.

Ben B. schrieb:
> Und für schneller halte ich es
> angesichts des gesteigerten Overheads auch nicht.

Ist zum einen schneller, weil die Datenbank weniger SQL zu parsen hat. 
Alles was an Daten übergeben wird, muss nicht durch den SQL-Parser.
Spart u.U. auch z.B. {json, xml, blob, ...}->TEXT->{json, xml, blob, 
...} Wandlungen, weil komplexe Datenstrukturen ohne Konvertierung in 
SQL-tauglichen Plain-Text direkt binär übertragen werden.

Zum weiteren kann die Datenbank (keine Ahnung ob das der MS-SQL macht, 
aber andere können das) sich einmal eine Execution Strategy für die 
Query zurechtlegen, und diese recyclen, wenn dieselbe Query (mit anderen 
Daten in den Params) neu ausgeführt wird.

Macht bei solchen Popel-Beispielen keinen Unterschied, bei großen 
Datenmengen und vielen Queries durchaus.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Müsste man glatt mal ausprobieren und wahrscheinlich kommt das auch auf 
die SQL-Engine an. Die optimieren da eine ganze Menge bevor sie die 
Aktion ausführen, aber aus Sicht eines Programms ist es wesentlich 
schneller, eine einzige Textzeile an den SQL-Server zu schicken anstatt 
da in mehreren Schritten vorzubereiten, Platzhalter durch Daten 
auszutauschen und die Anforderung erst dann abzuschicken, was auch 
wieder nur eine Textzeile an den SQL-Server ist.

: Bearbeitet durch User
von bluppdidupp (Gast)


Lesenswert?

Ben B. schrieb:
> da in mehreren Schritten vorzubereiten, Platzhalter durch Daten
> auszutauschen und die Anforderung erst dann abzuschicken, was auch
> wieder nur eine Textzeile an den SQL-Server ist.

Das clientseitige Austauschen passiert teilweise gerade nicht*:
Beides wird (ohne Escaping) direkt nacheinander/getrennt übertragen.
Der Parser in der DB hat dadurch minimal weniger Aufwand, weil er u.a. 
bei den Parametern nichts unescapen muss und die DB kann das 
Parser-Ergebnis oder gar den Query-Plan für gleiche SQL-Queries mit 
jeweils anderen Parametern außerdem auch direkt wiederverwenden. Zudem 
werden auch direkt die Datentypen der Parameter schon vom Client 
mitgegeben.

Bei uns auf der Arbeit ist es Policy immer parametrisierte SQL-Queries 
zu verwenden, wenn mal irgendwo direkt ein SQL-Query erzeugt wird.
Reines Escaping/Quoting reicht teils auch Pentestern nicht mehr / wird 
angemeckert.

(*allerdings stark abhängig davon was der jeweilige DB-Treiber und DB 
können)

von SQL (Gast)


Lesenswert?

c-hater schrieb:
> Εrnst B. schrieb:
>
>> Besser ist es, das SQL-Kommando sauber von den Daten zu trennen.
>
> Du hast das Konzept einer SQL-Injection offensichtlich nicht wirklich
> verstanden. Das beruht im Wesentlichen darauf, in den "Daten" etwas zu
> übergeben, was so tricky konstruiert ist, das es einerseits wie legale
> Daten aussieht, andererseits aber letztlich zum SQL-Kommando wird.
>
> Ich weiß nicht, was diese "AddWithValue"-Methode im Detail tut.
> Vielleicht enthält sie ja einen Filter, der das verhindert. Vielleicht
> aber auch nicht...

Schon mal was von einem „Prepared Statement“ gehört??

Stimmt, ist ja SQL und nicht Assembler.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.