Cookies selbst setzen
Volvic
- https
0 Tom0 Ingo Turski0 wahsaga
Hallo,
kurze Frage: Kann sich ein User ein Cookie, dass er eigentlich nie erhalten hat, selbst setzen bzw. seinen Browser so manipulieren, dass er dieses Cookie, das er eigentlich nicht von diesem Server erhalten hat, dem Webserver als "erhalten" übergibt?
Es geht darum, ob eine Authentifizierung in folgender Form sicher wäre:
Passworteingabe -> wenn korrekt, cookie "admin" setzen -> bei jedem zugriff wird geprüft, ob cookie "admin" existiert, wenn ja zugriff erlauben.
Wenn der User sich den Cookie jetzt aber selber setzt, ohne dass er das Passwort eingibt, wäre das ja ne mörderische Sicherheitslücke.
Eigentlich kann sich ja jeder die Sources der freien Browser so hinmanipulieren, dass das funktioniert, oder gibt es da noch in irgendeiner Form eine Blockade?
Googeln und Wiki haben leider nicht weitergeholfen, und nein, Sessions kann ich stattdessen nicht verwenden ;-)
Danke.
Hello,
kurze Frage: Kann sich ein User ein Cookie, dass er eigentlich nie erhalten hat, selbst setzen bzw. seinen Browser so manipulieren, dass er dieses Cookie, das er eigentlich nicht von diesem Server erhalten hat, dem Webserver als "erhalten" übergibt?
Es geht darum, ob eine Authentifizierung in folgender Form sicher wäre:
Passworteingabe -> wenn korrekt, cookie "admin" setzen -> bei jedem zugriff wird geprüft, ob cookie "admin" existiert, wenn ja zugriff erlauben.
So ein Cookie wäre bei einer wichtigen Seite einem Selbstmordversuch gelichzusetzen.
Mindestens mit einem Webserver (der ja als XAMPP auf jedem >= 586er lauffähig sein kann) kann man sich das selber bauen. Hier hilft nur ein Zertifikat. Die beiden Bedingungen, die dieses "sicher" machen, sind 'zeitliche Gültigkeitsbeschränkung' und 'genügend lang'.
Wenn Du als Cookie also einen 16-stelligen Code (jede Stelle 256 Möglichkeiten) übersendest, und auf deinem Server dann prüfst, wann dieser "Schlüssel" erteilt wurde, hast Du eine befriedigende Sicherheit. Das Erraten bleibt trotzdem möglich, aber eben mit einer sher geringen Wahrscheinlichkeit.
Ob Cookies aber in ihren Werten alle 256 Zeichen enthalten dürfen, habe ich nicht geprüft. Aber selbst bei 64 sollte es noch eine ausreiichende Sicherheit gewährleisten.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hi,
Ob Cookies aber in ihren Werten alle 256 Zeichen enthalten dürfen, habe ich nicht geprüft.
Dürfen vielleicht schon, nur funktioniert das dann nicht. Bereits Groß/Kleinschreibung führt in einigen Browsern zu Problemen.
Aber generell: ob ein - hier wirklich notwendiges - Paßwort nun per POST oder Cookie übertragen wird, läuft auf dasselbe hinaus. Besonders ohne Limitierung (z.B. über eine IP-Sperre) kann es theoetisch gehackt werden, daher sollte es möglichst komplex sein.
Und was das manuelle Setzen von Cookies betrifft: die landen in einem (oder mehreren) reinen Textfiles, die man nach Belieben manipulieren kann.
freundliche Grüße
Ingo
hi,
Ob Cookies aber in ihren Werten alle 256 Zeichen enthalten dürfen, habe ich nicht geprüft.
Dürfen vielleicht schon, nur funktioniert das dann nicht. Bereits Groß/Kleinschreibung führt in einigen Browsern zu Problemen.
Hier bitte nicht name und value in einen Topf schmeißen.
Value wird von PHP bei Nutzung von setcookie() automatisch urlencoded, also darf man da m.E. wirklich _alles_ reinpacken.
Zum Namen des Cookies drückt sich die im Manual verlinkte Cookie-Spezifikation von NetScape auch nicht spezifischer aus, außer das "characters excluding semi-colon, comma and white space" erlaubt sind, und das bei anderen Zeichen eben eine Kodierung "recommended" sei.
Mich auch noch durch den ebenfalls verlinkten RFC zu wühlen, fehlt mir gerade die Muße.
Aber gennerell dürftest du schon recht haben, es ist empfehlenswert, zwecks Kompabilität auf Sonderzeichen im Namen des Cookies zu verzichten.
gruß,
wahsaga