<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
Oliver G. schrieb: > Bitte geben Sie Vorschläge Vor der Prüfung lernen und nicht währenddessen die Fragen posten.
Ist doch schon mal ein Fortschritt. Früher bekam man einen Job als PHP-Programmierer, ohne das Wort überhaupt mal gehört zu haben.
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.
https://www.oreilly.com/library/view/adonet-in-a/0596003617/ch04s04.html (Ist SQL-Server 2008 nicht auch schon lange End-Of-Life?)
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.
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.
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
Noch besser wäre, das SQL Command in eine Stored Procedure zu legen, so ist die Abkopplung zwischen SQL Backend und Frontend Applikation perfekt.
Ε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...
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
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.
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
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)
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.