Donnerstag, 24. November 2011


Topthema

Donnerstag, 29. April 2010 | Topthema

About Security #252: Schwachstellen-Suche im Überblick (4)

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/055214)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Im vierten Teil des Überblicks über die Schwachstellen-Suche in Webanwendungen geht es zuerst um Angriffe auf den Webserver. So, wie eine normale Anwendung auf das Betriebssystem und seine Funktionen angewiesen ist, ist eine Webanwendung auf den Webserver angewiesen. Ein Angreifer, der die Kontrolle über den Webserver erlangt, kann danach auch die Webanwendung kompromittieren.

Angriffe auf den Webserver

Um den Webserver erfolgreich anzugreifen, muss der Angreifer wissen, mit welchem Server er es überhaupt zu tun hat. Daher ist der erste Schritt eines Angreifers immer das Erkennen des Webservers. Gibt der nicht von sich aus Name und Versionsnummer etc. preis, hilft das sog. Fingerprinting, bei dem der Webserver anhand charakteristischer Eigenschaften oder Verhaltensmuster erkannt wird (siehe About Security #206). Eine Möglichkeit für einen Angriff ist dann die Ausnutzung bekannter Schwachstellen (#207). Um sich vor solchen Angriffen zu schützen, gibt es verschiedene Möglichkeiten. Sich zu verstecken, also keine Informationen über Name und Versionsnummer auszugeben, hilft dabei wenig (#208). Außer vorhandenen Schwachstellen kann ein Angreifer auch Default-Zugangsdaten und -Inhalte aller Art ausnutzen (#209). Dazu gehören auch nicht benötigte Funktionen, die in einer sicheren Konfiguration abgeschaltet sein müssen. Das gilt auch für nicht benötigte Verzeichnislistings (#210). Auch manche HTTP-Methoden können gefährlich werden (#211). Ein weiterer Problemfall sind Proxy-Server: Über die kann ein Angreifer seine Herkunft verschleiern und evtl. auch andere Server im lokalen Netz oder andere Dienste auf dem Proxy-Server angreifen (#212). Insbesondere beim Virtual Hosting kann eine unsichere Konfiguration sehr gefährlich werden, ihr gilt daher eine besonders sorgfältige Prüfung. (#213).

Was möchte ein Angreifer? Sich die Kontrolle über die Anwendung verschaffen. Wie gelingt ihm das am einfachsten? Indem er sich als Benutzer, am besten als Administrator oder anderer Benutzer mit besonderen Rechten, anmelden kann. Für den Angreifer besonders interessant und für den Betreiber der Anwendung besonders gefährlich sind

Angriffe auf die Authentifizierung

Bevor man die Authentifizierungsfunktionen prüfen kann, muss man erst mal feststellen, welche es überhaupt gibt, denn es gibt mehrere Möglichkeiten, Benutzer gegenüber einer Webanwendung zu authentifizieren (#214). Manchmal, vor allem wenn es keine oder nur schwache Regeln für den Aufbau von Passwörtern gibt, führt brutale Gewalt am einfachsten zum Ziel: Brute-Force-Angriffe versuchen, ein Passwort zu erraten. Dazu müssen viele Passwörter in möglichst kurzer Zeit ausprobiert werden, was die Webanwendung besser verhindern sollte. (#215). Beim Brute-Force-Angriff hilfreich sind zu aussagekräftige Fehlermeldungen, die dem Angreifer verraten, ob ein Benutzername gültig ist oder nicht (#216). Hat ein Angreifer gültige Benutzernamen ermittelt, fällt der Brute-Force-Angriff gleich viel leichter (#217). Führt Brute Force nicht zum Ziel, sucht der Angreifer nach anderen Wegen zum Umgehen der Authentifizierung. Den können z.B. ungeschützt übertragene Zugangsdaten öffnen, die vom Angreifer beobachtet werden können. Das kann aber sogar trotz der verschlüsselten Übertragung über HTTPS passieren, wenn dabei nicht aufgepasst wird (#218). Ein weiterer möglicher Schwachpunkt ist die Verschlüsselung - die manchmal gar keine ist, sondern nur eine Umkodierung darstellt (#219). Aber auch wenn die Daten tatsächlich verschlüsselt und nicht nur umkodiert werden, können Schwachstelle bleiben - z.B. wenn die Verschlüsselung falsch bzw. unsicher angewendet wird (#220).

Ist die eigentliche Authentifizierung sicher, sucht der Angreifer anderswo nach Schwachstellen. Die Funktion zur Änderung des Passworts ist dabei ein potentielles Ziel, denn wenn ein Angreifer das Passwort zu einem ihm bekannten Benutzernamen nach seiner Wahl ändern kann, kann er sich damit danach anmelden (#221). Und wie sieht es aus, wenn ein Benutzer sein Passwort vergessen hat? Meist gibt es eine Funktion, die ihm dann zu einem neuen verhilft. Auch in dieser Funktion zum Passwort-Reset kann es Schwachstellen geben, z.B. unsichere "Sicherheitsfragen" oder Passwort-Hinweise oder eine unsichere "Recovery-Funktion" (#222). Eine sichere Lösung besteht z.B. darin, dem Benutzer an die gespeicherte E-Mail-Adresse einen eindeutigen, nicht erratbaren und nur kurze Zeit gültigen URL zu schicken, bei dessen Aufruf innerhalb der Gültigkeitsdauer der Benutzer auf eine Seite gelangt, auf der er ein neues Passwort eingeben kann. Bei der Schwachstellensuche in der eigenen Webanwendung kann sich das Testen im wesentlichen auf einen Vergleich der vorhandenen Funktion mit beschriebenen Schwachpunkten beschränken. Anders sieht es bei einem Black-Box-Test aus (#223).

In der nächsten Folge wird diese Zusammenfassung und damit auch der Themenblock "Schwachstellensuche in Webanwendungen" abgeschlossen.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

Kommentare

Folgende Links könnten Sie auch interessieren

  • Netzwerkangriffe von innen  [22.10.2009]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,796,.html]
  • Nmap   [14.08.2009]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,789,.html]
  • Extensions-News  [03.11.2008]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,2007,.html]
  • Twittern mit .NET  [24.02.2010]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,2881,.html]
  • About Security #132: XSS-Angriffe (2)  [22.11.2007]
    [http://entwickler.de/zonen/portale/psecom,id,99,news,39553,.html]