Schon beim Entwurf der Webanwendung kann man möglichen DoS-Angriffen zuvor kommen. Beim sog. "Threat Modelling" wird zwar vor allem auf Angriffe auf z.B. die Anwendungslogik oder die Authentifizierung geachtet, aber auch DoS-Angriffe lassen sich zumindest teilweise schon beim Entwurf verhindern oder zumindest abschwächen.

"Irgendwas irgendwie verbrauchen"

So könnte man eine große Anzahl der DoS-Angriffe gegen die Webanwendung umschreiben. Sei es, dass die Rechenleistung mit unnützen Aktionen belegt wird, sei es, dass der Hauptspeicher mit unnützen Daten gefüllt wird, sei es, dass der Festplattenspeicher mit unnützen Dateien beschrieben wird - immer versucht der Angreifer, von nur begrenzt verfügbaren Ressourcen so viele für sich zu reservieren, dass für die Bearbeitung der Anfragen anderer Benutzer nichts oder nicht mehr genug davon zur Verfügung steht.

Cachen, cachen, cachen...

Je mehr Daten in Caches vorgehalten werden können, desto weniger müssen berechnet, zusammengesetzt, aus Datenbanken abgefragt oder durch welche u.U. rechenintensiven Aktionen auch immer bereit gestellt werden. Der Einsatz von Caches empfiehlt sich schon, um die normale Belastung der Webanwendung so weit wie möglich zu reduzieren. Das man damit DoS-Angriffen erschwert, ist eigentlich nur ein angenehmer Nebeneffekt. Für den Angreifer stellt der Cache bzw. stellen die Caches nur eine zusätzliche Hürde oder ein zusätzliches Ziel dar: Werden z.B. die Datenbankabfragen gecached, muss ein Angreifer, der die Datenbank lahm legen will, entweder den Cache angreifen oder ihn unterlaufen, so dass die Datenbank trotz Cache überlastet wird. Das ist i.a. aber schwieriger und/oder aufwendiger als ein Angriff auf die Datenbank allein. Ein mehrfach eingeschleustes "SELECT * FROM Datenbank" führt ohne Cache zu ständiger Aktivität der Datenbank, während beim Einsatz eines Caches das Ergebnis der zweiten und aller folgenden Abfragen aus dem Cache geliefert wird und die Datenbank für andere Anfragen zur Verfügung steht. Ob evtl. der Cache durch das Zwischenspeichern des gesamten Datenbankinhalts überlastet wird, ist dabei eine andere Frage, die aber für dieses einfache Beispiel uninteressant ist. Sonst könnte man auch argumentieren, dass die SQL-Abfrage ja wohl i.A. nur über eine SQL-Injection-Schwachstelle möglich ist, die ja nicht vorhanden sein sollte.

Verbrauch von Rechenleistung

Sicherheitsrelevante Aktionen müssen auf dem Server ausgeführt werden - aber was ist mit den nicht sicherheitsrelevanten? Vor allem, wenn sie rechenintensiv sind wie z.B. das Umrechnen eines Avatar-Bilds? Wenn möglich, sollte man solche Aufgaben dem Client übertragen. Für Berechnungen auf dem Server gilt: Alle vom Client gelieferten Daten dürfen nur mit Funktionen bearbeitet werden, deren Leistung ggf. gedrosselt ("throttled") und auf eine bestimmte Laufzeit begrenzt werden kann. Außerdem sollte jede vom Benutzer ausgelöste Aktion auch einem bestimmten, authentifizierten Benutzer zugeordnet werden können. Können anonyme Benutzer beliebig aufwendige Aktionen auslösen, lädt das geradezu zu einem DoS-Angriff ein. Die Einschränkung "sollte" ergibt sich aus der einfachen Tatsache, dass es oft erwünscht oder sogar notwendig ist, dass Benutzer sich selbst registrieren können und danach sofort vollständigen Zugriff auf die Webanwendung haben. In so einem Fall kann ein Angreifer bei Bedarf einfach einen oder beliebig viele Benutzerkonten anlegen und die Beschränkung "Rechenleistung erst nach Registrierung" ist wirkungslos.

Wann immer möglich, sollten Ergebnisse gecached und statische, statt dynamischer Inhalte verwendet werden.

Verbrauch von Speicherplatz

Sowohl RAM als auch Massenspeicher sind kostbare Ressourcen. Es dürfte klar sein, dass der Benutzer keine beliebig lange Daten liefern darf. Für hochgeladene Daten müssen angemessene Maximalgrößen gesetzt werden, bei deren Überschreiten die Aktion, ggf. nach einer Warnung sowie dem Überschreiten einer dabei gesetzten zweiten Grenze, abgebrochen wird. Evtl. ist es angebracht, Arbeitsspeicherintensive Operationen nur gestaffelt auszuführen und über die zulässige Anzahl hinaus eintreffende Requests zeitversetzt auszuführen.

Können kleine heraufgeladene Dateien während der Bearbeitung große Speichermengen, egal ob im RAM oder auf dem Massenspeicher, belegen, müssen auch dafür Maximalgrößen festgelegt und beachtet werden. Sonst handelt man sich ein Problem vergleichbar dem von Archivbomben (siehe About Security #239 / #240) ein.

Virtueller Speicher ist keine Lösung, sondern ein Problem

Auf den ersten Blick mag es verlockend erscheinen, bei knapp werdenden Hauptspeicher auf virtuellen Speicher auszuweichen. Das kann aber zu einer neuen DoS-Schwachstelle führen - das System wird nicht durch gefülltes RAM, sondern durch ständiges Ein- und Auslagern virtuellen Speichers lahm gelegt. Was dem Angreifer im Endeffekt egal ist, der hat sein Ziel erreicht.

Verbrauch von Datenbankleistung

Wann immer möglich, sollten die Ergebnisse von Datenbankabfragen gecached werden, um die Anzahl der Abfragen zu minimieren. Die Abfragen sollten so weit wie möglich optimiert werden, und wenn möglich, sollten Stored Procedures an Stelle extern zusammengestellter Abfragen verwendet werden (was nebenbei beim Verwenden parametrisierter Aufrufe auch zum Verhindern von SQL-Injection-Angriffen eingesetzt werden kann, siehe About Security #13).

Verbrauch von Authentifizierungsversuchen

Alles Wesentliche zur sicheren Authentifizierung wurde bereits in About Security #232 bis #238 beschrieben, zur Abwehr von DoS-Angriffen interessiert dabei eine Frage: Was passiert bei einer, ggf. mehrmals, fehlgeschlagenen Authentifizierung? Passt man hier nicht auf, kann ein Angreifer andere Benutzer aussperren, indem er sich mit deren Benutzernamen und einem beliebigen Passwort anzumelden versucht. Die Anwendung erkennt einen Angriff und sperrt den angeblichen Angreifer aus - der gar nichts dafür kann.

Soviel zum Thema "DoS-Schwachstellen". In der nächsten Folge geht es um die Untersuchung von Werten wie Session-Tokens und Passwörtern.

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)
• About Security #241: Schwachstellen-Suche: Denial of Service (3)
• About Security #242: Schwachstellen-Suche: DoS verhindern
• About Security #243: Schwachstellen-Suche: DoS verhindern (2)
• About Security #244: Schwachstellen-Suche: DoS verhindern (3)

zurück

nach oben

drucken

empfehlen

kommentieren