Sichere ProgrammierungPflicht: Benutzereingaben filtern

Wie wichtig sichere Programmierung ist, zeigen die regelmäßigen Schreckensnachrichten zu neuen Sicherheitslücken. Davon sind natürlich Open-Source-Systeme betroffen, da dort Sicherheitslücken an die Öffentlichkeit kommuniziert werden. Aber auch kommerzielle Systeme bleiben davon nicht verschont. Sieht man sich einmal die Verteilung der häufigsten Sicherheitsmängel einer Website an, sind die meisten Lücken auf unsichere Programmierung zurückzuführen. Interessanti st dazu die Studie des OWASP (Open Web Application Security Project), einer Organisation mit dem Ziel, die verschiedenen Arten von Sicherheitslücken aufzudecken und zu bekämpfen.

Das OWASP gab 2004 erstmals die Top Ten der bedeutendsten Sicherheitslücken heraus und veröffentlichte später ein komplettes Werk rund um die Sicherheitsprobleme. Die meisten der in den Top Ten genannten Lücken sind auf unsichere Programmierung zurückzuführen, beispielsweise nicht geprüfte Nutzereingaben (Platz 1), gescheiterte Zugriffskontrolle und gescheiterte Authentifizierung (Platz 2 bzw. 3) und Cross Site Scripting (XSS, Platz 4). Diesen Problemen wollen wir auf den nächsten Seiten mit einigen grundlegenden Tipps zu Leibe rücken. Selbstverständlich kann das nur ein Einstieg in das umfangreiche Thema Sicherheit sein.

Die Grundempfehlung hinsichtlich der meisten Sicherheitsprobleme besteht darin, Benutzereingaben zu filtern. Die praktische Schwierigkeit besteht darin, dass Nutzer an Ihre Anwendung auf sehr unterschiedliche Arten Daten übermitteln können. Und all diese Fälle müssen abgefangen werden. Die hier gezeigten Beispiele werden mit PHP realisiert. ASP.NET filtert bereits vor und zeigt bei einigen bedenklichen Daten eine Warnmeldung. Allerdings ist auch dies kein optimales Verhalten und Sie sollten auch in ASP.NET die Nutzereingaben filtern. Vor allem im Bereich der SQL-Injections lauert hier großes Gefahrenpotenzial. Wo kann nun aber ein böswilliger Nutzer überall angreifen? Denkbar sind unter anderem folgende Stellen:
* über Daten in der URL (also per GET übermittelte Daten)
* über Daten in der HTML-Seite. Stellen Sie sich vor, ein Nutzer übernimmt Ihr HTML-Formular, verändert es ein wenig und schickt es dann an Ihr serverseitiges Skript.
* über Daten in Cookies
* über Daten in anderen HTTP-Feldern, beispielsweise im Feld Referer, also der Adresse, von der aus die Seite kommt

Denken Sie immer daran: Mit ein paar einfachen Tools beispielsweise in Form von Browsererweiterungen (siehe auch Kapitel 2) kann ein böswilliger Nutzer eigene HTTP-Header schreiben und Ihre Formulare modifizieren und erneut abschicken. Das heißt, alles, was als HTTP-Anfrage an den Server gelangt, ist potenziell böse. Wie bedrohlich der Angriff ist, hängt im Weiteren davon ab, welche Daten der Nutzer einschleust. Mehr dazu erfahren Sie in den nächsten Abschnitten.

Wir sind jeder der hier beschriebenen Lücken schon in der Praxis – zufällig oder bei Security-Audits – begegnet. Auch wenn manches sehr simpel klingt, es kann wirklich jedem alles passieren. Im Bereich Sicherheit ist Besserwisserei völlig fehl am Platz, denn niemand – uns eingeschlossen – ist vor Fehlern sicher.