Konfigurierte (Un-)Sicherheit

Die Auswirkung der Apache-Konfiguration auf die Sicherheit der Webanwendung
Kommentare

In dieser Folge des Security-Workshops dreht sich alles um die Konfiguration des Apache-Webservers. Vor allen zwei Konfigurationen haben meist übersehene Nebenwirkungen. Dieser Artikel zeigt, welche.

PHP Magazin

Der Artikel „Konfigurierte (Un-)Sicherheit“ von Carsten Eilers ist erstmalig erschienen im PHP Magazin 6.2012

Ihre Webanwendung kann absolut sicher sein – wenn das „Fundament“, also Webserver, PHP, Datenbank etc., Schwachstellen enthält, ist sie trotzdem in Gefahr. Der erste Schritt zu einem sicheren System ist immer die Installation aktueller Versionen aller genutzten Programme, und das ist auch bei einer Webanwendung nicht anders. Aber auch wenn alle eingesetzten Programme auf dem aktuellen Stand sind und keine bekannten Schwachstellen enthalten, droht noch Gefahr: Manche Konfigurationen sind unsicher und erlauben auch bei einem schwachstellenfreien Programm Angriffe. Im Folgenden geht es um die Konfiguration des Webservers, konkret des Apache-Webservers. Zumindest vom ersten Angriff sind aber auch alle anderen Webserver betroffen, sofern sie die TRACE-Methode unterstützen. Los geht es mit einem seit langem bekannten Angriff.

Cross-Site Tracing

Beim Cross-Site Tracing (XST) wird die HTTP-Methode TRACE missbraucht [1]. Der Angriff wurde 2003 von Jeremiah Grossman beschrieben [2]. Die TRACE-Methode dient dazu, die Verbindung zum Webserver zu überprüfen. Sie liefert die Anfrage genauso zurück, wie der Webserver sie empfangen hat. Man kann also feststellen, ob und ggf. wo die Anfrage auf dem Weg zum Server verändert wurde und so mögliche Fehler aufspüren. Ein TRACE-Request samt Antwort sieht z. B. wie in Listing 1 aus.

Listing 1: Ein TRACE-Request mit Antwort
ceilers$ telnet testserver.example 80
Trying 192.168.1.100...
Connected to testserver.example
Escape character is '^]'.
TRACE / HTTP/1.1 
Host: testserver.example
X-Header: Testheader

HTTP/1.1 200 OK
Date: Fri, 03 Aug 2012 20:57:54 GMT
Server: Apache/2.0.40 (Unix) 
Content-Type: message/http

TRACE / HTTP/1.1 
Host: testserver.example
X-Header: Testheader

Bei einem XST-Angriff sendet ein im Webbrowser des Opfers laufendes Skript einen TRACE-Request an einen Webserver und erhält als Antwort den kompletten Request samt aller vom Webbrowser gesetzten Header. Und genau die sind für den Angreifer interessant, da sie ggf. auch Cookies und die Authentifizierungsdaten der HTTP-Basic/Digest/NTLM-Authentication enthalten. Mittels XST lassen sich auch Cookies ausspähen, auf die der JavaScript-Code aufgrund eines gesetzten HttpOnly-Flags nicht direkt zugreifen kann [3]. Auf die Authentifizierungsdaten ist generell kein Zugriff durch JavaScript-Code möglich, da sie nicht Bestandteil des DOM sind.

Die Same-Origin-Policy greift ein

Die Same-Origin-Policy der Webbrowser verhindert Requests an andere Domains als die, von der der JavaScript-Code geladen wurde. Der Angreifer ist also für seinen XST-Angriff auf eine weitere Schwachstelle angewiesen. Entweder muss er seinen JavaScript-Code über eine XSS-Schwachstelle in die angegriffene Webanwendung einschleusen, oder er muss eine Schwachstelle im Browser ausnutzen, die Requests an andere als die Ursprungsdomain zulässt. Ein typischer Angriff über eine XSS-Schwachstelle läuft dann so ab (Abb. 1):

  1. Ein Benutzer wird auf die über XSS präparierte Seite der Webanwendung gelockt, von der der Angreifer die Cookies und/oder Authentifizierungsdaten ausspähen will
  2. Der XSS-Code schickt einen TRACE-Request an den Webserver der Webanwendung
  3. Der Webserver sendet als Antwort den kompletten empfangenen Request einschließlich der vom Browser eingefügten Cookies und/oder Authentifizierungsdaten zurück
  4. Der JavaScript-Code des Angreifers sendet die empfangenen Cookies und/oder Authentifizierungsdaten an den Angreifer
Abb. 1: Cross-Site Tracing in Aktion

Themen der folgenden Seiten:

  • JavaScript-Code zum Senden des TRACE-Requests
  • Ein TRACE-Request mit XSS-Code
  • TRACE sicherheitshalber Ausschalten
  • HTExploit umgeht .htaccess-Zugriffsbeschränkungen
  • Limitierte Zugriffsbeschränkungen
  • HTExploit in Aktion
  • Zugriff auf index.php mit der Methode GET
  • Zugriff auf index.php mit der Methode POTATO
  • Request-Methoden für CGI-Skripte
  • Zugriffsbeschränkungen auf Basis des Hostnames
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -