Teil 4: SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
- SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
- Teil 2: SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
- Teil 3: SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
- Teil 4: SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
- Teil 5: SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
- Teil 6: SQL-Injection: So schützen Sie Ihre Webserver vor Hackerangriffen
<Files ~ "\.inc$">Order allow,denyDeny from all</Files>...
<Files ~ "\.inc$">
Order allow,deny
Deny from all</Files>Offengelegte Quelltexte, die sich auf dem Webserver befinden, bieten Hackern reichlich Einblick in die Funktionsweise der Web-Applikation und manchmal auch die Möglichkeit, Sicherheitsmaßnahmen zu umschiffen.
Backdoor-URLs
Eine weitere Sicherheitslücke, die zu SQL-Injections führen kann, stellen sogenannte Backdoor-URLs dar. Hierbei handelt es sich um vermeintlich geschützte Ressourcen, die direkt via URL zugänglich sind. Meist fällt so etwas beim Testen nicht unbedingt unmittelbar auf, denn beim Zugriff über beabsichtigte Zugangswege werden wirklich nur authentifizierte Benutzer zugelassen. Diese Sicherheitslücke illustriert zum Beispiel dieser Quelltext:
$authenticated = FALSE;
$authenticated = check_auth();
/* ... */
if ($authenticated) {
include './sicherheitsluecke.php';
}Da sich das PHP-Dokument sicherheits luecke.php aus diesem Beispiel aber im Dokumentverzeichnis des Webservers befindet, kann es leider direkt von jedem beliebigen Webbrowser eingesehen werden, indem die sonst üblichen Zugangsbeschränkungen zwar nicht ausgehebelt, dafür aber einfach umgangen werden können.
Ein ähnliches Problem stellen Javascript-Skripte dar, die manchmal zum Verarbeiten der Formulareingabe genutzt werden. Sie mögen zwar die Eingabe über die betreffende Webseite tatsächlich filtern, indem sie etwa Anführungszeichen unterdrücken, aber nur wenn man es darauf ankommen lässt.
Ein Angreifer kann stattdessen den Quelltext der Webseite abspeichern, die Aufrufe der Javascript-Filter in einem Texteditor entfernen und aus dem so modifizierten Formular SQL-Injections auf das Opfer-System feuern. Beschränkt sich das Filtern der Eingabe auf die Javascript-Funktionen, ist das System eine leichte Beute.
Abwehrstrategien
Eine SQL-Injection gelingt durch das Einschleusen von Anführungszeichen. Daher konzentrieren sich auch Abwehrmaßnahmen auf das Neutralisieren der Eingabe und das Unterdrücken von Fehlermeldungen. Im praktischen Einsatz haben sich vor allem die folgenden drei Methoden bewährt:
• Herausfiltern (jedoch nicht Ausmaskie• ren) von Anführungszeichen aus der Eingabe in die Web-Applikation unabhängig von dem Ursprung der Daten; • Ausmaskieren von Anführungszeichen, zum Beispiel mit einer Funktion wie mysql_real_escape_string() bei der Ausgabe aus dem Applikationsserver nach außen hin, zum Beispiel in die Datenbank oder an memcached; • der Einsatz von sogenannten Prepared Statements, sofern diese von der verwendeten Datenbank unterstützt werden, um der Kreativität potenzieller Angreifer klare Grenzen zu setzen.
TIPP: Zum Testen der Verwundbarkeit einer Web-Applikation hinsichtlich SQL-Injections kann man kostenlose Tools wie sqlmap und SQLFury einspannen.
Anführungszeichen maskieren
Das Ausmaskieren von Anführungszeichen mittels escape-Funktionen wie mysql_real_escape_string() ist an sich trivial. Anstatt, wie hier am Beispiel von MySQL:
$abfrage = "SELECT spalte1
FROM tabelle
WHERE spalte2 = '".$_
POST['spalte2Wert']."'";
$query = mysql_query($abfrage) or
die("Die Datenbank konnte nicht abgefragt werden! ")sollte etwa der folgende Quelltext verwendet werden:
$abfrage = "SELECT spalte1
FROM tabelleWHERE spalte2 = '".mysql_real_escape_string($_POST['spalte2Wert'])."'";$query = mysql_query($abfrage) or die("Die Datenbank konnte nicht abgefragt werden!");PHP Data Objects und Prepared Statements
PHP bietet für nahezu jede beliebige Datenbank escape-Funktionen zum Ausmaskieren der Ausgabe aus einer Web-Applikation. Lediglich die Oracle-Anbindung bietet sie nicht; hier kommen stattdessen sogenannte Prepared Statements zum Einsatz.
Prepared Statements ersetzen ad-hoc erzeugte Datenbankabfragen. Sie erhöhen die Sicherheit der Datenbank, indem sie die SQL-Logik und die Daten strikt voneinander trennen. Dadurch erübrigt sich der Einsatz von escape-Funktionen.
