Entschärfung des "Firesheep"-Angriffs in der Anwendungsschicht?

Question

Welche Methoden werden empfohlen, um die "Firesheep"-Methode für Website-Anwendungen zu entschärfen?

Wir haben darüber nachgedacht, und aus Sicht der Benutzerfreundlichkeit kann es für Webentwickler ein Problem sein, den Angriff zu entschärfen, abgesehen von der Verschlüsselung des gesamten Datenverkehrs zu einer Website.

Ein Vorschlag, den wir gemacht haben, war die Verwendung pfadbasierter Cookies, die den Datenverkehr für einen bestimmten Pfad verschlüsseln, auf dem Kontobewegungen oder personalisierte Interaktionen stattfinden. Dies erschwert jedoch die Benutzerfreundlichkeit, da der Rest der Website (der nicht verschlüsselte - nicht authentifizierte) Teil nicht weiß, wer der Benutzer ist.

Hat jemand andere Vorschläge, wie man diesen Angriffsweg entschärfen und gleichzeitig ein brauchbares Maß an Benutzerfreundlichkeit beibehalten kann?

Answer 1

Firesheep ist nichts Neues . Session Hijacking gibt es schon seit mehr als zwei Jahrzehnten. Sie brauchen Ihr Cookie nicht zu "verschlüsseln", das wird von Ihrer Transportschicht erledigt. Cookies müssen immer ein kryptographische Nonce .

Normalerweise setzen Hacker ihre eigenen Cookies, indem sie Folgendes in die Adressleiste eingeben javascript:document.cookie='SOME_COOKIE' FireSheep ist für Skript-Kiddies, die 1 Zeile JavaScript fürchten. Aber es macht diesen Angriff nicht wirklich einfacher auszuführen.

Cookies können missbraucht werden, wenn Sie nicht während der gesamten Dauer der Sitzung HTTPS verwenden, und dies ist ein Teil der OWASP A9 - Unzureichender Schutz der Transportschicht . Aber man kann auch eine Sitzung mit XSS kapern.

1) Verwendung httponly-Cookies . (Dadurch kann JavaScript nicht auf document.cookie zugreifen, aber Sie können immer noch mit xss Session Riding betreiben)

2) Verwenden Sie " sichere Cookies "(Schrecklicher Name, aber es ist ein Flag, das den Browser zwingt, das Cookie nur für HTTPS zu verwenden).

3) Scannen Sie Ihre Webanwendung auf xss mit Sitewatch(kostenlos) o wapiti (offene Quelle)

Vergessen Sie auch nicht CSRF! (Was firesheep nicht anspricht)

Answer 2

Hat jemand versucht, die Vorteile des "Webspeichers" in HTML 5 zu nutzen, um einen gemeinsamen Schlüssel zu speichern (der bei SSL-verschlüsselten Antworten während der Authentifizierung übergeben wird), der von Javascript verwendet wird, um das Sitzungscookie im Laufe der Zeit zu ändern?

Auf diese Weise wären die gestohlenen (unverschlüsselten) Sitzungscookies nur für eine kurze Zeitspanne gültig.

Ich vermute, dass der Webspeicher nach Port (zusätzlich zum Host) segmentiert ist, so dass dies nicht möglich ist. Ich werfe diese Idee nur in den Raum, falls jemand sie ausprobieren möchte.

Answer 3

Ich habe einen interessanten Artikel auf GitHub gefunden, der eine Methode zur Entschärfung des FireSheep-Angriffs beschreibt.

https://github.com/blog/737-sidejack-prevention

Answer 4

Wenn sich der Benutzer anmeldet, speichern Sie die IP-Adresse in der Sitzung.

Bei jeder weiteren Anfrage aus dieser Sitzung wird geprüft, ob die IP-Adresse mit der in der Sitzung gespeicherten übereinstimmt.