Suchen

Die Webanwendung als Sicherheitsrisiko – Teil 1 Wie Cross Site Scripting und Local File Inclusion funktionieren

Autor / Redakteur: Marcell Dietl / Peter Schmitz

Webanwendungen sind aus den Unternehmen gar nicht mehr wegzudenken, denn Mitarbeiter sowie Kunden können weltweit darauf zugreifen. Doch sie machen es potentiellen Angreifern gleichermaßen einfacher sensible Unternehmensdaten auszuspähen. In dieser dreiteiligen Artikelreihe von Security-Insider.de betrachten wir die häufigsten Gefahren von Web-Applikationen und zeigen mögliche Sicherheitsmaßnahmen auf.

Firma zum Thema

Viele Webanwendungen sind anfällig für indirekte Angriffe wie Cross Site Scripting.
Viele Webanwendungen sind anfällig für indirekte Angriffe wie Cross Site Scripting.
( Archiv: Vogel Business Media )

Im Laufe der Jahre hat sich das Internet zu einem fundamentalen Bestandteil des wirtschaftlichen Lebens entwickelt. Dank sinkender Preise und stetig steigender Geschwindigkeiten bei der Datenübertragung werden immer mehr Geschäftsprozesse auf Webanwendungen ausgelagert.

Dadurch wird es für potentielle Angreifer jedoch gleichermaßen einfacher, unerlaubt auf sensible Unternehmensdaten zuzugreifen. Sei es um diese zu verkaufen oder um einen Wettbewerbsvorteil zu erlangen.

In vielen Statistiken zu den verschiedenen Schwachstellen in Webanwendungen taucht eine mögliche Angriffsform immer wieder an oberster Stelle auf: das Cross Site Scripting (XSS). Dabei führt der Angreifer einen Scriptcode, am häufigsten JavaScript, im Kontext einer Webanwendung aus.

Da JavaScript browserseitig interpretiert wird, erlaubt ein solcher Fehler zum Beispiel das Session Cookie eines angemeldeten Nutzers auszulesen. Mit dessen Rechten kann sich der Angreifer anschließend auf der Webseite bewegen (Session Hijacking).

Seite 2: Die zwei Arten des Cross Site Scripting

Die zwei Arten des Cross Site Scripting

Beim Cross Site Scripting unterscheidet man primär zwischen den beiden Typen Reflected und Persistent XSS, welche sich technisch gesehen nur unwesentlich unterscheiden.

Im Falle der reflektierten Code-Ausführung muss der Angreifer eine Person mit möglichst hohen Rechten dazu bewegen einen manipulierten Link aufzurufen, der den nötigen Scriptcode etwa innerhalb der URL enthält. Entsprechende Links können beispielsweise über E-Mails oder Foren-Beiträge verbreitet werden. Am häufigsten zielt eine solche Attacke auf die Suchfunktionen von Webapplikationen ab, die das Ergebnis der vom Nutzer ausgeführten Suche nicht richtig filtern.

Persistentes XSS stellt immer dann eine potentielle Gefahr dar, wenn der Nutzer einer Webapplikation den Inhalt selbst verändern darf. Dies ist etwa bei Gästebüchern oder Kommentaren gegeben. Kann ein Angreifer mit geringen Rechten Scriptcode in ein Kommentarfeld einfügen, so wird dieser Code von jeder Person ausgeführt, die anschließend diese Seite besucht.

Stattdessen könnte ebenso normaler HTML-Code benutzt werden, um etwa ein Inner Frame (IFrame) zu platzieren, welches eine Anmeldemaske vortäuscht.

Kontrolle übernehmen dank Cross Site Request Forgery

Ähnlich dem zuvor beschriebenen Angriff funktioniert das so genannte Cross Site Request Forgery, kurz CSRF oder XSRF. Ziel ist es den Nutzer zum unwissentlichen Ausführen von Kommandos auf der Webanwendung zu bewegen. Solche Fehler finden sich vergleichsweise oft auf den Web-Schnittstellen von Routern.

Über Parameter in der URL ist es beispielsweise möglich, sicherheitsrelevante Einstellungen wie etwa das Passwort eines Nutzers oder bei Routern den zu verwendenden DNS–Server zu verändern. Hierfür muss der Angreifer einen Mitarbeiter mit genügend Rechten dazu bewegen, einem unbekannten oder maskierten Link in einer E-Mail zu folgen und so die Einstellungen unbewusst nach Wünschen des Absenders zu verändern.

Seite 3: Daten mithilfe von Local File Inclusions ausspähen

Daten mithilfe von Local File Inclusions ausspähen

Eine weitere Gefahr für ein Unternehmen, welches sensible Daten auf Webanwendungen auslagert, besteht durch als File Inclusion bezeichnete Angriffe. Bei einer File Inclusion hängt die für das Opfer gegebene Gefahr von mehreren Faktoren ab.

Grundlegend gilt es zwischen Remote- und Local-File-Inclusion–Fehlern (RFI und LFI) zu unterscheiden. In diesem Teil der Artikelreihe betrachten wir die Local File Inclusion, die nicht zwangsläufig zum Erfolg eines Angriffes führt, ihn jedoch entscheidend begünstigen kann.

Ausschlaggebend sind die Rechte, mit denen die Webapplikation auf dem Server läuft. Fatal wäre es, diese mit den höchsten Rechten zu starten, was bei Linux/Unix Systemen „root“ entspricht und bei Windows Systemen „NT Authority/System“.

Ohne zusätzliche Schutzvorkehrungen, die den Zugriff auf Dateien außerhalb des Webverzeichnisses verhindern, kann ein Angreifer dank einer LFI-Schwachstelle bis auf die höchste Ebene des System-Verzeichnisbaums gelangen und so jegliche Datei auslesen, von deren Existenz er weiß. Da es vereinheitlichte Namen für Passwort- und Konfigurationsdateien gibt, stellt dies für einen geduldigen und geschickten Eindringling keine große Herausforderung dar.

Ist die Webanwendung mit geringen Rechten gestartet worden, sind Konfigurationsdateien sowie einige durchaus informative Systemdateien im Normalfall dennoch lesbar. So könnte der Angreifer etwa ermitteln, welche Nutzer Zugriff auf das System haben und anschließend gezielt versuchen schwache Passwörter zu erraten.

Gefahrenpotential indirekter Angriffe

Alle soeben beschriebenen Schwachstellen lassen sich unter dem Begriff „indirekte Angriffe“ auf eine Webapplikation zusammenfassen. Sie erlauben es im Normalfall nicht, Sicherheitsvorkehrungen direkt zu umgehen und sensible Daten zu erhalten. Mit Hilfe von Social Engineering jedoch, wie etwa dem gezielten Versenden von E-Mails oder durch das Erraten schwacher Passwörter aufgrund des Wissens um die Existenz der Benutzernamen, stellen sie eine ernstzunehmende Gefahr dar.

Artikelfiles und Artikellinks

(ID:2019217)