© saicle/Shutterstock.com
PHP Magazin
Die zehn größten Sicherheitslücken im Web

XSS und Co.

Das letzte Mal haben wir uns mit SQL Injection und Broken Authentication auseinander gesetzt. Dieses Mal geht es unter anderem um das sehr große Thema Cross-Site Scripting, und wir schauen uns die Serverkonfiguration genauer an, die nicht nur dabei helfen kann, mögliche Angriffe einzudämmen, sondern auch entsprechend vorzubeugen.

Tobias Zander


OWASP Top 10

Anschließend an das Authentication-Management sollten wir auch noch einen Blick auf das damit verbundene Sessionmanagement werfen, da Sessions doch heute als Standard dazu genutzt werden, um die Authentifizierung zu speichern. So bringt die beste Absicherung der Authentifizierung leider nichts, wenn danach mit relativ geringem Aufwand die bereits authentifizierte Session übernommen werden kann.

ArtikelserieTeil 1: Die zehn größten Sicherheitslücken im Web – Teil 1: OWASP Top 10, Platz 1 – 2Teil 2: Die zehn größten Sicherheitslücken im Web – Teil 2: Platz 3 – 6Teil 3: Die zehn größten Sicherheitslücken im Web – Teil 3: Platz 7 – 10

Session Hijacking

Damit wir uns mit Session Hijacking beschäftigen können, sollten wir zunächst verstehen, wie eine Session genau funktioniert. Zur Veranschaulichung dient Abbildung 1.

Abb. 1: Beim Session Hijacking wird die Session-ID des Opfers abgehört und dann zum Zugriff auf das eigentlich geschützte System genutzt

Vereinfacht gesehen ist eine Session nicht mehr als ein Array aus Daten, die zu einer eindeutigen ID zugeordnet sind. Der Zugriff auf diese Sessiondaten ist prinzipiell jedem möglich, der diese ID kennt, eine weitere Absicherung erfolgt standardmäßig nicht, bzw. muss manuell implementiert werden. Eine Möglichkeit wäre z. B. das Binden der IP-Adresse an die Session, sodass nur eine bestimmte IP Zugriff auf diese Session hat. Gerade mit der steigenden Anzahl mobiler Zugriffe ist dies aber auch ein Problem, da sich unterwegs doch sehr schnell und häufig die IP-Adressen ändern können und man sicherlich keinem User zumuten möchte, sich bei jedem Wechsel neu einloggen zu müssen. Eine Absicherung über den Useragent ist auch nicht sicher, da dieser problemlos von jedem Angreifer manipuliert werden kann. Es muss also sichergestellt werden, dass Session-IDs gar nicht erst einem Dritten bekannt werden und somit kein Angriff stattfinden kann.

Wie wird eine Session-ID überhaupt generiert? Hierfür ist in der php.ini [1] die Einstellung session.hash_function verantwortlich. Ist dies nicht explizit gesetzt, nutzt PHP per Default md5, um die Hash-ID zu generieren, was eine neue Session-ID von einem Angreifer relativ einfach vorhersehbar macht. Durch das Setzen auf eine bessere Hash-Funktion wie sha256 ist es sehr viel schwerer, an die generierte Session-ID zu kommen.

Der beste Hash-Algorithmus hilft aber leider nicht, wenn die Session-IDs offen lesbar im Netz publiziert werden. So kommt es nicht selten vor, dass Us...

PHP Magazin
Die zehn größten Sicherheitslücken im Web

XSS und Co.

Das letzte Mal haben wir uns mit SQL Injection und Broken Authentication auseinander gesetzt. Dieses Mal geht es unter anderem um das sehr große Thema Cross-Site Scripting, und wir schauen uns die Serverkonfiguration genauer an, die nicht nur dabei helfen kann, mögliche Angriffe einzudämmen, sondern auch entsprechend vorzubeugen.

Tobias Zander


OWASP Top 10

Anschließend an das Authentication-Management sollten wir auch noch einen Blick auf das damit verbundene Sessionmanagement werfen, da Sessions doch heute als Standard dazu genutzt werden, um die Authentifizierung zu speichern. So bringt die beste Absicherung der Authentifizierung leider nichts, wenn danach mit relativ geringem Aufwand die bereits authentifizierte Session übernommen werden kann.

ArtikelserieTeil 1: Die zehn größten Sicherheitslücken im Web – Teil 1: OWASP Top 10, Platz 1 – 2Teil 2: Die zehn größten Sicherheitslücken im Web – Teil 2: Platz 3 – 6Teil 3: Die zehn größten Sicherheitslücken im Web – Teil 3: Platz 7 – 10

Session Hijacking

Damit wir uns mit Session Hijacking beschäftigen können, sollten wir zunächst verstehen, wie eine Session genau funktioniert. Zur Veranschaulichung dient Abbildung 1.

Abb. 1: Beim Session Hijacking wird die Session-ID des Opfers abgehört und dann zum Zugriff auf das eigentlich geschützte System genutzt

Vereinfacht gesehen ist eine Session nicht mehr als ein Array aus Daten, die zu einer eindeutigen ID zugeordnet sind. Der Zugriff auf diese Sessiondaten ist prinzipiell jedem möglich, der diese ID kennt, eine weitere Absicherung erfolgt standardmäßig nicht, bzw. muss manuell implementiert werden. Eine Möglichkeit wäre z. B. das Binden der IP-Adresse an die Session, sodass nur eine bestimmte IP Zugriff auf diese Session hat. Gerade mit der steigenden Anzahl mobiler Zugriffe ist dies aber auch ein Problem, da sich unterwegs doch sehr schnell und häufig die IP-Adressen ändern können und man sicherlich keinem User zumuten möchte, sich bei jedem Wechsel neu einloggen zu müssen. Eine Absicherung über den Useragent ist auch nicht sicher, da dieser problemlos von jedem Angreifer manipuliert werden kann. Es muss also sichergestellt werden, dass Session-IDs gar nicht erst einem Dritten bekannt werden und somit kein Angriff stattfinden kann.

Wie wird eine Session-ID überhaupt generiert? Hierfür ist in der php.ini [1] die Einstellung session.hash_function verantwortlich. Ist dies nicht explizit gesetzt, nutzt PHP per Default md5, um die Hash-ID zu generieren, was eine neue Session-ID von einem Angreifer relativ einfach vorhersehbar macht. Durch das Setzen auf eine bessere Hash-Funktion wie sha256 ist es sehr viel schwerer, an die generierte Session-ID zu kommen.

Der beste Hash-Algorithmus hilft aber leider nicht, wenn die Session-IDs offen lesbar im Netz publiziert werden. So kommt es nicht selten vor, dass Us...

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