nicht angemeldet
Moin!
Tach!
Da bei HTTP alles unverschlüsselt über das Netz übertragen wird, liegt hier also der Schwachpunkt. Besser ist daher die Übertragung von Zugriffs-Schlüsseln (und Daten) per HTTPS.
Dann muss die ganze Sioetzung aber schon von vorn herein auf HTTPS laufen, denn einen Wechsel von und zu HTTPS ist wie ein Domainen-Wechsel und den überleben Cookies nicht.
Das ist falsch. Bei Cookies gilt nicht die Same-Origin-Policy, sondern ein deutlich weniger strenger Mechanismus. Ein Cookie für eine Domain gilt, sofern nicht explizit "secure" gemacht, immer für HTTP und HTTPS gleichermaßen.
Ebenso kann man definieren, dass das Cookie nur bei HTTP-Kommunikation verwendet wird (httponly), aber nicht für Javascript lesbar ist. (Es soll aber wohl Angriffsmöglichkeiten geben, die das aushebeln.)
Das Übertragen von Cookies auf andere Seiten (Domains) wird vom Browser üblicherweise nicht unterstützt.
Formulierungsfehler. Der Browser sendet Cookies nur innerhalb einer Domain (plus HTTP/HTTPS-Unterscheidung) wieder zum Server zurück. "Andere Seiten" interessieren dabei nicht, weil die Domain hier das dominante Glied ist.
Domain (ggf. Wildcard-Angabe für alle Third-Level-Domains einer Second-Level-Domain) und Pfad sind die Kriterien, das Protokoll nur ausnahmsweise (siehe oben).
Es ist aber sicherlich per JavaScript möglich, einen Parameter aus der einen Seite in eine andere Seite zu übernehmen.
Aber nicht (so ohne weiteres) domainübergreifend. Sonst lass ich mal deine Bankseite in einem Frame laufen und schaue, was du da so für Cookies verwendest.
Das Javascript, geladen von der Cookiedomain, angewandt auf eine Seite der Cookiedomain, kann problemlos ein Cookie ohne "httponly" auslesen und als Parameter an ein Bild hängen, welches von einer ganz anderen Domain geladen wird. Außerdem könnte Javascript versuchen, direkt ein Cookie mit dem Gültigkeitsbereich einer Drittdomain zu setzen, auch wenn das von Browsern gern mal vereitelt wird.
- Sven Rautenberg