Internet-Sicherheit im 21. Jahrhundert: heise.de

Der Heise Verlag ist seit vielen Jahren im Internet zu finden und von der Thematik her mit heise.de eine der ersten Adressen, wenn es um publizierte Sicherheit bzw. Sicherheitslücken geht. Angesichts der langjährigen Präsenz und der (angenommenen) Erfahrung bei Heise, bin ich doch etwas erstaunt darüber, dass die Benutzerkonten nur ungenügend vor Angriffen geschützt sind und u.a. die Verbreitung des drahtlosen Internets vollkommen ignoriert wird.


Das Login zum Benutzerkonto wird selbstverständlich verschlüsselt durchgeführt. Hierbei hat der Benutzer die Wahl ob die IP-Adresse mit im Session-Cookie gespeichert wird oder nicht.
heise.de - Login - IP-Adresse
Wozu gibt es denn diese Wahlmöglichkeit? Wird die Nutzung des Benutzerkontos an eine IP-Adresse gebunden, so muss ein Man-in-the-Middle im gleichen Netzwerk sitzen, um erfolgreich zu sein. Ein Angreifer müsste also z.B. im gleichen Büro arbeiten, in dem alle Angestellten über eine IP-Adresse mit dem Internet verbunden sind.

Seit der Verbreitung des drahtlosen Zugangs zum Internet, hat sich die Bedrohungslager stark verändert. Die meisten Benutzer erwarten, immer und überall die Möglichkeit zu haben, das Internet zu nutzen, egal ob es am Flughafen oder im ICE ist, im Hotel oder einem Internetcafe. Die Bindung an die IP-Adresse greift hier also nicht und bietet keinen ausreichenden Schutz.

Wenn ich mir die Cookie-Flags anschaue, so vermisse ich elementare Schutzmechanismen bei Heise…
cookie-flag-heise-k
die es z.B. bei XING gibt:
cookie-flag-xing-k
Das “HttpOnly” sorgt dafür, dass der Cookie nicht per JavaScript (Cross-Site Scripting) ausgelesen werden kann und der zweite Eintrag besagt, dass die Daten des Cookie nur verschlüsselt übertragen werden dürfen.

Wer also einen Internetzugang benutzt in dessen Netz er nicht alleine ist, der muss bei dem fehlenden Flag für die Verschlüsselung damit rechnen, dass ein Angreifer in sein heise.de-Konto eindringen kann.

Ich zitiere mich mal wieder selber:

Warum wird denn die Kommunikation zwischen Server und Client verschlüsselt?

Ohne Verschlüsselung sind Web-Daten für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da hiermit die Inhalte unabhängig vom Netz verschlüsselt werden.

Besser könnte ich es nicht in Worte fassen, deshalb als Zitat aus Wikipedia.
Quelle: http://de.wikipedia.org/wiki/Https



Hat der Man-in-the-Middle den Zugriff auf das heise.de-Benutzerkonto erlangt, so kann er ohne Probleme das Passwort und die E-Mail-Adresse ändern:
heise.de - Passwort und E-Mailadresse ändern
Eine solche Änderung sollte immer mit der Abfrage des aktuellen Passwortes authentifiziert werden müssen. Wird es nötig die E-Mail-Adresse zu ändern, so ist es natürlich wenig sinnvoll die Aktivierungs-E-Mail nur an die alte Adresse zu senden, weil es durchaus möglich ist, dass der Benutzer gar nicht mehr auf diese zugreifen kann, z.B. bei einem Wechsel des DSL-Anbieters, von dem die E-Mail-Adresse verwaltet wird. Aber trotzdem sollte zusätzlich eine E-Mail auch an die alte Adresse gesendet werden, um die Änderung durch einen Angreifer bemerken zu können.


Wenn sogar Heise, die sich auch mit IT-Sicherheit beschäftigen, solche Elementarteilchen vermissen lässt, dann wundert man sich kaum über die Fehler anderer Seiten — über die auch heise.de berichtet.

3 comments

  1. Frage zu HttpOnly:

    Unterstützen das jetzt alle Browser? Ich ältere (2008) Posts über HttpOnly gefunden, wo das über XMLHttpObject umgangen werden konnte. Neuere Artikel sind mir dazu aber nicht aufgefallen.

  2. Aktuelle Browser unterstützen HttpOnly, ab welcher jeweiligen Version, dazu kann ich nichts sagen. Wer nicht gerade mit einem IE 5.5 unterwegs ist, der sollte sich keine Sorgen machen müssen.

    Browsers Supporting HttpOnly” (owasp.org)
    (Liste ist von Februar 2009.)



    Es gibt aktuell einen Exploit für Apache 2.2.0 bis 2.2.21:

    Apache httpOnly Cookie Disclosure” (exploit-db.com)

    CVE-2012-0053” (cve.mitre.org)

    Die ursprüngliche Meldung findet man nur noch im Cache von Google:
    Apache httpOnly Cookie Disclosure

  3. Danke.

    Zum Thema Apache: Das was ich aktuell benutze ist Tomcat, wo ich auch erfreut war festustellen, dass anscheinend Sessioncookies in Tomcat 7 per default HttpOnly sind.

Comments are closed.