Open Source Software

Login Daten im Browser Cookie speichern

Ab und zu schaue ich auf Webseiten in die Cookies und den Local- und Session-Storage. Rein aus Neugier. Am gestrigen Tag habe ich bei der bekannten IT News Seite www.winfuture.de in die Cookies gesehen. Auch diese News Seite speichert Inhalte in Cookies ab. Soweit ist hier alles ganz normal. Nicht normal sind ein paar Cookie Einträge, die man im angemeldeten Zustand besitzt.

Login Daten speichert man nicht in Cookies!

Etwas stutzig wurde ich bei den drei Cookies namens wfv4login, wfv4pass und wfv4id. In diesen Cookies stehen nämlich die Login Daten von meinem persönlichen Account. Ich wiederhole: Es stehen die User ID, Username und ein gehashtes Passwort in den Cookies.

Auf Nachfrage über Twitter erhalte ich eine Antwort vom Winfuture Team, die lautet:

Was ist daran so schlimm?

Alles! Laut Winfuture werden die Daten zur Identifizierung gespeichert. Auch wenn das Passwort verschlüsselt ist: Durch Übernahme der Cookies kann der Winfuture Login übernommen werden.

Login erfolgreich übernommen

In meinem Test habe ich die Cookies einmal von Browser A nach Browser B kopiert. Das Resultat: Ich bin jetzt in beiden Browsern eingeloggt. Übernommen habe ich lediglich die drei Cookies wfv4login, wfv4pass und wfv4id. (Na gut, zwei Cookies reichen auch schon. Ohne Id fehlt nur der vollständige Link zum Profil und den Einstellungen.)

Die Kekse habe ich jetzt manuell übernommen. Doch wer böse Absichten hat, kann sich diese per Cookie-Diebstahl beschaffen und ein Account übernehmen. Siehe dazu auf blog.seibert-media.net/blog/2011/06/22/cookie-diebstahl-unterbinden-internet-security/

Meine Meinung: Grob fahrlässig!

Na klar wird ein Weg zum Identifizieren des Users benötigt. Doch wieso setzen die Entwickler von dem System nicht einfach ein Cookie mit einem Token inkl. IP Vergleich oder Radnom Session? Dieser verrät nichts und kann eindeutig den User wieder Identifizieren, so das ein Auto Login erfolgt. Es gibt hunderte Tutorials, wie man die „Login merken“-Funktion sicher programmiert.

Mein Tipp: Versucht es doch mit einem fertigen Authentification Script, was keine Login Daten im Cookie speichert, sondern nur einen kleinen Token. Zum Beispiel PHPAuth (github.com/PHPAuth/PHPAuth) oder PHP-Auth (github.com/delight-im/PHP-Auth).

Ich hoffe liebes Winfuture.de Team, ihr achtet in Zukunft etwas mehr auf Sicherheit. Wenn ihr Hilfe braucht, gebt mir Bescheid.

Kommentare (6)

  1. Ob im Cookie echte Credentials oder nur Token abgepeichert sind, ist beim Session Hijacking unerheblich. Wichtig ist noch, dass Secure und HttpOnly im Cookie gesetzt sind, damit es vom Client nur über eine sichere Verbindung übertragen und sein Inhalt nicht mit Javascript auslesbar (Cross-Site-Scripting-Gefahr) ist. 😉

  2. Der Aufruf wird keinen Erfolg haben, weil die erst ihr Team fragen und sich mit deren Antwort zufrieden geben werden. Die Agentur wird alles tun, um es zuvertuschen.

    Klarer Fall von: Ich setze ein Framework ein und habe die Konsequenzen nicht verstanden.

    Hype-driven-Development halt 🙂

    @alle,die es sicher haben wollen:

    1x Cookie setzen, ip im servercookie speichern,immer abgleichen, ob ip im cookie zur anfragenden ip gehört.

    Macht man das als Betreiber nicht, handelt man fahrläßig.

    • IP ist zwar gut und sicher aber wenn man sich nicht jeden tag einloggen will ist es schon sinnvoll das nicht zu machen aber man sollte zumindest HTTPS einfügen und den cookie vor scripts schützen.

    • Wenn so eine bekannte News Seite keinen Wert auf einen sicheren Login setzt, dann finde ich das ziemlich schade. Wir können nur Abwarten und Tee trinken. Entweder bleiben die dabei oder machen es sicherer. In meinen Augen sollte so eine laienhafte Umsetzung public gemacht werden.

  3. Ich finde lösungen wie PHPauth und co etwas overkill u.a. da die mit abhängigkeiten noch und nöcher kommen und es geht auch einfacher.
    sessionid generieren, in der serverdatenbank alle nötigen daten der session speichern.

    @benediktg wenn man aber nur ne sID hat, kann man die session remote absägen wenn was schiefläuft. dazu kann man auch wenn man den PWhash hat, ohne weiteres ne offline-bruteforceattacke starten, bcrypt ist schön aber PHP hat nicht ohne grund ne default-cost von 10 fürs pwhashen vorgesehen.

    und während HTTPOnly geht, geht secure nicht da die seite von WF kein HTTPS hat.

Kommentare sind geschlossen.