Viele User sehen bei einem Formular immer nur die Eingabe und was passiert wenn es übermittelt wurde. Was aber bei einer Übermittlung alles mitbedacht werden sollte wissen immer nur die Leute (die meisten), die das Formular gemacht haben. Selbst hab ich schon ab und an Sprüche gehört wie “und das ist alles in der Zeit?”… und im Moment drauf dachte ich gleich “So wenig Hirn??? In der Zeit?!?!?”.
Aber zurück zum eigentlichen Thema. Es geht um die Sicherheit bei Formularen. Leute die sich damit noch nicht so beschäftigt haben lernen vielleicht was neues… und die “Das ist alles in der Zeit?” Menschen sehen was dahinter steckt. Have fun!
P.S.: Wer weitere Anregungen hat oder einen Fehler findet einfach einen Kommentar hinterlassen.
Token Matching – Hast du nicht, bist du nicht!
Hast du, dann bist du. Wenn nicht dann verzieh dich und nerv einen anderen. Genau das passiert beim “Token Matching”. Manch einer frägt sich nun was ein Token ist, aber wie immer gleich hier die Antwort:
Ein Token ist ein geheimer Code, denn wir client- und serverseitig hinterlegen. Einmal im Formular (Client) und in der Session (Server). Somit existiert dieser Wert genau zwei mal.
Wenn nun das Formular übermittelt wird, können wir diese Werte vergleichen und sichergehen, dass diese übereinstimmen. Somit haben wir schonmal sichergestellt, dass wenn eine Übermittlung stattfindet, es sich hierbei auch um das eigene Formular handelt.
Form Whitelisting – Will ich dich?
Damit wir keine ungewollten Formulardaten erhalten, verwenden wir sogenanntes Whitelisting. Dabei Filtern wir die Daten bei der Übermittlung und arbeiten nur mit Werten, die wir wirklich wollen. Zum Beispiel wenn ein String nur alphanumere Zeichen haben darf, prüfen wir diesen String mit Regular Expressions ob er wirklich nur Zeichen wie [a-zA-Z0-9] hat. Möglich ist auch auf Länge zu prüfen oder ob eine Zeichenkette wirklich so entspricht, wie sie eine sein sollte (Email *.*@*.*).
Es gibt aber auch noch weitere Möglichkeiten:
- Numerische Werte mit is_numeric()
- Wert als Integer inval()
- Array mit is_array()
- String mit is_string()
- Wert als String strval()
- Null Wert mit is_null()
- Wert mit allgemein vorhanden sein isset()
Was auch sehr gerne passiert ist übermäßig Leerzeichen einzugeben. In diesem Fall ersetzen wir mehrere Leerzeichen mit einem Leerzeichen indem wir preg_replace() zum Einsatz bringen.
Valid URL – Sagmal woher bist du?
Clientseitig prüfen wir bereits ob die URL richtig ist, jedoch sollte man das auch Serverseitig machen. Dies stellt man am besten mit folgenden an:
- FILTER_FLAG_SCHEME_REQUIRED (http://foo)
- FILTER_FLAG_HOST_REQUIRED (http://www.foobar.com)
- FILTER_FLAG_PATH_REQUIRED (www.foobar.com/foo/bar/)
- FILTER_FLAG_QUERY_REQUIRED (foobar.php?foo=foo&bar=bar)
Saubere Werte – Einmal putzen bitte!
Sinn eines Formulares ist es mit den übermittelten Daten etwas anzustellen. Egal ob man nun ein einfaches senden als Email macht oder einen Datenbankeintrag macht, sollte man darauf achten, dass die Werte “sauber” sind.
Es wäre zum Beispiel möglich Javascript mitzusenden und dieses auszuführen, wenn die Email geöffnet wird.
Das ganze schafft man zum Beispiel mit:
- htmlentities()
- strip_tags()
- mysql_real_escape_string()
Hack Logging – Wissen wer wie nervt.
Natürlich wollen wir auch die Angriffe die gegen uns laufen analysieren. Deshalb verwenden wir ein Log, wo Daten zum Angriff (z.B. IP-Adresse, Host, Art und Datum). Es besteht die Möglichkeit die Angriffe serverseitig in eine Datei zu speichern oder gleich per Email an uns senden zu lassen. Wie heisst es so schön? “Be close to your friends, but closer to your enemies.”
Es gibt noch ein paar weitere Möglichkeiten, worauf ich später noch genauer eingehen werde. Im Moment hab ich leider keine Lust mehr…
Timeout – Zu langsam oder wie?
Coming soon!
HTTPS – Sicher senden!
Coming soon!
Ajax CSRF Angriffe
Coming soon!
Captcha – Bist du blind?
Coming soon!
Loading ...