2288217

Datenbanken absichern: Schutz vor SQL-Injection

03.08.2017 | 15:31 Uhr |

Eine MySQL-Datenbank läuft auf den meisten Webservern, die CMS, Blog oder Shop beherbergen. Damit Programmier-und Konfigurationsfehler nicht zum Verhängnis werden, ist eine vorausschauende Absicherung der Datenbank nötig.

Der Datenbankserver und dessen Konfiguration geraten nur selten in den Mittelpunkt der Aufmerksamkeit des Admins. Schließlich ist der Datenbankserver von außen nicht direkt erreichbar, sondern dient dynamisch erzeugten Webseiten als Back-End. Programmierfehler, wie sie im Code großer PHP-Projekte immer wieder auftreten, oder auch Bugs in Modulen können Datenbanken für Angriffe verwundbar machen. Bei Angriffen auf Datenbanken mit manipulierten Abfragen (SQL-Injection) geht es darum, einen nicht ausreichend gefilterten Parameter auf der Webseite in den HTTP-Anfragen zu finden. SQL-Injections gehören zu den anspruchsvolleren Angriffen im Web – aber auch zu den fatalsten, wenn sie gelingen.

SQL-Injection: Anatomie eines Angriffs

Die häufigste Art der SQL-Injection arbeitet mit manipulierten Abfragen, die dem Webserver per HTTP untergeschoben werden. Aus Suchfunktionen, Benutzeranmeldungen oder auch nur aus dem Aufruf einer Artikelnummer per POST-oder GET-Methode wird eine SQL-Abfrage geformt und die Datenbank antwortet mit einem Datensatz. Generiert die Webseite aus einem ungefilterten Eingabefeld eine SQL-Abfrage wie

SELECT user FROM users WHERE password = 'Eingabefeld';

so würde die Eingabe von

'XYZ' OR 1=1 --

in der SQL-Abfrage

SELECT user FROM users WHERE password = 'XYZ' OR 1=1 --';

resultieren. Diese Abfrage hätte nun das tatsächliche Passwort umgangen, da die ungefilterte OR-Verknüpfung und das auskommentierte letzte Hochkomma ein erfolgreiches Statement erzeugt.

Bei einer systematischen Überprüfung von My-SQL-Datenbanken auf verbreitete Schwachstellen und veraltete Softwareversionen sind Scripts eine große Hilfe. Es gibt so die Möglichkeit, die Datenbank von innen und außen einer Reihe von Tests zu unterziehen.

Check von innen: Ein Werkzeug zum Check der Datenbank auf dem Server ist das Perl-Script „ mysqltuner.pl „. Zwar ist das Script vornehmlich zur Leistungsoptimierung von My SQL und Maria DB geschaffen, findet aber auch Konfigurationsfehler wie Datenbankbenutzer ohne Passwort. Anhand einer Liste von Schwachstellen kann es zudem bekannte Bugs in der My-SQL-und Maria-DB-Datenbanksoftware auflisten. Bei einem Scan von innen muss das Passwort des root-Kontos in der Datenbank bekannt sein.

Der Download des neuesten „mysqltuner.pl“ geht mit dem Kommando

wget http://mysqltuner.pl -O mysqltuner.pl

im Terminal am schnellsten. Die aktuelle Schwachstellenliste erhalten Sie mit

wget https://git.io/vykrK -O vulnerabilities.csv

Der Aufruf

perl mysqltuner.pl --cvefile vulnerabilities.csv

startet den Check und verlangt die Eingabe des My-SQL-root-Passworts. Ein Report im Terminal zeigt unter „Security Recommendations“ und „CVE Security Recommendations“ sicherheitsrelevante Befunde.

Report von „mysqltuner.pl“: Das Perl-Script überprüft die My-SQL-oder Maria-DB-Datenbank intern auf unsichere Konten ohne Passwort und auf bekannte Sicherheitslücken.
Vergrößern Report von „mysqltuner.pl“: Das Perl-Script überprüft die My-SQL-oder Maria-DB-Datenbank intern auf unsichere Konten ohne Passwort und auf bekannte Sicherheitslücken.

Check von außen: Ein wichtiges Werkzeug zum Abklopfen einer Datenbank über Formulare auf einer dynamisch erzeugten Webseite ist das Python-Programm Sqlmap . Ab Ubuntu 16.04 befindet sich das Tool in den Standard-Repositories, läuft aber auf allen Distributionen mit Python-Interpreter. Der Aufruf

python sqlmap.py [Optionen]

startet das Tool. Ein Scan gegen eine Webseite, deren Parameter „page.php?id=“ per GET-Methode verwundbar für eine SQL-Injection scheint, wäre mit

python sqlmap.py -u 'http://domain.tld/page.php?id=hello'

auszulösen. Sqlmap beherrscht auch POST-Parameter über seine Option „--data“ und eignet sich für Angriffe der Kategorien In-band, Inferential und Out-of-band. Einige wertvolle Anwendungsbeispiele, die sich gegen die eigene Webseite ausprobieren lassen, liefert die englischsprachige Dokumentation .

Phpmyadmin: Potenzielles Einfallstor schließen

Ein beliebtes Werkzeug zur Datenbankverwaltung ist das PHP-basierte Phpmyadmin. Die Anmeldung an Phpmyadmin erfolgt auf der Log-in-Seite anhand eines bereits vorhandenen Datenbankusers oder als Datenbank-root. Eine Anmeldeseite dieser Art auf einem Webserver zu haben, ist immer ein Risiko. Die Anmeldung darf nur per HTTPS stattfinden, ein Log-in über unverschlüsselt übertragene Benutzerdaten ist tabu. Ein selbst signiertes SSL-Zertifikat sollte es dabei mindestens sein, damit Phpmyadmin verschlüsselt erreichbar ist. Wer als Angreifer hier einen Benutzernamen mit Passwort durch Wörterbuchangriffe oder durch einen Exploit findet, steht damit schon in der Datenbank.

Türsteher: Apache mit Filter

Um die Software hinter dynamisch erzeugten Webseiten gegen automatisierte, hartnäckige Scans abzusichern, eignen sich Web Application Firewalls (WAFs). Dabei handelt es sich um einen Erkennungsmechanismus, der auf verdächtige Anfragen reagiert. Eine WAF für den Apache-Webserver ist das Apache-Modul „mod_security“. Dieses Modul ist in den Paketquellen der verbreiteten Linux-Distributionen enthalten und in Debian/Ubuntu mit

sudo apt-get install libapache2-modsecurity

zu installieren. Das Modul bringt eine Beispielkonfiguration mit, die unter „/etc/modsecurity/modsecurity.conf-recommended“ liegt und mit dem Kommando

sudo mv /etc/modsecurity/modsecurity.conf{-recommended,}

aktiv wird. Der Standard ist, keine verdächtigen Anfragen zu blocken, sondern zunächst in der Logdatei „/var/log/apache2/modsec_audit.log“ nur zu protokollieren. Es empfiehlt sich, das so zu belassen und die Funktion des Webservers und der dort angebotenen Webseiten erst ausgiebig zu testen. Scharf schalten wird diese WAF aber erst eine Änderung in der Datei „/etc/modsecurity/modsecurity.conf“. Nach Ersetzen der Anweisung „ DetectionOnly“ in der Zeile

SecRuleEngine DetectionOnly

zu

SecRuleEngine On

blockiert Apache fragwürdige HTTP-Requests, unter anderem jene, die eine SQL-Injection aufspüren können. Der Schutz ist nicht absolut und wird gezielte In-band-Angriffe nicht aufhalten, aber zumindest automatisierte Scans ins Leere laufen lassen.

Tipp: Warum Sie Ihre Webseite auf HTTPS umstellen sollten

Glossar: SQL-Injection

In-band: Eine klassische SQL-Injection ist ein Eingabefeld auf einer Webseite, das bei einer manipulierten Anfrage die Antwort der Datenbank wieder über den Webserver zurückgibt. „In-band“ heißt dieser Typ deshalb, weil der gleiche Kanal für Angriff und Exploit genutzt wird.

Inferential: Falls die Datenbank nicht über den Webserver antwortet, gibt es die Möglichkeit blinder Attacken. Mit einer großen Sequenz an Beispielabfragen kann es gelingen, akzeptierte und verworfene Abfragen auch ohne Antwort zu unterscheiden. Das ist sehr zeitaufwendig, aber genügend Abfragen können eine Datenbankstruktur dennoch rekonstruieren und verwundbare Datenbanktabellen finden.

Out-of-band: Dieses eher seltene Angriffsszenario nutzt nicht direkte SQL-Abfragen, sondern greift die Datenbank über Seitenkanäle an.

Damit dies funktioniert, muss die Datenbank zu lax konfiguriert sein und damit andere Sicherheitslücken haben. Eine typische Out-of-band-Schwachstelle erlaubt es dann, SQL-Abfragen über eine externe URL nachzuladen.

0 Kommentare zu diesem Artikel
2288217