Web-Sicherheit

August 26, 2011

HTTP-Parameterverunreinigung, Teil 1

Filed under: Allgemein — sebastiankuebeck @ 13:52
Tags: , , , , , , , ,

Luca Carettoni und Stefano diPaola präsentierten auf der OWASP EU09 in Polen erstmals eine Angriffstechnik, die sie HTTP-Parameter-Pollution, also HTTP-Parameterverunreinigung nannten. Diese Technik nutzt Eigenheiten in der Art und Weise, wie gängige Web-Technologien HTTP-Parameter interpretieren aus, um gängige Angriffstechniken für Webanwendungen zu erweitern. Varianten dieser Angriffstechnik werden gegenwärtig ständig weiterentwickelt, weshalb ich diesen Beitrag auf mehrere Teile aufteilen muss. In diesem Artikel wird die ursprüngliche Angriffstechnik und deren Grundlagen beschrieben. Diese Kenntnisse sind nötig, um weitergehende Angriffstechniken zu verstehen.

HTTP-Parameter

HTTP-Parameter sind ein optionaler Bestandteil von URLs. Eine Beispiel für eine URL mit HTTP-Parametern:

http://www.example.org/showItem?id=123&size=small

Der letzte, fett gedruckte Teil ist eine kodierte Liste von HTTP-Parametern; das Fragezeichen vor den Parametern trennt den Pfad von der Parameterliste. In diesem Fall lauten die HTTP-Parameter wie folgt:

Name Inhalt
id 123
size small

Da die Länge von URLs beschränkt ist und man Parameter mit sensiblen Daten nicht in der URL haben möchte, kann man diese Parameter auch im Body der HTTP-Anfrage mitschicken. Das kann beispielsweise wie folgt aussehen:

POST showItem HTTP/1.1
Host: www.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 17

id=123&size=small

Kodierung von HTTP-Parametern

Die Kodierung der Parameter – auch URL-Kodierung genannt – ist in beidem Fällen dieselbe. Kurz zusammengefasst besteht eine Parameterliste (oft auch Query String genannt) aus Wertepaaren, die durch ein & oder ein ; getrennt sind. Die beiden Teile jedes Paars werden durch ein = getrennt.

Die URL-Kodierung kennt drei Klassen von Zeichen: Reservierte und nicht reservierte. Die nicht reservierten können ohne Codierung in den Parametern vorkommen, die Reservierten müssen mittels der Prozentdarstellung (siehe nächster Absatz) kodiert werden.

Nicht reservierte Zeichen: a,b,...z, A,B,...Z, 0,1,...9 sowie die Zeichen _ . ! ~ * ' ( )
Reservierte Zeichen: ; / ? : @ & = + $ % #

Bei der Prozentdarstellung wird der Code in Hexadezimaldarstellung nach einem % angegeben. Die Anzahl der Stellen hängt von der gewählten Codierung ab. Empfohlen wird inzwischen UTF-8 doch wird vereinzelt auch noch ISO 8859-1 (Latin-1) verwendet. Statt %20 (Leerzeichen) kann man auch ein + schreiben.

Mehrere HTTP-Parameter mit demselben Namen

Nun ist es auch möglich, mehrere Parameter mit demselben Namen in die Parameterliste aufzunehmen, dass sieht dann zum Beispiel wie folgt aus:

http://www.example.org/showItem?id=1&id=2&id=3

Nun wandeln gängige Webtechnologien Mehrfachparameter auf unterschiedliche Weise in interne Datenstrukturen um, beispielsweise verwandeln ASP und ASP.NET die liste an gleichnamigen Parametern in eine durch Komma getrennte Liste um. So wird aus…

id=1&id=2&id=3

…in der Webanwendung…

Request.Params["id"] -> "1,2,3"

PHP und Lotus Domino ignorieren hingegen alle Parameter bis auf den letzten:
So wird aus der selben Liste in der Webanwendung:

$_GET[id] -> "3"

Bei Perl, Servlets und JSPs verhält es sich genau umgekehrt: Es wird der erste Parameter genommen und weitere Vorkommen ignoriert.

request.getParameter("id") -> "1"

Python (Zope) wiederum liefert einen Array mit den Parameterwerten zurück. In der Webanwendung wäre obige Parameterliste dann:

self.request.form['id'] -> ['1','2','3']

Viele Web-Programmierer sind sich über diese Unterschiede nicht im klaren und erwarten Mehrfachparameter nur dort, wo sie auf der HTML-Seite explizit definiert sind – beispielsweise bei einer Auswahlliste, die eine Mehrfachauswahl erlaubt. Tatsächlich kann aber ein Angreifer Parameter mehrfach setzten, wo immer er will (bei POST-Parametern geschieht das meist mithilfe eines Werkzeugs wie Paros oder WebScarab) und so mitunter die Logik der Webanwendung durcheinanderbringen, wie folgendes Beispiel zeigt:

Die CUPS-Oberfläche, aufgerufen mit doppeltem Parameter „QUERY“. Im Eingabefeld steht der erste Parameter, die Suche berücksichtigte hingegen nur den zweiten. Quelle: Luca Carettoni, Stefano diPaola: HTTP-Parameter-Pollution, OWASP EU09 Poland, 2009.

Ausnutzen der Verarbeitung von Mehrfachparametern

PT Research verwendete diese Technik, um die Web-Application-Firewall ModSecurity zu umgehen (siehe Trick 3). Wie zuvor beschrieben setzt ASP.NET Parameter mit demselben Namen zu einer durch Komma getrennten Liste zusammen. So wird aus…

after=1 AND (select DCount(last(username)&after=1&after=1) from users where username='ad1min')

…in der Webanwendung…

after=1 AND (select DCount(last(username), 1, 1) from users where username='ad1min')

…also eine gültige SQL-Injection-Signatur. Dadurch, dass nur Fragmente in unterschiedlichen Parametern übergeben werden, kann ModSecurity den Angriff nicht erkennen.

2 Kommentare »

  1. […] Vorigen Teil dieser Serie haben wir die Grundlagen der HTTP-Parameterverunreinigung erörtert und die Eigenheiten […]

    Pingback von HTTP-Parameterverunreinigung, Teil 2 « Web-Sicherheit — August 27, 2011 @ 06:42 | Antwort

  2. […] ersten Teil dieser keinen Serie haben wir die Technik der HTTP-Parameterverunreinigung kennengelernt und im […]

    Pingback von HTTP-Parameterverunreinigung, Teil 3 « Web-Sicherheit — August 28, 2011 @ 06:24 | Antwort


RSS feed for comments on this post. TrackBack URI

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Bloggen auf WordPress.com.

%d Bloggern gefällt das: