Regelmäßig auftretenden Fallstricke:
- Blindes Vertrauen in Informationen aus Cookies oder in der URL übergebene Parameter
- Ungeprüfte Eingaben aus Formularen
- Vor-Validierungs-Konten
- Uneingeschränkte Benutzer-Navigation
- Falsch eingestellte Berechtigungen für Web-Ordner
- Caching vertraulicher Informationen
- Webserver-Demos installiert zu lassen (z.B. die standardmäßig mit IIS installierten)
- Vergessen, die Default-Passwörter für das Datenbank-Backend zu ändern
- Nicht-Einspielen von Sicherheits-Patches
- Offenlassen von Ports für die Web-Administration
Hier eine kurze Beschreibung der ersten fünf gängigen Fehler:
Vertrauen ist gut, Kontrolle ist besser
"Vertrauen ist gut, Kontrolle ist besser" war und ist schon immer ein gutes Motto um Risiken zu vermeiden. Entwickler und Programmierer von Web-Anwendungen täten gut daran, sich dieses Motto zu Eigen zu machen. Cookies und in der URL übertragene Parameter machen das Leben für den Entwickler zwar leichter, aber die übergebenen Daten sollten immer validiert werden.
Viele Unternehmen mit Basis im Web sind hier erst durch Schaden klug geworden, und zwar durch die berüchtigte "Warenkorb-Sicherheitslücke", bei der Cyber-Ladendiebe die Preise von Artikeln im Warenkorb ändern konnten. Der Warenkorb war nichts weiter als ein textbasierter Cookie. Beim Gang zur Kasse zählte der Server einfach die Einzelpreise der im Cookie gespeicherten Artikel zusammen. Man stelle sich das einmal vor: Der Kunde besaß die totale Kontrolle über die Preise. Und was noch schlimmer war: Der Server hatte keine Möglichkeit, die Daten zu validieren. Das dürfte für viele Unternehmen ein böses Erwachen gegeben haben!
Die beste Möglichkeit, dies zu überprüfen, besteht darin, alle Cookies zu löschen, die Anwendung auszuführen und sich dann die auf die Festplatte geschriebenen Cookies anzuschauen. Es empfiehlt sich immer, einen Blick auf den Inhalt der Cookies zu werfen, um sicherzugehen, dass keine vertraulichen Informationen wie Rollen oder schlimmer noch Benutzernamen und Passwörter in Cookies gespeichert werden.
Befehlsgewalt
Der Autor dieser Zeilen wurde einmal gebeten, sich ein System anzuschauen, das Befehle zur Programmsteuerung mithilfe von Parametern in der URL übergab. Ein Blick in den Quellcode offenbarte eine häufige Sicherheitslücke. Befehle auf Systemebene waren in die URL auf folgende Weise eingebettet: action="mach was".
Für die Tests wurden eine Reihe spezieller URLs generiert, um festzustellen, wie das System mit diesen umgehen würde. Und tatsächlich konnte man die Kontrolle über das gesamte System gewinnen, indem man Befehle übergab, mit denen das System nicht rechnete: action="cat xxx >> /etc/passwd".
Fazit: Falls man Parameter über die URL übergibt, sollte man diese zumindest auf ungültige oder schädliche Inhalte hin untersuchen. Man sollte für alle Parameter bestimmte Grenzwerte festlegen, so dass die Anwendung bei einem unerwarteten Wert entsprechend reagieren kann. Auch dies lässt sich einfach testen: Man verändert einfach die URL in der Adresszeile des Browsers und beobachtet, wie die Anwendung mit diesen Daten umgeht.
