Kein Webentwickler kommt um Formulare herum. Sie sind ein nicht wegzudenkender Teil des World Wide Webs und auf nahezu jeder Website vorhanden. Ist es nun die Kommentarfunktion, ein Kontaktformular oder ein Login-System, in allen drei Fällen haben wir es mit Benutzereingaben zu tun. Die Eingaben sollten immer entsprechend gesichert sein, um böswilligen Handlungen zu aus dem Weg zu gehen. Welche Angriffsmöglichkeiten es bei Formularen gibt und wie man Sie als Entwickler verhindern kann zeige Ich euch hier!
1. Cross-Site-Scripting (XSS)
Ich beginne mit dem Cross-Site-Scripting (kurz: XSS), weil die Lücke potentiell bei allen Scripts vorhanden ist, die eine zuvor erfolgte Benutzereingabe ausgeben. Damit habe Ich auch schon das wesentliche Prinzip erklärt: Bei XSS Attacken versucht der Angreifer in der Regel, Javascript Code einzuschleusen. Er sendet also ein mehr oder weniger gefährliches Script an ihr PHP Script. Wenn man diese Eingabe nicht filtert, wird der Javascript Code ausgeführt.
Um das praktisch zu erläutern: Wenn Ich über ein ungeschütztes Formular einen Kommentar schreiben würde und als Name den folgenden Javascript Code angebe, dann würde jeder Besucher automatisch auf meine Webseite weitergeleitet, wenn er den Kommentar aufruft:
<script> window.location="http://maxkops.com"; </script>
Das Ausmaß dieses Fehlers wird schnell klar. Doch eben so leicht ist die Lösung des Problems! PHP bringt dafür die htmlentities Funktion mit. Der übergebene String wird von allen HTML Tags befreit. Eine Javascript Ausführung ist so nicht mehr möglich:
htmlentities($_POST['koomentarinhalt'], ENT_QUOTES);Der Parameter ENT_QUOTES bewirkt, dass auch einfache Anführungszeichen entfernt werden. Es empfiehlt sich, generell auf diese Funktion zu setzen. Früher wurden Strings auch mit str_replace “gesichert”, indem z.B. “<script>” mit einem Leerzeichen ersetzt wurde. Dies ist aber nicht sicher, wie Wir bereits in diesem Artikel gezeigt haben.
Man sollte die Funktion ebenfalls bei der Verwendung von $_SERVER[‘PHP_SELF’] gebrauchen.
Hinweis:
Wenn ein Formularfeld einen bestimmten Datentyp erwartet, ist es einfacher, die Variable zu casten. Wenn ich den Typ mit int auf eine Zahl setze, werden automatisch alle anderen Zeichen entfernt.
2. SQL Injection
Die SQL Injection ist eine ebenso beliebte und gefährliche Angriffsmöglichkeit für Datenbanken. Eine entsprechende Injection schleust einen SQL Code ein, mit dem man möglicherweise Änderungen an der Datenbank vornehmen kann. Als Beispiel nehme ich folgende SQL Anfrage:
SELECT * WHERE `name` = '$suche'
$suche ist die Benutzereingabe, die getätigt wird. Durch eine Eingabe eines einfachen Anführungszeichens kann man den String in der SQL Anweisung schließen. Alles was danach folgt, wird als normaler SQL Befehl verstanden. Lautet die Eingabe also
' OR WHERE '1' = '1
dann entsteht folgende SQL Anweisung:
SELECT * WHERE `name` = '' OR WHERE '1' = '1'
Es werden also nicht nur die Zeilen ausgewählt, in denen der Name ein leerer String ist, sondern alle. (‘1’ = ‘1’ ist immer erfüllt.) Bisher ist das zwar nicht dramatisch, hängt der Angreifer jedoch einen DELETE Befehl an, sind die wertvollen Daten schneller gelöscht als Ihnen lieb ist.
3. Datei Uploads
Datei Uploads sind nützliche Funktionen einer Website, man sollte Sie aber nicht zu leichtsinnig einsetzen. Vor der Implementierung eines Upload Formulars sollte feststehen, wofür dieses genutzt werden soll (z.B. Bilder) und welche Dateitypen akzeptiert werden sollen (z.B. JPG,PNG,TIF). Lassen Sie nur diese Dateitypen zu! Wenn keine Filterung erfolgt, können auch PHP Dateien hochgeladen und anschließend auf ihrem Webserver ausgeführt werden. So wird die nette Fotoupload Homepage schnell zur Spamschleuder.
Hierzu ein kleines Snippet:
$erlaubte_dateitypen = array("image/gif", "image/jpg");
$dateityp= $_FILES['datei']['type'];
if(in_array($dateityp,$erlaubte_dateitypen){
//Upload durchführen
}
else{
echo "Unerlaubte Dateiendung";
}
