<\/p>\n
Filterausdrücke können schnell gefährlich werden, zumindest wenn Sie nicht aufpassen. Dafür sorgt die sogenannte SQL-Injection, bei der davon ausgegangen wird, dass der Benutzer einen Ausdruck in die Benutzeroberfläche eingibt, die dann als Teil eines SQL-Ausdrucks verwendet wird und Schaden anrichten könnte. Dieser Beitrag erläutert, was SQL-Injection eigentlich ist und wie Sie sich dagegen wappnen können.<\/b><\/p>\n
Die SQL-Injection ist eine Methode, aus eigentlich harmlosen SQL-Anweisungen schädliche SQL-Anweisungen zu machen – oder damit an Informationen zu gelangen, die der Benutzer normalerweise nicht erhalten sollte. Dabei ist die Voraussetzung immer ein Eingabefeld in einer Webseite oder, in diesem Falle, in einem Access-Formular, in das der Benutzer beispielsweise einen Vergleichswert für einen Vergleichsausdruck eingeben soll – im einfachsten Fall etwa die ID eines Kunden.<\/p>\n
Als Spielwiese für die folgenden Beispiele verwenden wir ein einfaches Access-Formular namens frmKunden <\/b>samt Unterformular sfmKunden<\/b>, wobei das Unterformular die Daten der Tabelle tblKunden <\/b>anzeigt und das Hauptformular ein Eingabefeld für einen Suchbegriff liefert, der zunächst die Suche nach Werten im Feld KundeID <\/b>ermöglicht (s. Bild 1).<\/p>\n
![\"Beispielformular](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_001.png\")
<\/p>\n
Bild 1: Beispielformular in der Entwurfsansicht<\/span><\/b><\/p>\n Für das Textfeld txtKundenID <\/b>legen wir die folgende Ereignisprozedur an:<\/p>\n Diese sorgt dafür, dass eine neue SQL-Anweisung zusammengestellt wird, die den Datensatz der Tabelle tblKunden <\/b>mit einem bestimmten Wert im Feld KundeID <\/b>liefert und diesen der Eigenschaft RecordSource <\/b>des Unterformular zuweist. Dies gelingt auch reibungslos, wenn der Benutzer einfach nur einen Zahlenwert eingibt (s. Bild 2).<\/p>\n Bild 2: Filtern nach dem Wert 1 im Feld KundeID<\/span><\/b><\/p>\n Was an unserer Methode soll also gefährlich sein – schließlich kann man doch nur Zahlenwerte eingeben und erhält das gewünschte Ergebnis Mitnichten: Schon die Kenntnis der Datenstruktur (oder ein wenig experimentelle Arbeit) erlauben es, ein ganz anderes Ergebnis zu erhalten als geplant. Geben Sie beispielsweise einmal den folgenden Ausdruck in das Suchfeld ein:<\/p>\n Das Ergebnis ist überraschend: Es gibt keinen Fehler, sondern es erscheinen zwei Datensätze (s. Bild 3)! Allzu verwunderlich ist dies jedoch gar nicht, denn der resultierende Ausdruck in der Variablen strSQL<\/b>, den Sie sich einfach im Debugbereich ausgeben lassen können, sieht wie folgt aus:<\/p>\n Bild 3: Erweiterung des Ergebnisses per UNION<\/span><\/b><\/p>\n Gut, der Schaden ist gering, denn wir greifen so nur auf Datensätze zu, die wir auch anderweitig hätten lesen können. Aber wenn wir keine Bedingung angeben, liefert der resultierende SQL-Ausdruck uns sogar wieder alle Datensätze:<\/p>\n Dies könnte interessant werden, wenn der eigentliche Filterausdruck noch dafür sorgt, dass beispielsweise nur die Kunden des aktuell angemeldeten Mitarbeiters angezeigt werden sollen.<\/p>\n Noch spannender wird es, wenn Sie hinter dem UNION <\/b>-Schlüsselwort nicht auf die gleiche, sondern direkt auf eine andere Tabelle zugreifen, die unter Umständen kritische Daten enthält. Im Beispiel wollen wir einfach einmal probieren, Daten aus der Tabelle tblArtikel<\/b> zusätzlich auszugeben, und testen den folgenden Suchausdruck:<\/p>\n Dies liefert im ersten Anlauf noch den Fehler aus Bild 4, weil der zweite Teil der UNION<\/b>-Abfrage nicht die gleiche Anzahl Felder wie der erste Teil zurückliefert. Aber was geschieht, wenn wir einfach ein paar fixe Werte entsprechend der Anzahl der Felder des ersten Teils der Abfrage hinzufügen – und so notfalls durch Experimentieren auf die richtige Anzahl Felder kommen So ergibt sich nach kurzem Test der folgende Ausdruck:<\/p>\n Bild 4: Fehler, wenn nicht alle Seiten der UNION-Abfrage die gleiche Anzahl Felder enthalten<\/span><\/b><\/p>\n Das Ergebnis ist einigermaßen erschreckend: Wir gelangen so tatsächlich an die Informationen der Tabelle tblArtikel<\/b>, die eigentlich gar nicht zur Datenherkunft des Unterformulars gehört (s. Bild 5). Und natürlich könnten wir diese Tabelle auch durch eine Tabelle mit wirklich sensiblen Daten wie etwa der Benutzertabelle ersetzen.<\/p>\n Bild 5: Ermitteln der Daten einer anderen Tabelle<\/span><\/b><\/p>\n So lassen sich auch leicht die Tabellen einer Datenbank ausgeben – und zwar mit diesem Suchbegriff:<\/p>\n Gibt es ebenfalls Probleme, wenn man ein Suchfeld für die Eingabe einer Zeichenkette verwendet Ja. Dazu fügen wir dem Formular ein Textfeld namens txtFirma <\/b>hinzu, das nach dem Aktualisieren die folgende Ereignisprozedur auslöst:<\/p>\n <\/p>\n Geben Sie hier etwa A* <\/b>ein, liefert dies alle Einträge der Tabelle tblKunden<\/b>, deren Feld Firma<\/b> einen Wert enthält, der mit A <\/b>beginnt. Wie können wir hier beispielsweise mit dem UNION<\/b>-Schlüsselwort auf die Daten einer zweiten Tabelle wie etwa MSysObjects <\/b>zugreifen Dazu fügen wir einfach hinter dem Vergleichswert ein schließendes Hochkomma ein und hängen die UNION<\/b>-Klausel hinten an:<\/p>\n Dies liefert uns, wie in Bild 6 zu erkennen, wie gewünscht alle Tabellennamen der Datenbank. Der resultierende SQL-Ausdruck endet nun zwar mit einem unerwünschten Hochkomma, doch das hindert Access nicht an seiner Interpretation:<\/p>\n Bild 6: Ermitteln der Daten einer anderen Tabelle, hier die Tabellennamen<\/span><\/b><\/p>\n Würde der SQL-Ausdruck wie folgt zusammengesetzt, also mit einem Sternchen am Ende, würde dies allerdings einen Fehler auslösen:<\/p>\n Der resultierende SQL-Ausdruck würde nämlich dann wie folgt aussehen:<\/p>\n Auch dies können wir jedoch umgehen, wenn wir folgenden Suchausdruck eingeben:<\/p>\n Das Ergebnis sieht dann so aus:<\/p>\n Die Einsatz eines einfachen Hochkommas muss gar nicht unbedingt in böser Absicht erfolgen, denn nicht immer dient dies dem Manipulieren einer SQL-Anweisung. Manchmal möchte der Benutzer einfach nach einem Namen wie Paul“s Boutique <\/b>suchen. Das Ergebnis unserer ungesicherten Variante können Sie in Bild 7 begutachten – Access meldet einen Syntaxfehler. Kein Wunder: Es denkt, das zweite Hochkomma hinter Paul <\/b>im folgenden Ausdruck würde den Vergleichsausdruck der Bedingung beenden. Mit den danach folgenden Zeichen s Boutique <\/b>kann es dann nichts mehr anfangen und meldet einen Fehler:<\/p>\n Bild 7: Fehler durch ein Hochkomma<\/span><\/b><\/p>\n Wenn Sie mit Auswahl- oder auch Aktionsabfragen auf die Daten eines SQL Servers zugreifen, die einen beispielsweise wie in diesem Fall per Textfeld eingegebenen Vergleichswert enthalten, kann der Benutzer damit noch viel größeren Schaden anrichten. Der SQL Server erlaubt nämlich im Gegensatz zu Access die Angabe mehrerer durch Semikolon getrennter Anweisungen. So ließen sich sogar Anweisungen einbauen, mit denen Daten (oder gar komplette Tabellen) aus der Datenbank gelöscht oder geändert oder Skripte auf dem Server ausgeführt werden. Wir wollen hier nicht ins Detail gehen, was die Möglichkeiten angeht, sondern uns lieber darum kümmern, wie Sie solche Aktionen verhindern können.<\/p>\n Es gibt verschiedene Möglichkeiten, die Wirkung der oben genannten Eingaben zu verhindern. Der Grundtenor lautet: Fügen Sie die Eingaben des Benutzers nicht ungeprüft in den SQL-Code ein. Die verschiedenen Varianten schauen wir uns nun an.<\/p>\n Wer mit Textfeldern als Vergleichskriterium arbeitet, weiß, dass es mit der Eingabe von Hochkommata zu Problemen kommen kann. Die Lösung ist denkbar einfach: Sie müssen die Hochkommata einfach „verdoppeln“, indem Sie zu jedem Hochkomma noch ein weiteres hinzufügen. Dies gelingt ganz schnell mit der Replace<\/b>-Funktion.<\/p>\n In unserem Beispiel des Textfeldes txtFirma<\/b> sieht das wie in Listing 1 aus. Wir haben den Inhalt dieses Textfeldes zunächst in die Variable strVergleichswert <\/b>geschrieben, damit die Vorgehensweise übersichtlicher wird. In der folgenden Anweisung haben wir den Inhalt von strVergleichswert <\/b>mit der Replace<\/b>-Anweisung bearbeitet, und zwar so, dass jedes Auftreten eines Hochkommas durch zwei Hochkommata ersetzt wurde. Wenn der Benutzer also Paul“s Boutique <\/b>eingeben würde, enthielte strVergleichswert <\/b>anschließend den Wert Paul““s Boutique<\/b>. Aber was gewinnen wir nun dadurch Ganz einfach: Access-SQL interpretiert die doppelten Hochkommata nun wie ein einfaches Zeichen und nicht mehr als Steuerzeichen, wie es das öffnende und schließende Zeichen einer Zeichenkette ist:<\/p>\n Listing 1: Entschärfen von Hochkommata durch „Verdoppeln“<\/span><\/b><\/p>\n Die Zeile zum Zusammenstellen der SQL-Anweisung hätten wir natürlich auch gleich wie folgt umgestalten können:<\/p>\n Hier haben wir nun das öffnende und schließende Hochkomma für das als Vergleichswert angegebene Literal durch doppelte Anführungszeichen ersetzt. Der resultierende SQL-Ausdruck sieht nun so aus (die Replace<\/b>-Funktion zum Verdoppeln des Hochkommas haben wir hier nicht benötigt):<\/p>\n In diesem Fall könnte uns der Benutzer aber wieder einen Strich durch die Rechnung machen, indem er ein Anführungszeichen in den Suchbegriff integriert. Dies würde in folgender SQL-Anweisung resultieren, die wiederum den Teil hinter dem zweiten Anführungszeichen nicht interpretieren könnte:<\/p>\n Wenn Sie also mit doppelten Anführungszeichen zur Markierung des Vergleichsausdrucks arbeiten, sollten Sie die Anführungszeichen im Suchbegriff verdoppeln – also wie zuvor die Hochkommata. Dies sieht mit Replace <\/b>dann so aus:<\/p>\n Dies wäre dann der SQL-Ausdruck mit unserem Beispielvergleichswert:<\/p>\n Wenn Sie, wie weiter oben gezeigt, einem Textvergleichswert per UNION eine weitere Abfrage hinzufügen wollen, um Werte anderer Tabellen zu ermitteln, reicht das Verdoppeln der Hochkommata als Vorbeugung bereits aus. Der Wert im Suchfeld sieht wie folgt aus:<\/p>\n Dann erhalten wir mit Verdoppeln des Hochkommas die folgende SQL-Abfrage:<\/p>\n Nun endet der Vergleichswert mit dem Feld Firma <\/b>nicht hinter A*<\/b>, sondern das Verdoppeln des Hochkommas sorgt dafür, dass dieses als Teil des Vergleichswertes interpretiert wird. Das Ergebnis der Abfrage ist nun leer, es sei denn, das Feld Firma <\/b>enthielte den Wert A*““ UNION SELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 FROM MSysObjects<\/b>, was nicht der Fall sein dürfte.<\/p>\n Weiter oben hatten wir ja auch die Möglichkeit aufgezeigt, in Access-SQL-Abfragen einfach mit UNION<\/b> weitere Abfragen an eine bestehende Abfrage anzuhängen, die einen Zahlenwert als Vergleichswert nutzt. Hier ist das Verdoppeln von Hochkommata oder Anführungszeichen im Vergleichsausdruck wie etwa im obigen Beispiel nutzlos, denn der Vergleichsausdruck enthält ja keine solchen. Hier könnten Sie bereits bei der Eingabe prüfen, ob der angegebene Wert ein Zahlenwert ist. Falls nicht, geben Sie einfach eine entsprechende Meldung aus. Dies realisieren Sie am einfachsten auf folgende Art und Weise:<\/p>\n Sollten Sie auf Nummer sicher gehen wollen, können Sie mit Parameterabfragen arbeiten. Eine solche Abfrage müssen Sie entsprechend vorbereiten, was aber auch den schönen Nebeneffekt von Performancegewinnen mit sich bringen kann.<\/p>\n Die Abfrage für das Unterformular unseres Beispiels sähe etwa wie in Bild 8 aus. Sie soll alle Felder der Tabelle tblKunden <\/b>zurückliefern, aber nur für solche Datensätze, deren Feld Firma <\/b>mit dem Wert des mit [prmFirma] <\/b>gekennzeichneten Parameters übereinstimmt.<\/p>\nPrivate Sub <\/span>txtKundenID_AfterUpdate()\r\n Dim <\/span>strSQL As String<\/span>\r\n strSQL = \"SELECT * FROM tblKunden WHERE KundeID = \" & Me!txtKundenID\r\n Me!sfmKunden.Form.RecordSource = strSQL\r\nEnd Sub<\/span><\/pre>\n![\"Filtern](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_002.png\")
<\/p>\nErgebnismenge mit UNION erweitern<\/h2>\n
1 UNION SELECT * FROM tblKunden WHERE KundeID = 10<\/pre>\n
![\"Erweiterung](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_003.png\")
<\/p>\nSELECT * FROM tblKunden WHERE KundeID = 1 \r\nUNION \r\nSELECT * FROM tblKunden WHERE KundeID = 11<\/pre>\n
SELECT * FROM tblKunden WHERE KundeID = 1 \r\nUNION \r\nSELECT * FROM tblKunden<\/pre>\n
Daten anderer Tabellen auslesen<\/h2>\n
1 UNION SELECT ArtikelID as KundeID, Artikelname as Kundencode FROM tblArtikel<\/pre>\n
![\"Fehler,](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_004.png\")
<\/p>\n1 UNION SELECT ArtikelID as KundeID, Artikelname as Kundencode, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 FROM tblArtikel<\/pre>\n
![\"Ermitteln](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_005.png\")
<\/p>\n1 UNION SELECT Name, Type , 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 FROM MSysObjects WHERE Type = 1<\/pre>\n
Gefährliche Strings<\/h2>\n
Private Sub <\/span>txtFirma_AfterUpdate()\r\n Dim <\/span>strSQL As String<\/span>\r\n strSQL = \"SELECT * FROM tblKunden WHERE Firma LIKE ''\" & Me!txtFirma & \"''\"\r\n Debug.Print<\/span> strSQL\r\n Me!sfmKunden.Form.RecordSource = strSQL\r\nEnd Sub<\/span><\/pre>\nA*'' UNION SELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 FROM MSysObjects<\/pre>\n
![\"Ermitteln](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_006.png\")
<\/p>\nSELECT * FROM tblKunden WHERE Firma LIKE ''A*''\r\nUNION\r\nSELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 \r\nFROM MSysObjects''<\/pre>\n
strSQL = \"SELECT * FROM tblKunden WHERE Firma LIKE ''\" & Me!txtFirma & \"*''\"<\/pre>\n
SELECT * FROM tblKunden WHERE Firma LIKE '''' UNION SELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 FROM MSysObjects*''<\/pre>\n
'' UNION SELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 FROM MSysObjects WHERE ''<\/pre>\n
SELECT * FROM tblKunden WHERE Firma LIKE '''' \r\nUNION \r\nSELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 \r\nFROM MSysObjects WHERE ''*''<\/pre>\n
Fehler durch unerwartete Eingaben<\/h2>\n
![\"Fehler](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_007.png\")
<\/p>\nSELECT * FROM tblKunden \r\nWHERE Firma LIKE ''Paul''s Boutique*''<\/pre>\n
Noch mehr Möglichkeiten auf dem SQL Server<\/h2>\n
Verhindern von Fehlern und Manipulationen<\/h2>\n
Hochkommata escapen<\/h2>\n
Private Sub <\/span>txtFirma_AfterUpdate()\r\n Dim <\/span>strSQL As String<\/span>\r\n Dim <\/span>strVergleichswert As String<\/span>\r\n strVergleichswert = Me!txtFirma\r\n strVergleichswert = Replace<\/span>(strVergleichswert, \"''\", \"''''\")\r\n strSQL = \"SELECT * FROM tblKunden WHERE Firma LIKE ''\" & strVergleichswert & \"*''\"\r\n Debug.Print<\/span> strSQL\r\n Me!sfmKunden.Form.RecordSource = strSQL\r\nEnd Sub<\/span><\/pre>\nSELECT * FROM tblKunden \r\nWHERE Firma LIKE ''Paul''''s Boutique*''<\/pre>\n
strSQL = \"SELECT * FROM tblKunden WHERE Firma LIKE \"\"\" & strVergleichswert & \"*\"\"\"<\/pre>\n
SELECT * FROM tblKunden \r\nWHERE Firma LIKE \"Paul''s Boutique*\"<\/pre>\n
SELECT * FROM tblKunden \r\nWHERE Firma LIKE \"Paul\"s Boutique*\"<\/pre>\n
strVergleichswert = Replace<\/span>(strVergleichswert, \"\"\"\", \"\"\"\"\"\")<\/pre>\nSELECT * FROM tblKunden \r\nWHERE Firma LIKE \"Paul\"\"s Boutique*\"<\/pre>\n
UNION-Abfragen entschärfen<\/h2>\n
A*'' UNION SELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 FROM MSysObjects<\/pre>\n
SELECT * FROM tblKunden WHERE Firma LIKE ''A*'''' \r\nUNION \r\nSELECT Name, Type, 3,4,5,6,7,8,9,10,11,12 \r\nFROM MSysObjects''<\/pre>\n
Zahlenwerte sichern<\/h2>\n
Private Sub <\/span>txtKundenID_AfterUpdate()\r\n Dim <\/span>strSQL As String<\/span>\r\n If <\/span>IsNumeric(Me!txtKundenID) Then<\/span>\r\n strSQL = \"SELECT * FROM tblKunden WHERE KundeID = \" & Me!txtKundenID\r\n Debug.Print<\/span> strSQL\r\n Me!sfmKunden.Form.RecordSource = strSQL\r\n Else<\/span>\r\n MsgBox<\/span> \"Bitte geben Sie einen Zahlenwert ein.\"\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\nMit Parametern arbeiten<\/h2>\n
![\"Abfrage](\"..\/fileadmin\/_temp_\/2017_01\/pic_1070_008.png\")
<\/p>\n