© saicle/Shutterstock.com
PHP Magazin
Die Auswirkung der Apache-Konfiguration auf die Sicherheit der Webanwendung

Konfigurierte (Un-)Sicherheit

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.

Carsten Eilers


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 Trac­ing (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 Antwortceilers$ telnet testserver.example 80Trying 192.168.1.100...Connected to testserver.exampleEscape character is '^]'.TRACE / HTTP/1.1 Host: testserver.exampleX-Header: Testheader HTTP/1.1 200 OKDate: Fri, 03 Aug 2012 20:57:54 GMTServer: Apache/2.0.40 (Unix) Content-Type: message/http TRACE / HTTP/1.1 Host: testserver.exampleX-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...

PHP Magazin
Die Auswirkung der Apache-Konfiguration auf die Sicherheit der Webanwendung

Konfigurierte (Un-)Sicherheit

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.

Carsten Eilers


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 Trac­ing (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 Antwortceilers$ telnet testserver.example 80Trying 192.168.1.100...Connected to testserver.exampleEscape character is '^]'.TRACE / HTTP/1.1 Host: testserver.exampleX-Header: Testheader HTTP/1.1 200 OKDate: Fri, 03 Aug 2012 20:57:54 GMTServer: Apache/2.0.40 (Unix) Content-Type: message/http TRACE / HTTP/1.1 Host: testserver.exampleX-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...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang