Montag, 16. Januar 2012


Topthema

Donnerstag, 7. Juli 2005 | Topthema

About Security #13: Mit Stored Procedures gegen SQL Injection

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/022694)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Die Verwendung von Prepared SQL Statements bzw. Stored Procedures ist neben der in About Security #12 beschriebenen Pr�fung der Benutzereingaben eine weitere M�glichkeit, um SQL-Injection-Angriffe zu verhindern.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Bei der Verwendung von Stored Procedures werden Templates der verwendeten SQL-Abfragen definiert und in der Datenbank gespeichert. W�hrend der Programmausf�hrung werden diese Templates um die �bergebenen Parameter erweitert und ausgef�hrt. Prepared SQL Statements funktionieren �hnlich, die Templates werden jedoch w�hrend der Programmausf�hrung an die Datenbank gesendet und von dieser dann gespeichert, ebenfalls um die Parameter erweitert und ausgef�hrt. Das Hinzuf�gen weiterer SQL-Befehle �ber die Parameter ist bei parametrisierten Abfragen nicht m�glich.

Ein wichtiger Hinweis: Stored Procedures sind nicht von sich aus vor SQL Injection sicher. Werden sie auf herk�mmliche Weise mit den Benutzereingaben aufgerufen, kann SQL-Code eingeschleust werden. Erst durch den parametrisierten Aufruf sind sie nach aktuellem Wissenstand vor SQL-Injection sicher.

W�hrend Stored Procedures von der verwendeten Datenbank unterst�tzt werden m�ssen, k�nnen Prepared Statements auch vom Datenbank-Interface implementiert werden. Diese Prepared Statements auf der Clientseite bieten die gleiche Sicherheit wie ihre serverseitige Variante, profitieren aber nicht wie diese von etwaigen Optimierungen durch das Datenbanksystem.

Im Folgenden wird der Einsatz von Prepared Statements beschrieben. �hnlich funktioniert die Verwendung von Stored Procedures.

Prepared Statements

Als Beispiel soll die Abfrage

SELECT * FROM Benutzer WHERE Ort = 

aus About Security #11 dienen. Wie dort gezeigt wurde, kann ein Angreifer diese Abfrage f�r einige Angriffe ausnutzen. Dies ist bei parametrisierten Aufrufen nicht m�glich. Dabei werden die Eingaben gefiltert und der Typ entsprechend der gespeicherten Abfrage angepasst.

Allgemein lautet die obige Abfrage als Prepared Statement

SELECT * FROM Benutzer WHERE Ort = ?
About Security: Die komplette Serie

F�r PHP gibt es je nach verwendeter Datenbank verschiedene Funktionen zum Erstellen vom Prepared Statements. F�r PostgreSQL kann man die Abfrage als Prepared Statement als

 = pg_prepare("ort_abfrage", 'SELECT * FROM Benutzer WHERE Ort = ');

formulieren. Der Aufruf erfolgt dann �ber folgenden Funktionsaufruf:

 = pg_execute("ort_abfrage", );

F�r MySQL sind entsprechende Funktionen in der experimentellen MySQL-Erweiterung MySQLi vorhanden.

Perls datenbankunabh�ngiges Datenbankmodul DBI stellt folgende Funktionen zur Verf�gung:

 = ->prepare("SELECT * FROM Benutzer WHERE Ort = ?");
= ->execute( );

In Microsofts .NET-Framework k�nnte die parametrisierte Abfrage folgenderma�en formuliert werden:

SqlCommad cmd = new SqlCommand("SELECT * FROM Benutzer WHERE Ort = @ort;")
cmd.Parameters.Add("@ort", ort)

F�r Java gibt es die Klasse PreparedStatement, mit der sich folgende Aufrufe ergeben:

reparedStatement ortabfrage = con.prepareStatement("SELECT * FROM Benutzer WHERE Ort = ?");
ortabfrage.setString(1, ort);
ResultSet rset = ortabfrage.executeQuery();
Weitere Ma�nahmen

Um SQL Injection zu verhindern oder zumindest ihre Auswirkungen zu mindern, sind eine Reihe weiterer Ma�nahmen hilfreich:

  • Der Benutzer, �ber den die Webanwendung auf die Datenbank zugreift, darf nur die absolut notwendigen Rechte besitzen. Sollen nur Daten abgefragt werden, reichen das Recht f�r den SELECT-Befehl und die Zugriffsrechte f�r die Tabellen mit den relevanten Daten aus. Damit kann ein erfolgreicher Angreifer zwar immer noch alle Daten aus diesen Tabellen lesen, aber wenigstens ist ihm keine Manipulation m�glich. Niemals darf von einer Webanwendung aus mit Administratorrechten auf die Datenbank zugegriffen werden.
  • Sofern m�glich, sollte der gesamte Zugriff auf die Datenbank �ber Stored Procedures ausgef�hrt werden. Dann ben�tigt der von der Webanwendung verwendete Datenbankbenutzer nur die Berechtigung zur Ausf�hrung dieser Stored Procedures.
  • Nicht ben�tigte Extended Stored Procedures (z.B. xp_cmdshell f�r MS SQL), Stored Procedures etc. m�ssen entfernt oder dem f�r die Webanwendung verwendeten Datenbankbenutzer der Zugriff darauf verboten werden.
  • Um einem Angreifer keine Anhaltspunkte f�r seinen Angriff zu liefern, d�rfen keine ausf�hrlichen Fehlermeldungen ausgegeben werden. Diese sind in einem Logfile besser aufgehoben. Die Logfiles m�ssen regelm��ig auf verd�chtige Eintr�ge �berpr�ft werden.
  • Sensitive Daten wie z.B. Passw�rter d�rfen nur verschl�sselt gespeichert werden.

Database-Intrusion-Protection-Systeme k�nnen Angriffe feststellen und abwehren. Sie werden in einer sp�teren Folge behandelt. In der n�chsten Folge geht es um einen weiteren Angriff auf Webanwendungen: Cross-Site Scripting.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren