IT-Sicherheit und Penetrationstests Teil 3: Lücken in Web-Anwendungen aufdecken

Fast schon vergessen sind die Zeiten, in denen Würmer wie Sasser und Netsky ihr Unwesen trieben und der Albtraum eines jeden Administrators waren. Sicherer ist das Internet seitdem aber nicht geworden. Statt die vergleichsweise gut geschützten Heimcomputer ins Visier zu nehmen, zielen Kriminelle immer häufiger auf schlecht gesicherte Web-Anwendungen, denn dort, in sozialen Netzwerken und Online-Shops, befinden sich die wirklich wertvollen Daten: Namen, Adressen, Bankverbindungen usw. In diesem letzten Teil unserer Artikelreihe über Penetrationstests wollen wir diese oft unterschätzte Gefahr näher beleuchten und Ihnen zeigen, was die Experten von //SEIBERT/MEDIA/SYSTEMS tun können, damit Ihre Websites sicher(er) werden.

Noch einmal zur Erinnerung: Am Anfang unseres prototypischen Penetrationstests standen Formalien und Informationsbeschaffung. Auf den gesammelten Erkenntnissen aufbauend hat ein Experte dann die Server im Allgemeinen und die Web-Server im Speziellen untersucht, um Schwachstellen in den Systemen ans Licht zu bringen.

Nun, im dritten und letzten Abschnitt der Sicherheitsüberprüfung, gehen wir noch eine Ebene höher. Uns interessiert jetzt nicht mehr der Web-Server selbst, sondern die Anwendungen, die auf ihm laufen, sei es ein Content-Management-System (CMS), eine Administrationsoberfläche wie phpMyAdmin oder auch nur eine schlichte Seite mit Suchfunktion und Datenbankanbindung. Fehler, das lehrt die Erfahrung, stecken in so ziemlich jeder Web-Anwendung – man muss sie nur finden.

Application Discovery, verräterische Kommentare und die robots.txt

Die Suche nach Fehlern in Webapplikationen unterscheidet sich in seinen Grundzügen erstaunlich wenig von bisherigen Überprüfungen. Am Anfang steht das Aufspüren von Anwendungen, die von außen erreichbar und potenziell angreifbar sind (Application Discovery). Der Unterschied liegt im Detail.

Hat der Experte zuvor einfach auf einen Portscanner zurückgreifen können, muss er sich nun einer Kombination aus verschiedenen Tricks bedienen, um möglichst alle Anwendungen zu entdecken, die auf dem Web-Server zu finden sind.

Ein Reverse IP Lookup liefert eine Liste der Webseiten, die auf demselben Server betrieben werden. Eine geschickte Google-Suche macht ab und an vergessene Verzeichnisse ausfindig. Und auch das stumpfe Durchprobieren typischer Subdomain- und Ordner-Namen kann von Erfolg gekrönt sein.

Viel zu häufig braucht es gar keine exotischen Methoden, um sensible Informationen aufzuspüren – schon ein Blick in den Quellcode der Anwendung kann wahre Wunder wirken. Immer wieder stößt man dort auf Kommentare und auskommentierten Code. Und so sehr wir es als IT-Dienstleister auch begrüßen, wenn Programmierer ihre Arbeit sauber dokumentieren: Vor dem Deployment sollten solche Spuren entfernt werden.

Was zunächst harmlos oder gar lustig ist, kann schnell sicherheitsrelevant werden, und zwar dann, wenn die Kommentare Hinweise auf die Konfiguration und interne Funktionsweise der Anwendung enthalten.

Ganz ähnlich verhält es sich mit der berühmten robots.txt-Datei, die eigentlich nur für Suchmaschinen gedacht ist, aber eben auch für jedermann lesbar sein muss. In dieser Datei können Administratoren Pfade eintragen, die sie von der Indizierung ausschließen wollen - ein Mechanismus, der weit verbreitet ist und von seriösen Anbietern wie Google auch eingehalten wird. Wer auf diesem Wege kritische Pfade "verstecken" will (Security by Obscurity), geht ein hohes Risiko ein, denn der Blick in eben diese Datei gehört für jeden Angreifer zur Routine und wird Ausgangspunkt seiner Einbruchsversuche sein.

Fehler in der Authentifizierung und im Session-Management ausnutzen

In fast jeder Web-Anwendung – von statischen Websites einmal abgesehen – gibt es auf die eine oder andere Weise die Möglichkeit, sich an- und auch wieder abzumelden. Was selbstverständlich klingt, kann leider leicht zu einem Sammelsurium von Fehlern und Lücken werden. Eines ist die Umsetzung eines sicheren Session-Managements definitiv nicht: trivial. Es geht nicht mehr "nur" darum, lückenlosen Code zu schreiben, sondern das Zusammenspiel vieler kleiner Komponenten zu gewährleisten.

Aber was genau macht eine Anwendung eigentlich (un)sicher? Worauf legen Hacker (und Experten im Rahmen von Penetrationstests) ihr Hauptaugenmerk? Unter anderem sind folgende Aspekte hier von Bedeutung:

  • Werden die Login-Daten ausschließlich verschlüsselt übertragen und wurde das Cookie-Attribut secure gesetzt, um MITM-Angriffe zu unterbinden?
  • Ist es möglich, auf private Informationen auch ohne Anmeldung Zugriff zu erhalten, wenn man die Seite direkt aufruft oder Parameter manipuliert?
  • Ist eine Passwort-Vergessen-Funktion vorhanden und kann diese nicht zum Kapern des Kontos missbraucht werden kann, weil sie allgemeingültige Fragen stellt?
  • Werden CAPTCHAs eingesetzt, um Bots auszubremsen, und ist sichergestellt, dass die Bilder bzw. Fragen schwer genug und ihre IDs stets eindeutig sind?
  • Gelingt es, bereits generierte Session-IDs einem anderen Nutzer zuzuspielen und von diesem authentifizieren zu lassen (Session-Fixation-Attacke)?
  • Setzt jeder Request innerhalb der Anwendung ein individuelles Token voraus, um einen Angreifer an der Durchführung von CSRF-Angriffen zu hindern?

Zwar sind die obigen Beispiele nur ein kleiner Teil dessen, was Experten während eines Tests untersuchen sollten. Aber dennoch – oder sogar gerade deshalb – sollte klar geworden sein, warum die Implementierung eines sicheren Session-Managements gewiss keine anspruchslose Aufgabe ist.

Von JavaScript bis SQL: Injection-Schwachstellen ans Licht bringen

Eine der wichtigsten Regeln sicheren Software-Designs lautet seit jeher:

Traue keiner Benutzereingabe!

Leider ist das leichter gesagt als richtig implementiert. Und so sehr sich die vielen Web-Anwendungen auch im Detail unterscheiden mögen – eines haben sie doch (fast) alle gemein: Injection-Schwachstellen, über die sich auf die eine oder andere Weise Code einschleusen lässt.

Der unangetastete Spitzenreiter ist seit Jahren das sog. Cross-Site-Scripting (XSS), eine Angriffsform, auf die wir bereits in unseren Blog-Artikeln IT-Sicherheit als kontinuierlichen Prozess verstehen und Cookie-Diebstahl schnell und erfolgreich unterbinden detailliert eingegangen sind und hier nicht erneut vertiefen wollen.

Eines sollte jedoch klar sein: XSS ist kein Schönheitsfehler, den man in Kauf nehmen darf, wenn etwa eine Deadline naht, sondern eine akute Sicherheitslücke, die schnellstmöglich geschlossen werden muss.

Noch deutlich gefährlicher und häufig der Grund, warum Cross-Site-Scripting nur als Lappalie angesehen wird, sind Injection-Schwachstellen, mit denen sich Code serverseitig ausführen lässt bzw. dort hinterlegte Daten ausgelesen werden können. Zu dieser Kategorie zählen unter anderem diese Angriffe:

  • Local und Remote File Inclusion zum Einbinden von Programmcode
  • SQL-Injection zum Auslesen und Manipulieren der Datenbank
  • Command und Code Injection zum direkten Ausführen von Befehlen

Es gibt noch zahlreiche mehr, die sich aber zumeist nur noch syntaktisch voneinander unterscheiden, jedoch die gleiche Wirkung entfalten: Jede Sekunde, in der die Injection-Schwachstellen im Code verweilen, hat ein Angreifer mit genügend Know-how die Chance, immensen Schaden anzurichten.

Fazit

In unserem dreiteiligen Beitrag zu Penetrationstests sind wir einige der Schritte durchgegangen, die die Experten von //SEIBERT/MEDIA/SYSTEMS bei einer solchen Analyse gehen werden, um Ihre Infrastruktur, Ihre Server-Systeme und Ihre Web-Anwendungen sicher(er) zu machen.

Wohlgemerkt: einige der Schritte. Vollständig und endgültig kann eine Artikelreihe über Penetrationstests eigentlich nie sein. Findige Angreifer werden sich stets neue Wege in fremde Systeme suchen und Sicherheitsfachleute werden gleichermaßen stets neue Wege suchen, um sie daran zu hindern.

Und damit wären wir dann auch schon wieder bei einer der ältesten Weisheiten der IT-Sicherheit, formuliert vom Kryptographie-Experten Bruce Schneier:

Security is a process, not a product.

Weiterführende Informationen

Haben Sie Fragen zum Thema IT-Sicherheit? Möchten Sie Risiken minimieren und Sicherheitslücken in Ihrem Unternehmen identifizieren und stopfen? Die erfahrenen IT-Experten von //SEIBERT/MEDIA/SYSTEMS beraten Sie gerne – bitte sprechen Sie uns unverbindlich an! Ausführliche Informationen finden Sie auch auf unserer speziellen Seite zum Thema Internet-Security-Beratung.

Englische Seite des Open Web Application Security Project (OWASP)
PDF-Datei mit den 10 häufigsten Sicherheitsrisiken für Web-Anwendungen
Vergleich diverser kostenpflichtiger und -loser Web Security Scanner


Mehr über die Creative-Commons-Lizenz erfahren