Donnerstag, 26. Januar 2012


Topthema

Donnerstag, 21. Juli 2005 | Topthema

About Security #15: Cross-Site Scripting verhindern

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

In dieser Folge erfahren Sie, wie Angreifer den in About Security #14 vorgestellten Cross-Site-Scripting-Code einschleusen und Entwickler dessen Ausf�hrung verhindern k�nnen.

Code einschleusen

Es gibt drei M�glichkeiten, um Parameter von einem Webbrowser an eine Webanwendung zu �bertragen:
Ein Formular kann Eingaben �ber die POST- oder die GET-Methode schicken. Bei der POST-Methode baut der Webbrowser eine Verbindung zum f�r die Formularverarbeitung zust�ndigen Server auf und sendet in einem zweiten Schritt die Daten. Bei der GET-Methode werden die Daten, abgetrennt durch ein '?', an den im action-Attribut des Formulars definierten URL angeh�ngt und so an den Server gesendet. Cookies werden vom Webbrowser verwaltet und bei jedem Request an den entsprechenden Webserver mitgesendet.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Ein Angreifer kann alle drei Methoden verwenden, um Code einzuschleusen. �blich ist der Weg �ber die GET-Methode, da daf�r nur ein URL entsprechend pr�pariert und dem Opfer untergeschoben werden muss. Um �ber die POST-Methode Code einzuschleusen, muss das vom Benutzer verwendete Formular manipuliert werden. Ein Einschleusen �ber Cookies ist im Allgemeinen zu aufw�ndig, da der Angreifer die Cookies im Webbrowser seines Opfers oder auf dem �bertragungsweg manipulieren muss.

Ein Angriff ist auch �ber Daten m�glich, die nicht direkt an den Benutzer zur�ckgegeben, sondern vorher in einer Datenbank gespeichert wurden. Dies betrifft zum Beispiel Eintr�ge in G�steb�chern, Kommentaren oder �hnlichem. Dort eingeschleuster Code wird im Browser des Benutzers ausgef�hrt, wenn ein entsprechend pr�parierter Eintrag betrachtet wird. Der Vorteil f�r den Angreifer bei diesem so genannten Persistenten Cross-Site Scripting: Er kann problemlos auch die POST- und Cookie-Parameter zum Einschleusen verwenden, da er die Daten selbst an den Server sendet. Nutzt er die direkte R�ckgabe von Eingaben aus, muss er den Benutzer die manipulierten Daten senden lassen. Derartige Angriffe werden auch als reflektiertes Cross-Site Scripting bezeichnet.

Alle Eingaben m�ssen daher vor der R�ckgabe an den Benutzer, beziehungsweise vor der Speicherung in einer Datenbank, sorgf�ltig auf Cross-Site-Scripting-Code gepr�ft werden. Besonders ist darauf zu achten, dass auch wirklich alle verwendeten Parameter gepr�ft werden. Niemand kann einen Angreifer daran hindern, einen bestimmten Parameter sowohl �ber die GET- als auch �ber die POST-Methode an die Webanwendung zu senden. Wird dann der eine Parameter gepr�ft und der andere (ungepr�fte) verwendet, kann Code an der Schutzfunktion vorbeigeschleust werden.

About Security: Die komplette Serie

Dies war z.B. die Ursache f�r einige SQL-Injection-Schwachstellen in Cacti: F�r SQL-Abfragen wurden mit GET �bertragene Parameter verwendet. Gepr�ft wurde jedoch die Variable , in die der Reihe nach die Inhalte der GET-, POST- und Cookie-Parameter geschrieben werden. Ein Angreifer konnte so seinen Code mit GET und einen harmlosen Wert mit POST oder als Cookie senden, um die Schutzfunktion zu umgehen.

Codeausf�hrung verhindern

Das Verhindern der Codeausf�hrung ist sehr einfach, wenn generell kein vom Benutzer eingegebener HTML-Code ausgef�hrt werden soll: Eingegebener HTML-Code wird gel�scht oder unbrauchbar gemacht. F�r PHP erledigen dies die Funktionen strip_tags() und htmlspecialchars() oder htmlentities(). W�hrend strip_tags() versucht, alle HTML-Tags zu l�schen, wandeln htmlspecialchars() und htmlentities() bestimmte oder alle Zeichen in die entsprechenden HTML-Entities um. Aus den Zeichen '<' und '>' zur Kennzeichnung von HTML-Tags werden so die entsprechenden HTML-Entities '&lt;' und '&gt;'. Wird die so bearbeitete Eingabe an den Webbrowser zur�ckgegeben, werden die HTML-Tags nicht interpretiert, sondern als Text ausgegeben.

�hnliche Funktionen stehen auch f�r Perl (im CPAN-Modul HTML::Entities) und ASP.NET zur Verf�gung. Bei Bedarf kann eine Funktion zum Unbrauchbarmachen auch schnell selbst geschrieben werden. Die Zeichen '<', '>', '&' und '"' sollten durch die entsprechenden HTML-Entities '&lt;', '&gt;', '&amp;' und '&quot;' ersetzt werden.

Schwieriger wird es, wenn die Eingabe bestimmte HTML-Tags enthalten darf, beispielsweise weil in einem G�stebuch oder Forum bestimmte Hervorhebungen m�glich sein sollen. In diesem Fall m�ssen unerw�nschte Tags ausgefiltert werden, die erw�nschten Tags d�rfen jedoch nicht besch�digt werden. Erschwert wird dies durch verschiedene Zeichenkodierungen und die Eigenheiten mancher Webbrowser, auch fehlerhaften HTML- oder JavaScript-Code zu interpretieren. Dadurch steigt die Gefahr, dass eingeschleuster Cross-Site-Scripting-Code nicht als solcher erkannt wird. Entsprechende Filterfunktionen m�ssen meist selbst geschrieben werden. Dabei sollten alle zul�ssigen Tags festgelegt und alle anderen gel�scht oder unbrauchbar gemacht werden. Werden gezielt die unzul�ssigen Tags ausgefiltert, k�nnen gef�hrliche Tags �bersehen werden.

Weitere Informationen zu Cross-Site Scripting erhalten Sie ab Folge #129. In der n�chsten Folge geht es um das Einschleusen von Skriptcode in Webanwendungen.

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 "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren

  • Professionelles Webdesign mit (X)HTML und CSS  [28.07.2006]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,525,.html]
  • Hardening Apache  [11.10.2004]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,306,.html]
  • Prefactoring  [29.06.2006]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,534,.html]
  • Hardcore Java  [04.05.2004]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,283,.html]
  • Jakarta Commons  [11.07.2005]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,425,.html]