Web-Anwendungen und ihre größten Schwachstellen

Anzeige

Eine Liste mit Schwachstellen in Webanwendungen ohne Wertung der Reihenfolge. Viele Informationen beziehen sich auf die Aussagen des OWASP-Projektes. Dort sind auch mögliche Lösungen und Hintergründe in ausführlicher Form hinterlegt (Downloads).

Cross Site Scripting (XSS)

Die bekannteste und meiste genutzte Lücke im System - XSS. Wie, was und warum - dazu habe ich bereits einen Artikel im Vorfeld veröffentlicht.

Grundlegend heißt es, bösartige User hinterlegen Script im Browser des Anwenders und holen darüber benutzereigene Daten und können mit diesen Daten beispielsweise schadhaften Code injizieren. Die meisten Angriffe werden mittels JavaScript ausgeführt, daher auch die ehemalige Ablehnung von JavaScipt in einigen Bereichen. Grundlegend können aber XSS-Attacken mit jeder Script-Sprache ausgeführt werden, die der Browser unterstützt. Seit dem Thema Web 2.0 ist JavaScript in aller Munde und in vielen Anwendungen nicht mehr wegzudenken. Um so wichtiger das Wissen über die möglichen Schwachstellen und die damit verbundene Vorsorge. Gerade im AJAX-Umfeld ist XSS ein Problem.

Hierbei sehr interessant das XSS-Cheat Sheet (Auch im Download von OWASP zu finden)

Cross Site Request Forgery (CSRF)

Der Hacker greift den Client an und übernimmt die Kontrolle über den Browser. In der Regel passiert das nach dem Einloggen in eine Webappliaktion. Mit diesem Login kann der Hacker dann Anfragen an das System kreieren und nutzereigene Daten als Rückmeldung bekommen. In der Regel laufen derartige Aktione über Cookies-Sessions. Einzige Lösung ist das nicht Speichern durch den Browser von relevanten Daten.

Offene URLs

Eine ganze Reihe von Webseiten haben Anwendungen für kleine Bereiche laufen. Allerdings schützen sie die Verzeichnisse nicht und versierte User finden die URLs recht schnell und können so auf eventuell schützenswerte Daten zugreifen. Es findet also das klassische Erraten von Adressen statt, was man aber deswegen nicht als abwegig und nachlässig einstufen sollte. Prinzipiell sollte man den Anderen nicht unterschätzen, also lieber das Verzeichnis schützen und eine Zugangskontrolle implementieren.

Ausführen von

Kann die Applikation Nutzerdaten akzeptieren, dann kann prinzipiell auch schadhafter Code ausgeführt werden. Die meisten Probleme in diesem Umfeld sind mit der Sprache PHP bekannt. Anfällig ist aber jede Applikation oder Framework. Die Schwachstellen wird bezeichnet als Remote File Inclusion (RFI).

Injection-Fehler

Hierbei nutzen Hacker die Möglichkeit, dass Daten vom Anwender als Befehl oder Anfrage an einen Interpreter gesendet werden. Dabei werden die Befehle manipuliert und die Daten verändert. Man kann also jede Form von Daten für die Anwendung erstellen, lesen, ändern oder löschen. Das größte Problem in aktuellen Anwendungen sind die gelobten APIs. Diese könnten, wenn sie Lücken aufweisen dazu missbraucht werden. Klassisches Beispiel sind SQL-Injections.

Objekt-Zugriff

Unautorisierte Zugriffe via Direct Object References dienen dem Angreifer um auf Dateien, Verzeichnisse, Schlüssel oder direkt auf Datenbankeinträge zuzugreifen. Prinzipiell kann man, wenn man einen Schlüssel im System hat, auf die anderen Schlüssel schließen und verwenden. Ein klassisches Beispiel ist der Finanzmarkt: die Kontonummer des Nutzers referenziert ihn in allen Anwendungen und somit hat der Angreifer Kontonummer und kann damit weitere Daten abrufen. Eine indirekte Referenz kann helfen und macht die Zugriffe autonomer. Grundlegend sollten direkte Referenzen vermieden werden.

Fehlerbehandlung

Ausführliche und inhaltlich wertvolle Fehlerbeschreibungen eines Fehlers in der Webapplikation sind für Hacker ein Schlüssel. Mit diesen detailreichen Informationen können Bösewichte entsprechende Maßnahmen einleiten um das System für sich zu öffnen. Derartige Probleme lassen sich nur mit Hilfe von umfangreichen Tests finden. Auch dafür gibt es Tools mit entsprechenden Möglichkeiten. Außerdem gehört die Fehlerbehandlung im Live-Betrieb deaktiviert.

Zugang via Session und Kommunikation

Webapplikationen sind so gut wie immer mit einem Zugang geschützt, die Zugangsdaten gehören sicher gespeichert und der Zugang sollte immer per Protokoll SSL laufen. Ebenso speichert man Zugangsdaten nicht 1:1, sondern mit Hilfe eines Hash. Auch hier gilt es, Cookies sind nicht immer der Schlüssel zum Glück des Anwenders. Die Kommunikation zwischen verschiedenen Servern o.ä. gehört mittels Verschlüsselung oder Transport Layer Security realisiert.

Offene Datenablage

Die Datenablage ist bei relevanten Applikation schon heute in vielen Bereichen verschlüsselt. Die Daten selbst werden aber uncodiert gespeichert und die vorhandene Verschlüsselung ist oft unzureichend. Es gilt, dass möglichst starke und ausreichend getestet, besser standardisierte, Algorithmen genutzt werden. Einfache oder eigene Algorithmen entsprechen selten den nötigen Anforderungen.