Bitte dringend um Hilfe: Einbruch befürchtet!
Ralph
- datenbank
0 Bio0 Christian Kruse
Hallo allerseits,
ich habe den Verdacht, dass auf meiner Website jemand eingebrochen sein koennte, und zwar ueber ein oeffentliches Formular.
Habe gerade alles gesichert, bin aber jetzt panisch am checken, wie das gegangen sein koennte, bzw. ob es wirklich so ist.
Darum eroeffne ich jetzt einfach mal diesen Thread, und waere Euch sehr dankbar, wenn ihr mir hin und wieder auftauchende Fragen beantworten koenntet?
Frage Nr. 1: haltet ihr diesen SQL-Ausdruck (in PHP) fuer problematisch?
==============
$newAuthorSQL = 'INSERT INTO dyn_authors';
$newAuthorSQL .= ' (eMail,';
$newAuthorSQL .= ' userName,';
$newAuthorSQL .= ' password)';
$newAuthorSQL .= ' VALUES (';
$newAuthorSQL .= " '".addslashes($eMail)."',";
$newAuthorSQL .= " '".addslashes($userName)."',";
$newAuthorSQL .= " '$password')";
$newID = $dataBase->insert($newAuthorSQL);
Der Befehl ist ausgefuehrt worden, es erfolgte ein Eintrag in der Datenbank, allerdings mit leeren Feldern (eMail, userName, password).
Der Rueckgabewert $newID (id des Eintrags) war korrekt.
Eigentlich werden alle drei Parameter auf Gueltigkeit (leerer String, gueltige Zeichen, ...) geprueft, keine Ahnung, wo da das Loch ist.
Moeglicherweise, dass ich beim Passwort kein addslashes() benutzt habe? Aber kann es denn sein, dass jemand ein Passwort mit Datenbank-Befehl eingeschmuggelt hat, der Eintrag in die DB aber trotzdem korrekt funktioniert?
Auf die Parameter greife ich bei Formularuebergabe z.B. per
$HTTP_POST_VARS['userName']
zu. Die Laenge der Parameter wird allerdings im Skript nicht nochmal explizit geprueft, nur das (Original-)Formularfeld hat eine feste Länge.
Und abschliessend: was kann denn ein Eindringling, der Zugriff auf die DB hat normalerweise tun? Zugangsdaten ausschnueffeln? Hat er Zugriff auf meinen Code? Kann er Dateien loeschen? Schlimmeres?
Ich hoffe, ihr versteht, dass ich die betroffene Domain hier nicht nennen will, man muss ja Sicherheitsloecher nicht unbedingt propagieren.
Danke fuer Eure Hilfe,
Ralph
Sup!
Wenn Du aus den Eingabeparametern die ' nicht rausgefiltert hast, kann der Angreifer je nach DB alles mögliche getan haben.
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
Beim MS-SQL-Server oder einem Server, der die Fehler auf STDOUT schreibt, kann er z.B. Dein Datenbanklayout rausbekommen haben, oder die Verzeichnisstruktur auf dem Server, ggf. konnte er auch einen neuen User anlegen... es ist vieles denkbar.
Wenn das Skript als DB-Administrator oder DB-Superuser läuft, dann könnte der Angreifer ggf. ganze Tabellen oder die ganze DB löschen.
Gruesse,
Bio
Hallo Ralph,
Frage Nr. 1: haltet ihr diesen SQL-Ausdruck (in PHP) fuer problematisch?
[...]
Ja. Du gehst davon aus, dass alle Datenbanken gleiche Quoting-Mechanismen haben. Dem
ist nicht so. DB/2 macht das sogar so, dass ein String in ' eingeschlossen zu sein
hat und das weitere '-Zeichen mit ' escaped werden müssen:
SELECT * FROM blahr WHERE val = 'bl''ahr';
Benutze also die Quoting-Methode, die für deine DB-Engine vorgesehen ist. Bei
MySQL wäre das mysql_escape_string bzw. mysql_real_escape_string. Bei PostGreSQL
wäre das pgsql_escape_string.
Zu dem Thema der SQL-Injection hat Bio dir ja schon mehr geschrieben.
Grüße,
CK