A1 - Injection

vorige Präsentation: Web Security | zurück zum Buch-Kapitel [esc] | Nächste Präsentation A2 - Authentifizierung

Auf Platz 1 der OWASP Top 10 2017.

Die OWASP beschreibt dieses Problem allgemein so:

Injection-Schwachstellen tauchen auf, wenn eine Anwendung nicht vertrauenswürdige Daten an einen Interpreter weiterleitet. Injection Schwachstellen sind weit verbreitet, besonders in altem Code; sie finden sich in SQL-, LDAP- und XPath-Anfragen, Systembefehlen, Programm-parametern usw.

Wir haben im Kapitel PHP DB Schreiben → Löschen schon SQL Injection behandelt. Zur Verhinderung von SQL-Injection steht uns in PHP die Prepared Statements zur Verfügung:

Php Code Prepared Statements verhindern SQL Injection

$query = $dbh->prepare('SELECT * FROM users WHERE id=?');
$query->execute(array( $_GET['pid'] ) );

Mit dem prepare wird das SQL-Statement bereits vor-kompiliert. Die Daten, die als Input vom User/der Userin kommen werden mit execute an die Datenbank übergeben, können aber nicht mehr als SQL interpretiert werden.

Prepared Statement mit benannten Platzhaltern

Eine zweite Schreibweise für prepared Statement ist noch besser lesbar: dabei werden statt der Fragezeichen benannte Platzhalter verwendet:

Php Code Prepared Statements mit benanntem Parameter

$stm = $dbh->prepare ( 'SELECT * FROM USERS WHERE USERNAME LIKE :name' );
$stm->bindParam(':name', $_POST['name'] );
$stm->execute();

Prepared Statement falsch verwenden

Man kann auch mit prepared statments noch Code schreiben, der für Injections anfällig ist. Wenn man nämlich im String der an prepare übergeben wird Variablen einbettet:

Php Code Prepared Statements falsch gmacht

$stm = $dbh->prepare ( "UPDATE users SET newsletter = ? WHERE USERNAME = '$name'" );
$query->execute(array( $_GET['newsletter'] ) );
$stm->execute();

OWASP Empfehlungen

Die OWASP empfiehlt:

  1. Den Interpreter gänzlich vermeiden, oder
  2. Eine Schnittstelle benutzen es dem Interpreter erlaubt zwischen Code und Daten zu unterscheiden (z.B., prepared statements, stored procedures in der Datenbank), oder
  3. Den Input von der Userin/dem User geeignet escapen bevor er an den Interpreter weiter gegeben wird

Im dritten und schlechtesten Fall ist weiter zu beachten:

Unabhängig von den oben genannten Punkt gilt noch die Empfehlung:

Siehe auch SQL Injection Prevention Cheat Sheet

A1 - Injection

vorige Präsentation: Web Security | zurück zum Buch-Kapitel [esc] | Nächste Präsentation A2 - Authentifizierung

/

#