entwickler.de

Mögliche DoS-Schwachstellen in der Webanwendung wurden bereits in About Security #239 beschrieben: Immer, wenn ein Benutzer mit wenig Aufwand eine hohe Auslastung der Webanwendung verursachen kann, besteht Gefahr. Die muss verringert und am besten ganz beseitigt werden.

DoS-Schwachstellen in der Webanwendung verhindern

Die in About Security #239 beschriebenen Beispiele gehen zum Teil von Angriffen auf bzw. über andere Schwachstellen aus, wie z.B. die Abfrage der gesamten Datenbank über SQL Injection. Entsprechend einfach ist das Verhindern dieser Angriffe: Gibt es keine Schwachstellen, können sie auch nicht für DoS-Angriffe ausgenutzt werden. Andere Angriffe gehen von "bösartigen Eingaben" aus, die die Webanwendung auf ganz normalem Weg erreichen. Egal, ob das nun das Heraufladen präparierter Dateien wie Bilder oder Archive, oder die Suche nach sämtlichen Produkten des Online-Shops ist, immer hat eine gewünschte Aktion unerwünschte Nebenwirkungen. Da man die "bösartigen Eingaben" nicht verhindern kann und will, muss man bei der Verarbeitung der Daten ansetzen: Auch bei gewünschten Eingaben muss man davon ausgehen, dass sie böse gemeint sind. Man muss sich also bei jeder Aktion fragen, ob/wie sie missbraucht werden kann und ob/wie man dem Missbrauch verhindern oder eindämmen kann.

Beispiel 1: Datenbankabfragen

Betrachten wir als Beispiel die Suchfunktion eines Webshops. Mal abgesehen von der Frage, ob es überhaupt sinnvoll ist, z.B. durch die Eingabe eines '*' nach allen Produkten suchen zu können (niemand möchte sich wirklich einen gesamten Warenhauskatalog auf einmal ansehen) und ob nicht vielleicht eine Forderung wie "vor einem Wildcard müssen mindesten 1/2/3/... Zeichen stehen" angebracht wäre, kann man die Folgen einer solchen Eingabe auch durch zusätzliche, fest vorgegebene Beschränkungen kontrollieren. Zum Beispiel könnte das Ergebnis auf 50 Einträge beschränkt werden, die nächsten 50 werden erst dann in der Datenbank abgefragt, wenn der Benutzer sie aktiv anfordert. Im Normalfall passiert das erst, wenn er die ersten 50 Ergebnisse zumindest oberflächlich geprüft hat, was auf jedem Fall einige Zeit dauert. Selbst wenn alle Ergebnisse auf einer Seite ausgegeben werden, dauert es einige Sekunden, bis der Benutzer nach unten gescrollt und auf "Weiter" geklickt hat (oder wie auch immer die nächste Suche ausgelöst wird). Zum Problem "Ein Computer kann das schneller" und automatischen Angriffen komme ich gleich noch.

Beispiel 2: Heraufgeladene Dateien

Als weiteres Beispiel sollen heraufgeladene Dateien dienen. Die können bekanntlich allen möglichen digitalen Sondermüll enthalten und man ist gut beraten, sie von einem Virenscanner prüfen zu lassen, bevor man sie an andere Benutzer ausliefert. Dadurch verhindert man, dass eine hochgeladene PDF-Datei Exploits für Schwachstellen im Adobe Reader enthält, ein Bild eine Schwachstelle in Grafikprogrammen ausnutzt oder anderes Unheil angerichtet wird. Virenscanner erkennen i.A. auch Archivbomben und packen sie gar nicht erst aus. Möchte man die Dateien, z.B. Bilder für Avatare, durch die Webanwendung selbst prüfen lassen, fängt man zweckmäßigerweise klein an: Stimmt der vom Webbrowser gelieferte MIME-Type? Den kann und wird ein Angreifer zwar i.A. passend fälschen, aber die Prüfung schadet ja nicht. Stimmen die Header der Datei mit dem erwarteten Dateityp überein? Stimmen die Dimensionen des Bilds oder ist es auffallend gross? Möchte jemand ein 2048*2048 Pixel großes Bild in einen 48*48 Pixel großen Avatar umrechnen lassen, kann er die 2000 überflüssigen Pixel ruhig auf seinem Rechner entsorgen. Erst wenn man relativ sicher ist, es wirklich mit einem Bild zu tun zu haben, übergibt man es an das zuständige Programm zum Umwandeln in die gewünschte Größe und das gewünschte Dateiformat.

Kleine Aktion - große Wirkung; viele kleine Aktionen - DoS

Auch durch eigentlich völlig harmlose Aktionen kann ein Angreifer u.U. einen DoS auslösen - er muss sie nur oft genug parallel oder direkt nacheinander auslösen. Wer im Webshop nicht nach '*' suchen darf, sucht dann vielleicht nach 'aaa*', 'bbb*', 'ccc*', ... 'zzz*', 'aab*', ..., und das in mehreren Browserfenstern gleichzeitig. So etwas lässt sich auch wunderbar automatisieren, ein Skript, das entsprechende Requests an die Webanwendung schickt, ist schnell geschrieben. Um einen solchen Angriff zu verhindern, muss verhindert werden, dass ein Benutzer viele eigentlich zulässige Aktionen schnell nacheinander oder parallel auslöst. Das muss auf dem Server mit auf dem Server gespeicherten Informationen, z.B. zur laufenden Session, geprüft und sicher gestellt werden. Keinesfalls darf dazu eine im Browser gespeicherte Informationen wie z.B. ein Cookie verwendet werden, da dessen Wert vom Angreifer manipuliert werden kann (und auch wird), um die Schutzfunktion zu unterlaufen. Wie viele gleiche oder unterschiedliche Aktionen einem Benutzer zur gleichen Zeit erlaubt werden, hängt dabei sehr von der jeweiligen Anwendung ab.

In der nächsten Folge geht es um DoS-Angriffe auf den Webserver, z.B. durch DDoS-Angriffe.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #239: Schwachstellen-Suche: Denial of Service
• About Security #240: Schwachstellen-Suche: Denial of Service (2)