Web-Application- und E-Business-Security - SQL Injection

SQL Injections

Einleitung

Ich wurde vor einigen Jahren zu einem verdächtigen Fall von immer wieder verschwindenden Daten gerufen. Die zugrundeliegende Datenbank basierte auf mySQL (mittlerweile im Besitz von Oracle), aus einer der Tabellen verschwanden zu bestimmten Zeiten immer wieder Einträge. Zunächst wurden Hacker vermutet, die auf die Tabelle Zugriff erlangt haben könnten, doch die Auswertung der Protokolle der Firewall ergab keine Hinweise darauf. Somit musste der Fehler intern zu suchen sein, vielleicht bei privilegierten Mitarbeiter*innen, die dem Unternehmen schaden wollten. Eine genauere Analyse ergab, dass die Löschungen immer mit administrativen Privilegien erfolgten, die diese NutzerInnen nicht hatten. Eher zufällig saß ich dann bei einem der Administratoren, die die Datenbank über phpMyAdmin – einer Weboberfläche, die wie schon der Name suggeriert auf php basiert – verwalteten. Wenn Sie nun einen Angriff über php vermuten, dann muss ich sie enttäuschen, der wahre Grund war noch skurriler, denn der Administrator hatte den Link zu phpMyAdmin als Favorit abgespeichert und dabei nicht bedacht, dass man in der URL auch Parameter übergeben kann. In dem Fall war dies eine Löschanfrage in einer bestimmten Tabelle. Der Administrator hatte also bei jedem Aufruf von phpMyAdmin aus seinen Favoriten im Browser die Löschung selbst durchgeführt. Was lernen wir daraus: Angriffe können über die skurrilsten Wege erfolgen. Im ersten Moment klingt dieser Angriffsvektor eher einzigartig, doch eine ähnliche Vorgehensweise wird auch bei Cross-Site-Request-Forgery (CSRF) verwendet.

SQL Grundlagen

Ich setze an dieser Stelle das Grundlagenwissen von SQL voraus. Sollten Sie also den folgenden Cartoon nicht verstehen, dann würde ich dringend empfehlen, Ihr SQL Grundlagenwissen aufzufrischen.

SQL Cartoon c by xkcd

Gute Quellen zu SQL Grundlagen gibt es viele, einige davon sind im Internet frei verfügbar. Als Beispiel seien hier die SQL Grundlagen[20] der Wikibooks genannt. Ich empfehle die genannten Beispiele auch in der Praxis zu üben. Dies kann über eine einfache lokale Installation einer SQL Variante erfolgen. Die Beispiele in diesem Studienheft wurden in der aktuellen mySQL Version 8 (in der Community Edition noch immer ohne Kosten und ohne Registrierung erhältlich) geschrieben. Alternativ gibt es auch kostenfreie Zugänge zu diversen Online-Datenbanken wie MariaDB[21]. Weiters lohnt auch ein Blick in die Referenzen der SQL Sprache, denn hier sind oft Hinweise auf mögliche Angriffsvektoren zu finden. Als Beispiel hier die Abfrage SELECT:

SELECT
    [ALL | DISTINCT | DISTINCTROW ]
      [HIGH_PRIORITY]
      [STRAIGHT_JOIN]
      [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
      SQL_NO_CACHE [SQL_CALC_FOUND_ROWS]
    select_expr [, select_expr ...]
    [FROM table_references
      [PARTITION partition_list]
    [WHERE where_condition]
    [GROUP BY {col_name | expr | position}, ... [WITH ROLLUP]]
    [HAVING where_condition]
    [WINDOW window_name AS (window_spec)
        [, window_name AS (window_spec)] ...]
    [ORDER BY {col_name | expr | position}
      [ASC | DESC], ... [WITH ROLLUP]]
    [LIMIT {[offset,] row_count | row_count OFFSET offset}]
    [INTO OUTFILE 'file_name'
        [CHARACTER SET charset_name]
        export_options
      | INTO DUMPFILE 'file_name'
      | INTO var_name [, var_name]]
    [FOR {UPDATE | SHARE} [OF tbl_name [, tbl_name] ...] [NOWAIT | SKIP LOCKED] 
      | LOCK IN SHARE MODE]][22]

Testumgebung

Wie schon in der Einleitung erwähnt finden sich im Internet zahlreiche Möglichkeiten das theoretische Wissen auch in der Praxis zu überprüfen. Da sich unsere Vorlesung sehr stark an der OWASP orientiert, verwenden wir in weiterer Folge das Tool bWApp, ein Projekt aus dem Jahr 2014, dass man als virtuelle Maschine oder in einer klassischen XAMPP oder LAMP realisieren kann. Der Vorteil einer virtuellen Maschine ist die klare Trennung vom realen Betriebssystem und die Möglichkeit Snapshots zu erstellen. Hierzu kann man sich eine fertig konfigurierte virtuelle Maschine mit Ubuntu als Basis herunterladen und diese auf einem lokalen Rechner (im Falle des Autors mit VMware Workstation , kostenfreie Alternativen wie Oracle VirtualBox eignen sich ebenso) laufen lassen. Die folgende Abbildung zeigt den Ubuntu Startbildschirm des Images. Die folgenden Beispiele beruhen alle auf diesem virtuellen Image.

PlatzhStartbildschirm des bWApp Images in VMwarealter

Funktionsweise einer SQL Injection

Beispiel 1:

Eine einfache Abfrage einer BenutzerInnen-Tabelle könnte folgendermaßen aussehen:

SELECT * FROM Users WHERE UserId = 105;

Sehen wir uns diese einfache Abfrage in wenig genauer an:

• SELECT zählt zu den Daten-Manipulations-Statements und dient primär der Auswahl
• * steht hier dafür, dass alle Felder der Tabelle User ausgewählt werden
• FROM gehört zum Statement SELECT, ist nicht zwingend nötig beschreibt aber die Auswahl der entsprechenden Tabellen
• WHERE spezifiziert aus dem Statement SELECT eine Bedingung, die erfüllt werden muss, in dem Fall UserId=105
• ; Das Semikolon schließt den Befehl ab (wäre in mySQL nicht zwingend nötig)

Vereinfacht gesagt wird der User mit der ID 105 ausgewählt. In der Praxis könnte die Programmierung einer Userabfrage aussehen wie folgt:

txtUserId = $_POST["UserId"];
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

In dem Fall wird via PHP ein Formularfeld ausgelesen und an die SQL Anfrage angehängt. Wenn man nun {105} (zur Erinnerung: die geschwungene Klammer markiert nur den Beginn und das Ende der Eingabe und wird selbst nicht geschrieben) eingibt, dann entsteht die obenstehende SQL Abfrage. Was könnte man noch eingeben? Probieren wir es mit {105 OR 1=1}. Wie sieht nun das SQL Statement aus?

SELECT * FROM Users WHERE UserId = 105 OR 1=1;

Die Abfrage wurde um den logischen „Oder“ Operator ergänzt. Da 1=1 immer WAHR ist, wird die Abfrage ALLE NutzerInnen auslesen und wir haben erfolgreich die erste SQL Injection durchgeführt.

Beispiel 2:

Wir erweitern jetzt das erste Beispiel um die Abfrage eines Zugangs zu einer Website. Dazu benötigt man in der Regel den Benutzernamen und das Passwort. Abgebildet in einer (symbolischen) PHP Lösung wäre das:

txtName = $_POST ["username"];
txtPass = $_POST ["userpassword"];
txtSQL = 'SELECT * FROM Users WHERE Name ="' + uName + '" AND Pass ="' + uPass + '"'

Falls Sie sich jetzt wundern, warum bei der einen Abfrage ‘ und bei der zweiten Abfrage verwendet werden, dann liegt das daran, dass PHP sowohl Anführungszeichen () als auch die so genannten Hochkommata (’) als Markierung für Text akzeptiert. Das liegt unter anderem auch daran, dass man auch in Texten beide Zeichen verwenden können soll. Was in der obigen Abfrage also wie drei Striche aussieht, ist ein Anführungszeichen gefolgt von einem Hochkomma. Textverarbeitungsprogramme unterscheiden zusätzlich noch zwischen unteren und oberen Anführungszeichen. Diese werden je nach SQL Engine meist als doppelte Anführungszeichen interpretiert, obwohl sie ein anderes Zeichen darstellen. (Unicode 201E bzw. 201C, das simple hat Unicode 0022). Geben wir als User adminund als Passwort ein, so wird aus der Abfrage:

SELECT * FROM Users WHERE Name ="admin" AND Pass ="123456"'

Geben wir nun beim Passwort {or =} ein, so wird aus der Abfrage:

SELECT * FROM Users WHERE Name ="admin" AND Pass ="" or ""=""

Es wird also nach dem Namen {admin} gesucht, gefolgt von einem AND (AND hat Vorrang vor OR, die beiden Teile links und rechts von AND müssten also beide WAHR sein, deshalb würde der Trick auch nicht mit der Eingabe beim Usernamen funktionieren). Danach wird leeres Passwort gesucht {} und es folgt ein OR dass ein Anführungszeichen mit einem weiteren Anführungszeichen verglicht { =}. Da die beiden Zeichen natürlich gleich sind, ist es nun auch egal was der vordere Teil der Abfrage liefert, sie wird immer WAHR sein. Setzt man dies nun bei beiden Feldern ein, so werden alle Zeilen der Tabelle zurückgegeben.

Beispiel 3:

Nehmen wir erneut Beispiel 1:

txtUserId = $_POST["UserId"];
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;

und geben in der Abfrage nun {105; DROP TABLE accounting; } ein. Das ergibt:

SELECT * FROM Users WHERE UserId = 105; DROP TABLE accounting;

MySQL wird (eine Berechtigung des Users zum Löschen vorausgesetzt) brav die Tabelle accounting löschen, da mehrere SQL Befehle mit dem Semikolon {;} getrennt werden können.

Praxisbeispiel 1

Wagen wir uns nun an unser erstes reales Beispiel heran und rufen in unserem virtuellen Image die Seite SQL Injection (GET/Search) auf. Sucht man nun ohne Parameter, so werden alle Filme der Datenbank ausgegeben.

bWApp SQL Injection Ablauf - 1

Sieht man sich die URL der Seite genauer an, so kann man erkennen, dass die Parameter in der URL übergeben werden. (Aufmerksame Leser*Innen werden sich an meine Schilderung der Administration via phpMyAdmin erinnern).

http://xxx/ sqli_1.php?title=&action=search

Offenbar gibt es eine Variable „title“ die in dem Fall leer ist. Wir haben in Beispiel 2 schon gelernt, dass Anführungszeichen eine Textabfrage beenden können, also probieren wir einfach ein Anführungszeichen {’}. Die folgende Abbildung zeigt das Ergebnis, mySQL sagt uns netterweise an welcher Stelle der Fehler ist (beim Anführungszeichen – man erkennt es in der Fehlermeldung relativ schlecht, da die Fehlermeldung zwei Anführungszeichen hintereinander ausgibt).

bWApp SQL Injection Ablauf - 2

Was auf den ersten Blick her schlecht erscheint ist in Wahrheit ein untrügerisches Zeichen, dass die Anwendung anfällig auf SQL Injections ist. Nun probieren wir im nächsten Schritt die Zeichenfolge {’ OR 1=1-- }. Wieder liefert das System alle Datensätze, da ja 1=1 immer WAHR ist. An dieser Stelle ist noch anzumerken, dass der Abschluss des Befehls das Aussehen von zwei Minuszeichen gefolgt von einem Leerzeichen enthält. Das hat den Hintergrund, dass in mySQL Kommentare mit einem doppelten Minus und mindestens einem Leerzeichen {-- } oder mit einem Hashtag {#} beginnen. Der Kommentar gilt dann immer bis zum Ende der Zeile. Das Ziel dieser Zeichenkombination ist also das Abschneiden etwaiger folgender SQL Anweisungen wie weitere AND Verknüpfungen. Als nächster Schritt wäre es interessant auch auf andere Tabellen zugreifen zu können. Hier hilft der SQL Befehl UNION. Wir geben also ein {X’ UNION SELECT 1--}. Das {X} ist hier nur ein willkürlicher Platzhalter für den echten Suchbegriff. Dies resultiert in einer Fehlermeldung, wie folgende Abbildung zeigt.

bWApp SQL Injection Ablauf - 3

Der Fehler liegt darin, dass UNION eine gleiche Anzahl an Spalten erwartet, wir werden diese also schrittweise erhöhen. Achtet man auf die Beschriftung der Spalten in der Ausgabe, so kann man von mindestens 5 Spalten und vermutlich einem Primärschlüssel ausgehen, was dem Resultat nahekommt, nämlich 7 Spalten. Die korrekte Abfrage lautet also: {X’ UNION SELECT 1,1,1,1,1,1,1-- }

bWApp SQL Injection Ablauf - 4

Da wir nun die korrekte Anzahl der Spalten kennen ist es möglich die einzelnen Spalten für Abfragen zu nutzen, beispielsweise nach dem Datenbanknamen: {X’ UNION SELECT 1,DATABASE(),1,1,1,1,1-- }. Hierbei muss man darauf achten, dass die Abfrage auch angezeigt wird – daher die Abfrage erst an der zweiten und nicht an der ersten Spalte. Das Ergebnis zeigt die folgende Abbildung.

bWApp SQL Injection Ablauf - 5

Hier erkennt man den Namen der Datenbank. Um nun auch die Tabellen auszulesen reicht eine einfache Abfrage: {X’ union select 1,table_name,1,1,1,1,1 from INFORMATION_SCHEMA.TABLES where table_schema=‘bwapp‘--}. Wir suchen also im INFORMATION_SCHEMA , das ist der Platz an dem mySQL Metadaten über verwendete Tabellennamen oder BenutzerInnen-Privilegien ablegt. Das Ergebnis in der folgenden Abbildung zeigt die zugehörigen Tabellen.

bWApp SQL Injection Ablauf - 6

Als Hacker wird man sich zunächst auf die User-Tabelle konzentrieren. Das erreicht man leicht mit: {X’ union select 1,column_name,1,1,1,1,1 from INFORMATION_SCHEMA.COLUMNS where table_name=‘users‘--}. Das Ergebnis liefert sofort die nötigen Spalten der Tabelle wie die folgende Abbildung zeigt.

bWApp SQL Injection Ablauf - 7

Da wir nun alle Informationen haben, reicht eine einfache Abfrage der {users} Tabelle: {X’ union select 1,login,password,email,secret,1 from users-- }. Diese liefert den Benutzernamen und das Passwort, das offenbar mit einer HASH Funktion umgewandelt und gespeichert wurde. Je nach Qualität der Hashes – den aktuellen Mindeststandard was Algorithmen und Schlüssellängen betrifft gibt beispielsweise das BSI (Bundesamt für Sicherheit in der Informationstechnik) in der BSI TR-02102[23] Richtlinie vor. So dürfen beispielsweise SHA-256, SHA-512/256, SHA-384 und SHA-512 verwendet werden. Für einfache Passworte findet man auch für sichere HASH Funktionen relativ rasch Ergebnisse, so auch für unseren Hashwert {6885858486f31043e5839c735d99457f045affd0} wie die folgende Abbildung zeigt.

Onlineseite zum Auffinden von Passworten aus HASH Werten

An dieser Stelle sei noch angemerkt, dass die Auffindbarkeit des zugehörigen Passwortes nichts mit der Sicherheit der HASH Funktion an sich zu tun hat . Das erste Praxisbeispiel hat also gezeigt, dass man sich über einfache Abfragen bis hin zur Tabelle mit den Usernamen und Passworten tasten kann. Hat man diese erst einmal geknackt kann man die reguläre Funktionalität – beispielsweise eines Online-Shops – nutzen, um Schaden anzurichten. Alle Aktionen, die wir nun im Namen des entsprechenden Nutzers tun wären nur schwer als Hackerangriffe zu identifizieren, da sie über reguläre Kanäle ablaufen.

Schutz vor SQL Injections

Sie wissen nun also über die Grundlagen der Angriffe Bescheid. Wie kann man sich nun gegen SQL Injections wirksam zur Wehr setzen?

User Privilegien

Um den potenziellen Schaden eines erfolgreichen SQL-Injektionsangriffs zu minimieren, sollte jeder Anwendung ein eigenes Datenbankkonto zugewiesen werden. Dabei sollte man darauf achten, dass Konten, die nur Lesezugriff benötigen auch nur Lesezugriff auf Tabellen erhalten. In mySQL ist hierfür der Befehl GRANT zuständig. Zum weiteren Schutz schlägt die OWASP mehrere Strategien vor, wir werden uns zwei davon näher ansehen, nämlich „Stored Procedures“ und „Escaping“.

Stored Procedures

Vereinfacht gesagt ist eine „Stored Procedure“ ein vorbereiteter (SQL)-Code, den man speichern und immer wieder verwenden kann. Da die Abfragen inhaltlich variieren, können auch Parameter übergeben werden. In der Praxis sieht das für mySQL folgendermaßen aus:

CREATE PROCEDURE `hello_world`(par_name VARCHAR(32))
BEGIN
SELECT CONCAT('Hello ', par_name);
END

Diese Prozedur beinhaltet schon einen Parameter, nämlich den Namen. Der Aufruf der Prozedur erfolgt jetzt mit:

CALL hello_world(‚Mr. X‘);

Die Ausgabe ist dann {Hello Mr. X} Das einfache Beispiel zeigt bereits, dass im Falle der Übergabe des Namens als PHP Variable zwar SQL Code eingeschleust werden kann, dieser aber nicht aus der Prozedur „entkommen“ kann, und somit auch keinen Schaden anrichtet. Stored Procedures werden innerhalb der Datenbank gespeichert. Neben der damit verbundenen höheren Sicherheit ist auch die Ausführung schneller und der Traffic über das Netzwerk geringer. Wesentliches Argument, um auf Stored Procedures zu verzichten ist meist die höhere Last, die diese Art des Zugriffes auf Daten mit sich bringt. Gerade bei vielen parallelen Zugriffen wird dadurch die Last nicht unerheblich.

Escaping

Ein weit verbreiteter Schutzmechanismus ist das Maskieren (Escape) von Zeichen mit anderen Zeichen. Dazu gibt es meist ein spezielles Maskierungszeichen (Escape Character), oft ist dies der Backslash {\}, wie beispielsweise in HTML {\r\n} für den Beginn einer neuen Zeile steht. In mySQL gibt es folgende Zeichen:

•   \0  An ASCII NUL (X'00') character
•   \'  A single quote (') character
•   \"  A double quote (") character
•   \b  A backspace character
•   \n  A newline (linefeed) character
•   \r  A carriage return character
•   \t  A tab character
•   \Z  ASCII 26 (Control+Z); see note following the table
•   \\  A backslash (\) character
•   \%  A % character; see note following the table
•   \_  A _ character; see note following the table[25]

Die Umwandlung erfolgt in den meisten Programmiersprachen mit eigenen Funktionen, in PHP war dies die Funktion mysql_escape_string ( string $unescaped_string ) : string. Die Funktion wurde aber mit PHP 7.0 durch mysqli::escape_string ( string $escapestr ) : string ersetzt. Wendet man die Ersetzungen konsequent an, dann können die Sonderzeichen aus den Beispielen nicht ungefiltert bis zur SQL Abfrage durchdringen und somit auch keinen Schaden anrichten. Da Zeichenersetzungen immer spezifisch auf eine Datenbank (in dem Fall mySQL) maßgeschneidert sind, sind Stored Procedures immer dieser Variante vorzuziehen.

ZAP und Nikto

Bevor wir uns über Nikto und ZAP unterhalten –Comic Fans muss ich enttäuschen, es hat nichts mit den gleichnamigen Comics zu tun – gilt es den Begriff des Penetrationstests zu definieren. Diese Tests fassen meist speziellen Tools in einer Umgebung zusammen. Diese Tools erlauben dann gezielte Angriffe auf bekannte Schwachstellen. Allen, die mit Penetrationstests noch keine praktische Erfahrung gemacht haben, sei der Leitfaden des BSI[26] zu dem Thema an Herz gelegt, dass die grundlegenden Abläufe sehr gut darstellt. Eine weit verbreitete Sammlung für die praktische Umsetzung ist KALI Linux. Hiervon gibt es auch virtuelle Maschinen , mittels derer gefahrlos geübt und getestete werden kann. In Kali Linux ist auch das Tool ZAP (Zed Attack Proxy Project) enthalten, da wir jedoch lokal auf unserer virtuellen Maschine mit bWApp bereits das ältere Tool Nikto installiert haben, sehen wir uns einen Scan hiermit an. In der virtuellen Maschine öffnen Sie im Menü den Link zu Nikto, was ein Konsolenfenster öffnet. Da es sich um eine Perl Anwendung handelt, starten wir mit dem Befehl: {perl nikto.pl -host localhost} Der Parameter {-host} dient dazu, den zu untersuchenden Server zu spezifizieren. Die folgende Abbildung zeigt das Ergebnis des Scans.

bWApp Nikto Analyse

Im Detail erhält man folgende Infos:

root@bee-box:/toolbox/nikto-2.1.5# perl nikto.pl -host localhost
- ***** SSL support not available (see docs for SSL install) *****
- Nikto v2.1.5
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    localhost
+ Target Port:        80
+ Start Time:         2019-01-16 16:11:57 (GMT1)
---------------------------------------------------------------------------
+ Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_fastcgi/2.4.6 PHP/5.2.4-2ubuntu5 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
+ Server leaks inodes via ETags, header found with file /, inode: 838422, size: 588, mtime: 0x506e4489b4a00
+ The anti-clickjacking X-Frame-Options header is not present.
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /crossdomain.xml contains a full wildcard entry. See http://jeremiahgrossman.blogspot.com/2008/05/crossdomainxml-invites-cross-site.html
+ /crossdomain.xml contains 0 line which should be manually viewed for improper domains or wildcards.
+ PHP/5.2.4-2ubuntu5 appears to be outdated (current is at least 5.4.4)
+ mod_ssl/2.2.8 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ Apache/2.2.8 appears to be outdated (current is at least Apache/2.2.22). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ OpenSSL/0.9.8g appears to be outdated (current is at least 1.0.1c). OpenSSL 0.9.8r is also current.
+ mod_ssl/2.2.8 OpenSSL/0.9.8g - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell (difficult to exploit). CVE-2002-0082, OSVDB-756.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3268: /doc/: Directory indexing found.
+ OSVDB-48: /doc/: The /doc/ directory is browsable. This may be /usr/doc.
+ OSVDB-561: /server-status: This reveals Apache information. Comment out appropriate line in httpd.conf or restrict access to allowed hosts.
+ Retrieved x-powered-by header: PHP/5.2.4-2ubuntu5
+ OSVDB-3092: /phpmyadmin/changelog.php: phpMyAdmin is for managing MySQL databases, and should be protected or limited to authorized hosts.
+ OSVDB-3268: /icons/: Directory indexing found.
+ Cookie phpMyAdmin created without the httponly flag
+ Uncommon header 'tcn' found, with contents: choice
+ OSVDB-3092: /README: README file found.
+ OSVDB-3092: /INSTALL.txt: Default file found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /phpmyadmin/: phpMyAdmin directory found
+ 6544 items checked: 0 error(s) and 23 item(s) reported on remote host
+ End Time:           2019-01-16 16:12:27 (GMT1) (30 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Die Bezeichnung „OSVDB“ steht für das Open Source Vulnerability Database Projekt[27], das leider 2016 eingestellt wurde. Die NIST (National Institute of Standards and Technology) führt mit der NVD (National Vulnerability Database[28]) ein ähnliches Verzeichnis, auch wenn es vordergründig nur für die USA gedacht ist. Eine Suche nach {server-status} als möglichen Angriffsvektor zeigt beispielsweise folgendes Ergebnis:

Suchergebnis für ’server-status’

In der Detailbeschreibung sieht man dann betroffene Systeme und deren Versionen, und vor allem auch Vorschläge zur Lösung.

Zusammenfassung

In diesem Kapitel haben Sie die grundlegenden Techniken zum Ausführen einer SQL Injection kennengelernt. In weiterer Folge haben wir uns mit einfachen Methoden zur Gefahrenabwehr beschäftigt. Diese werden ergänzt durch intensive Tests, die weitere Schwachstellen aufdecken.

Übungsbeispiele

Übungsbeispiel 1:

Testen Sie das erlernte Wissen nun anhand der Seite SQL Injection (GET/Select). Sucht man einen Film in der Datenbank, so wird die Seite eher unauffällig aussehen. Noch dazu kann man in der Auswahl der Filme nichts eingeben.

bWApp SQL Injection über Select

Auch hier kann man erkennen, dass Parameter in der URL übergeben werden.

http://xxx/sqli_2.php?movie=2&action=go

Die Vorgehensweise ist also ähnlich, die Manipulation wird aber über die URL übergeben.