' in Strings

[Henri van de Velde]

Moin moin,

Ich muss eine Firebird-Datenbank in eine SQLCE-Datenbank überführen.

ich mache das mit folgendem (Ausschnitt) Code :

            while (dr.Read())
            {
                lfdnr++;  // Primary Key


                ce_CMD.CommandText = "Insert into ce_Artikel (lfdnr,artnr,artbez,EAN,gezaehlt) values ("
                + lfdnr.ToString() + ","
                + "'" + dr["Artnr"].ToString() + "',"
                + "'" + dr["ArtBez"].ToString() + "',"
                + "'" + dr["EAN"].ToString() + "',0)";
                try
                {
                    ce_CMD.ExecuteNonQuery();
                }
                catch (Exception)
                {
                    MessageBox.Show(ce_CMD.CommandText.ToString());
                }
                pgb.Value = lfdnr;
            }

Wenn nun aber in der Spalte ArtBez ein ' vorkommt gibt es eine Exception.
Weiss jemand wie man dieses Problem lösen kann ??

[robert.oh.]

Hallo,

Du koenntest in diesem Fall eventuell vorhandene ['] in den Strings mit [''] ersetzen - also verdoppeln; somit sind sie fuer SQL gueltig.

Dein Command koennte dann zB so ausschauen:

...CommandText = "INSERT INTO ... " + dr["ArtNr"].ToString().Replace("'", "''") + " ... "

[Henri van de Velde]

Danke, das geht so. Allerdings schmeiß ich die ' ganz raus, weil eine Artikelbezeichnung Fritz"s nicht so gut aussieht.

[Bernhard Geyer]

Die einzig sinnvolle Lösung ist die verwendung von parametrisierten Abfragen um das SQL Injection

Kein wunder das MS vor Angriffen per SQL Injection warnen muss wenn man fast alle Beispiel so aufbaut.

[Henri van de Velde]

Die einzig sinnvolle Lösung ist die verwendung von parametrisierten Abfragen um das SQL Injection
.

Würde ich ja machen, wenn denn benutzbare Beispiele auf der MS-Seite zu finden wären. Wenn man vom C++Builder und den IBX-Komponenten kommt, ist es sehr mühsam ADO.NET zu verstehen.

Kein wunder das MS vor Angriffen per SQL Injection warnen muss wenn man fast alle Beispiel so aufbaut
Das war kein Beispiel, sonder der einzige Weg den ich gefunden habe.

[robert.oh.]

Beispiel fuer Code mit SqlParameter:

System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand();
cmd.CommandText = "INSERT INTO table (artnr, artbez) VALUES (@parameter1, @parameter2)";
cmd.Parameters.AddWithValue("@parameter1", dr["ArtNr"]);
cmd.Parameters.AddWithValue("@parameter2", dr["ArtBez"]);
cmd.ExecuteNonQuery();

[Bernhard Geyer]

Das war kein Beispiel, sonder der einzige Weg den ich gefunden habe.

Deshalb sind auch im Gegensatz zu Javalösungen ASP.NET-Lösungen oft Anfällig für Angriffe wenn man Dokumentationstechnisch seine Hausaufgaben nicht macht.

[Henri van de Velde]

Beispiel fuer Code mit SqlParameter:

System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand();

while (irgendwas)
{
cmd.CommandText = "INSERT INTO table (artnr, artbez) VALUES (@parameter1, @parameter2)";
   cmd.Parameters.AddWithValue("@parameter1", dr["ArtNr"]);
   cmd.Parameters.AddWithValue("@parameter2", dr["ArtBez"]);
   cmd.ExecuteNonQuery();
   cmd.Parameters.Clear ();
}

Tausend Dank.
Wenn das ganze in einer Schleife laufen soll, muss man am Ende
noch

cmd.Parameters.Clear ();

anhängen.

[Henri van de Velde]

Deshalb sind auch im Gegensatz zu Javalösungen ASP.NET-Lösungen oft Anfällig für Angriffe wenn man Dokumentationstechnisch seine Hausaufgaben nicht macht.

Verstehe ich nicht

[Bernhard Geyer]

Verstehe ich nicht

Wenn du nicht weisst das das ".NET übliche" zusammenbauen von SQL-Strings gefährlich ist, wieso sollte man es nicht verwenden. AFAIK wird in der Sun/Java-Doku an allen möglichen Stellen auf diese Gefahr hingewiesen.

[Henri van de Velde]

Momentan weiss ich noch nichteinmal was .NET üblich ist.
Das ganze ist ohnehin eine Application für WindowsCE, da sind Angriffe von aussen wohl eher selten

[Bernhard Geyer]

Momentan weiss ich noch nichteinmal was .NET üblich ist.

SQL-Injection ist unabhängig von der eingesetzten Technik?

Das ganze ist ohnehin eine Application für WindowsCE, da sind Angriffe von aussen wohl eher selten

Da CE oft auf Smarphones mit Mobilteil läuft ist CE eine der zielplattformen der Zukunft für Viren. Schön mal per SMS/Bluetooth oder sonstige offene Programmierschnittstellen eingebrochen und mal schnell ein paar Premium-SMS oder 0900-Nummern angerufen und wieder gelöscht. Bis die Nummer gesperrt ist sind teile der aufgelaufenen Kosten schon auf den Bahamas oder in Russland angekommen.