ZDNet stellt eine Liste der häufigsten Fehler in Bezug auf die Sicherheit Web-basierter Anwendungen zusammen. Mit diesem Know-how ausgestattet sollte man die meisten der gängigen Fallstricke während der Entwicklung vermeiden können.
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. In Webformularen finden sich häufig Felder, bei denen die eingegebenen Daten nicht validiert werden. Dies ist ein gefundenes Fressen für Angreifer, die Buffer-Overflows oder SQL Injection einsetzen wollen. Zum Testen kann man im Texteditor einfach einen Text mit mehr als 500 Zeichen erstellen, diesen dann ausschneiden und in das Passwortfeld kopieren. Wo das System den Eingabe-String nicht begrenzt, werden Systeme häufig hängen bleiben oder abstürzen.
Als nächstes kann man die Validierungsregeln dadurch testen, dass man eine Bedingung, die immer als wahr evaluiert wird (z.B. OR "x"="x"), einfügt, indem man diese an das Passwort-Feld anhängt. Viele Systeme können so manipuliert werden, dass sie Unautorisierten Zugang gewähren. Dies liegt an der Konstruktion von SQL-Ausdrücken. Wenn man eine "OR TRUE"-Bedingung anhängt, kann man das System überlisten. Hier ein Beispiel für einen SQL-Ausdruck, der auf diese Weise manipuliert werden könnte:
Select userid, passwd from USERS where userid = :uid_entered and passwd = pwd_entered
Man stelle sich vor, der Benutzer hätte admin in das userid-Feld und password OR "x"="x" in das Passwort-Feld eingegeben. Daraus würde der folgende SQL-Ausdruck werden:
select userid, passwd from USERS where userid=admin and passwd=password OR "x"="x"
Das ist wahrscheinlich nicht das, was der Entwickler im Sinn hatte.
Der Schlüssel liegt unter der Fußmatte
Es ist außerdem erstaunlich, wie häufig System-Accounts für einfache Anmeldungen bei Anwendungs-Datenbanken verwendet werden. Viele Web-Anwendungen speichern Anmeldeinformationen (d.h. Benutzernamen und Passwörter) in ihrer eigenen Anwendungs-Datenbank. Da man sich bei der Datenbank anmelden muss, um seine Anmeldeinformationen zu validieren, handhaben die meisten Systeme die Validierung mithilfe eines so genannten "Vor-Validierungs-Anmelde-Kontos". Bspw. meldet sich das System als "admin/admin" an und stellt sicher, dass es in der Datenbank einen Benutzer samt Passwort gibt, der den Benutzereingaben auf der Website entspricht.
Bemerkenswerterweise sind solche Konten fast ausnahmslos vom Typ "admin" mit umfangreichen Berechtigungen innerhalb der Anwendung. Noch gefährlicher wird diese Praxis, wenn man bedenkt, dass die entsprechenden Passwörter entweder in einer Textdatei im Stammverzeichnis der Website gespeichert oder direkt in die Startseite integriert sind, damit die Web-Anwendung Zugriff auf die Passwörter für diese Konten hat. In beiden Fällen kann ein böswilliger Benutzer äußerst einfach an das Passwort gelangen. Diese Praxis ist fast so, als ob man den Hausschlüssel unter der Fußmatte versteckt oder den Ersatzschlüssel fürs Auto auf der Sonnenblende. Es ist ein großer Fehler, der das Eindringen in eine Web-basierte Anwendung zu einem Kinderspiel macht. Ein weiterer sehr beliebter Test funktioniert so: Man bittet einen der Administratoren der Anwendung, sich korrekt anzumelden, dann ein Lesezeichen für eine beliebige administrative Seite zu speichern (zum Beispiel die Seite "Neuen Benutzer hinzufügen") und sich wieder abzumelden. Nun kann man testen, ob die Session beim Abmelden beendet wird, indem man einen Browser öffnet und auf das Lesezeichen klickt. In erstaunlich vielen Fällen wird einem die Anwendung automatisch Administrator-Rechte verleihen.
Eine weitere Technik besteht darin, nach „totem“ Code zu suchen, der nur auskommentiert, aber nicht entfernt wurde. Man loggt sich als Gast-Benutzer ein (oder als ein beliebiger anderer legitimer Benutzer) und versucht auf Seiten mit solchem "toten" Code zu gelangen. Die Erfahrung zeigt, dass eine Menge solchen Codes immer noch in den Quelltexten vorhanden ist.
Häufig erstellen Entwickler eine Startseite während des Entwicklungsprozesses, die gar nicht für das Deployment gedacht ist, den Anmeldeprozess umgeht und eine Testumgebung einrichtet. Wenn dann der Betrieb des Systems aufgenommen wird, kommentieren Web-Programmierer den Original-Aufruf aus oder benennen die Seite um, belassen aber die Testseite im Web-Stammverzeichnis.
Es lohnt sich auch, den Code daraufhin zu untersuchen, ob es mehrere Anmelde- oder Startseiten gibt, und zu testen, ob einem eine davon Administrator-Zugang zum System verleiht, ohne die Anmeldeinformationen abzufragen. Und man kann versuchen, sich auf der Website ohne die eigentliche Seitennavigation zu bewegen, besonders wenn der Entwickler Hinweise für die Navigation gegeben hat. Normalerweise reicht zur Orientierung ein Blick in die Browser-History oder den Cache, um zu sehen, auf welchen Seiten andere Benutzer waren. Die Temporären Internetdateien liefern eine Fülle von Informationen, falls sie nicht gelöscht wurden. Falls die Anwendung ausdrücklich will, dass man einen bestimmten Weg nimmt, sollte sichergestellt sein, dass auch wirklich alle Hintereingänge versperrt sind. Normalerweise sind Entwickler nicht verantwortlich für falsch eingestellte Berechtigungen – es sei denn, sie haben die Anwendung so erstellt, dass sie sich auf solche Berechtigungen verlässt. Falls eine Anwendung zum Beispiel verlangt, dass ein bestimmtes Verzeichnis für jedermann mit Schreibrechten versehen ist (oder noch schlimmer mit vollen Zugriffsrechten zum Lesen, Schreiben und Ausführen), ist die Anwendung ein ausgezeichnetes Versteck (oder gar Auslösepunkt) für bösartigen Code.
Viele Anwendungen verfügen über Verzeichnisse zum Speichern von temporären Berichten. Man kann versuchen, etwas in den Ordnern auf dem Webserver herumzustöbern, indem man die URL ändert, um ein Gefühl dafür zu bekommen, welche Berechtigungen bestehen. Falls die Anwendung die Möglichkeit zur Freitextsuche bietet (üblicherweise gibt es für das Speichern von Ergebnissen Ordner mit Schreibrechten für alle), kann man versuchen, dorthin eine ausführbare Datei zu posten und diese dann vom Browser aus aufrufen, um zu sehen, ob sie ausgeführt wird.
Falls die Anwendung eine Upload-Möglichkeit bietet, sollte man auf Ausführrechte prüfen. Nur in den seltensten Fällen sollte irgendjemand Ausführungs-Rechte für Webordner haben. Auch sollte kein Benutzer in der Lage sein, ausführbare Dateien auf dem Server laufen zu lassen. Falls man per Shell außerhalb der Anwendung Zugriff auf den Server erlangen kann (was häufig der Fall ist), ist fast jeder dort befindliche Prozess im Besitz eines privilegierten Benutzerkontos wie "oracle", "root" oder "system" und hat dieselben Rechte wie der Besitzer. Potenzielle Probleme entstehen, falls die Anwendung den Upload von Daten erlaubt oder nicht den Zugriff auf einmal hochgeladene Daten einschränkt. Ein weiterer häufiger Fehler besteht darin, dass für Upload-Verzeichnisse nur schwache Zugangsberechtigungen verlangt werden.
Sicherheitslücken vermeiden
Diese Liste ist zwar nicht vollständig, aber sie enthält die häufigsten Fehler, die man bei Entwicklern beobachten kann, wenn sie Web-basierte Anwendungen erstellen. Es gibt eine Reihe hervorragender Informationsquellen für Entwickler und Tester, die mehr über die gängigsten Sicherheitslücken erfahren wollen. Hier sei allen Entwicklern besonders der OWASP-Report für 2004[1] empfohlen. Außerdem sollte man die SANS-Top-20-Liste[2] lesen. Auch wenn sie sich nicht speziell auf Web-Anwendungen bezieht, bekommen Entwickler einen Eindruck davon, worauf sie gefasst sein sollten. Mit diesem Know-how ausgestattet sollte man die meisten der gängigen Fallstricke vermeiden können.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/