Die Behandlung von Cookies ist ein Minenfeld

 (grayduck.mn)
3 Punkte von GN⁺ 2024-11-22 | 1 Kommentare | Auf WhatsApp teilen
  • HTTP-Cookies sind das grundlegende Mittel zur Aufrechterhaltung von Zustand im Web, aber Browser, Server und Standardbibliotheken weichen bei erlaubten Zeichen und der Fehlerbehandlung voneinander ab, was zu realen Ausfällen führen kann
  • Die RFC-6265-Familie legt unterschiedliche Bedingungen für von Servern gesendete Set-Cookie-Werte und von Browsern akzeptierte Werte fest, und mit document.cookie erzeugte Werte kollidieren mit Annahmen serverseitiger Parser
  • Firefox, Chromium und Safari unterscheiden sich bei der Behandlung von Leerzeichen, Anführungszeichen, Kommas, Backslashes und Unicode; Safari zeigt dabei das Verhalten, bei verbotenen Zeichen nicht das gesamte Cookie zu verwerfen, sondern nur den vorderen Teil zu speichern
  • Go kann vom Browser akzeptierte JSON-Cookies stillschweigend auslassen, Python SimpleCookie kann das Laden nach einem unverständlichen Cookie abbrechen, und auch PHP, Ruby und Rust unterscheiden sich jeweils in ihren erlaubten Bereichen
  • Ein einziges Unicode-Cookie kann auf großen Websites wie Facebook, Netflix, Okta, WhatsApp, AWS oder Apple Support 400/500-Fehler oder Teilausfälle auslösen, daher müssen Cookie-Spezifikation und Bibliotheksverhalten klarer aufeinander abgestimmt werden

Cookies, die Browser annehmen, Go aber nicht lesen kann

  • Cookies sind Daten, die entweder über JavaScript mit document.cookie oder von einem HTTP-Server gesetzt werden und bis zum Ablauf weiterhin in passende HTTP-Anfragen aufgenommen werden
  • Das Beispiel-JavaScript speichert einen JSON-String unverändert als Session-Cookie-Wert
    • Der Wert hat die Form {"ginger":"snap","peanutButter":"chocolate chip","snicker":"doodle"}
    • Beim Speichern von JSON in Cookies wird oft eine Base64-Serialisierung verwendet, aber Browser setzen diesen Wert problemlos und senden ihn im Cookie-Header mit
  • Das Problem entsteht, wenn dieses Cookie an Code weitergegeben wird, der die Go-Standardbibliothek verwendet
    • Der Go-Parser kann dieses Cookie nicht interpretieren
    • Das Scheitern propagiert kaskadenartig in höhere Ebenen des Stacks

Zwei widersprüchliche Maßstäbe in der RFC

  • Cookies wurden über RFC 2109, RFC 2965 und RFC 6265 definiert; derzeit gibt es eine in Überarbeitung befindliche Draft-Version
  • Die RFC behandelt Cookie-Werte in zwei Bereichen unterschiedlich
    • Section 4.1.1 schließt in Werten, die Server per Set-Cookie senden, Steuerzeichen, Leerzeichen, doppelte Anführungszeichen, Kommas, Semikolons, Backslashes usw. aus
    • Section 5.6 erlaubt Browsern beim Parsen von Set-Cookie-Strings deutlich mehr, solange keine Steuerzeichen enthalten sind
  • Der zentrale Konflikt besteht darin, dass Werte, die Server senden sollen, und Werte, die Browser akzeptieren sollen, nicht aufeinander abgestimmt sind
    • Wenn Browser nur Cookies akzeptieren würden, die der Server selbst gesetzt hat, wäre die Auswirkung gering, aber auch document.cookie kann Cookies erzeugen
    • Der Standard legt nicht klar fest, ob Standardbibliotheken, die den Cookie-Header verarbeiten, so tolerant wie ein User Agent oder so strikt wie ein Server sein sollen

Unterschiede bei zulässigen Cookie-Werten je Browser

  • Firefox

    • Die Prüfung von Cookie-Werten in Firefox erlaubt einige Zeichen, die RFC 6265 eigentlich verbietet
    • Folgende laut RFC normalerweise ausgeschlossene Zeichen werden akzeptiert
      • 0x09 horizontaler Tabulator
      • 0x20 Leerzeichen
      • 0x22 doppeltes Anführungszeichen
      • 0x2C Komma
      • 0x5C Backslash
    • Dieses Verhalten wurde historisch zur Kompatibilität mit Chrome eingeführt und ist in beiden Codebasen verblieben
    • Die Einstellung network.cookie.blockUnicode kann Werte ab 0x80 ablehnen; die zugehörige Arbeit wird in bug 1797231 verfolgt
    • Das Problem mit der Zulassung von 0x7F wurde in bug 1797235 in Firefox 108 behoben

  • Chromium

    • Chromium lehnt in Cookie-Werten nur Steuerzeichen und Semikolons ab
    • Damit ist es etwas strenger als Firefox und akzeptiert den horizontalen Tabulator 0x09 nicht
    • Anders als die RFC akzeptiert und sendet es Leerzeichen, doppelte Anführungszeichen, Kommas, Backslashes und Unicode-Zeichen erneut mit

  • Safari / WebKit

    • Der Code zur Cookie-Speicherung in Safari befindet sich in dem Closed-Source-Bestandteil CFNetwork und lässt sich daher nur schwer direkt prüfen
    • Tests, bei denen per JavaScript Cookie-Werte von 0x00 bis 0xFF gesetzt wurden, zeigen, dass Safari folgende Werte zulässt
      • 0x09 horizontaler Tabulator
      • 0x20 Leerzeichen
      • 0x22 doppeltes Anführungszeichen
      • 0x5C Backslash
    • Safari erlaubt weder 0x7F delete noch 0x80-FF high ASCII / Unicode-Zeichen
    • Laut RFC soll bei Steuerzeichen das gesamte Cookie ignoriert werden, Safari übernimmt jedoch den Wert bis zu der Stelle vor dem verbotenen Zeichen
    • Beobachtet wurde auch ein Safari-Bug, bei dem beim Setzen von -- , -- Leerzeichen rund um das Komma entfernt werden

Unterschiede beim Parsing in Sprachen und Standardbibliotheken

  • Go

    • Gos Cookie-Code orientiert sich relativ eng an der RFC-Formulierung für Werte, die Server per Set-Cookie senden
    • Häufige Leerzeichen und Kommas aus der Praxis werden akzeptiert, doppelte Anführungszeichen, Semikolons und Backslashes jedoch nicht
    • Wenn der Beispiel-Cookie-Header ein JSON-Cookie enthält, bleiben im Ergebnis von request.Cookies() nur cookie1=foo und cookie3=bar übrig
    • Das vom Browser akzeptierte cookie2 verschwindet stillschweigend, ohne Exception oder expliziten Fehler

  • PHP

    • PHP hat keine native Funktion zum Parsen von Cookies, weshalb sich der exakte zulässige Bereich schwer eindeutig festlegen lässt; Tests zeigen jedoch ein inkonsistentes Verhalten bei Steuerzeichen
    • Werte wie 0x00-0x09 und 0x0D carriage return funktionieren
    • Bei 0x10 data link escape oder 0x7F delete liefert PHP einen 400 Bad Request-Fehler
    • Auch Unicode-Cookies erscheinen in der Testausgabe

  • Python

    • Pythons http.cookies.SimpleCookie bricht das Laden nach einem JSON-Cookie stillschweigend ab
    • Bei der Beispieleingabe bleibt in der Ausgabe nur cookie1=foo erhalten
    • Wenn eine Subdomain ein problematisches Cookie für die Basisdomain setzen kann, kann ein einziges solches Cookie die gesamte Cookie-Verarbeitung der Website beschädigen
    • Auch die Behandlung von Steuerzeichen ist unregelmäßig
      • Einige Steuerzeichen werden als leerer Wert geladen
      • Wenn vor und nach dem Wert aa angefügt wird, wird das Cookie mit Steuerzeichen nicht geladen

  • Ruby

    • Rubys CGI::Cookie.parse scheint beim Parsen sehr tolerant zu sein
    • Es akzeptiert Steuerzeichen, Tabulatoren, doppelte Anführungszeichen, Kommas, Backslashes, 0x7F und Unicode-Zeichen und wendet beim Auslesen aus dem Cookie-Jar Percent-Encoding an
    • Dieser Ansatz könnte in der Cookie-Welt fast optimal sein, aber Code, der per document.cookie setzt, erwartet möglicherweise keinen percent-encodierten reflektierten Wert

  • Rust

    • Rust bietet keine eingebaute Cookie-Behandlung; als Referenz wurde daher das verbreitete cookie-Crate betrachtet
    • Das cookie-Crate in der Standardkonfiguration gehört eher zur tolerantesten Seite und scheint übergebene UTF-8-Strings zu akzeptieren

Sichtbare Auswirkungen auf realen Websites

  • Das Problem wurde entdeckt, als auf einer Testseite ein Update einer Third-Party-Bibliothek manuell validiert wurde
    • Es handelte sich um eine Änderung, die sich nur schwer mit automatisierten Tests erfassen lässt
    • Wäre sie unverändert ausgerollt worden, hätten spätere Besucher beschädigte Cookies erhalten und wären bis zu einem Rollback des Updates und dem Löschen der Cookies durch schwer erklärbare Fehler ausgesperrt gewesen
  • Das Problem ist nicht auf kleine Websites oder bestimmte Frameworks beschränkt
  • Wenn man in der Browser-Konsole wie folgt ein Unicode-Cookie für eine Domain setzt, können mehrere große Websites beschädigt werden
    • document.cookie="unicodeCookie=🍪; domain=.grayduck.mn; Path=/; SameSite=Lax"
  • Beobachtet wurden unter anderem folgende Fälle
    • Facebook: Eine Fehlerseite wird angezeigt und auch Bilder sind beschädigt
    • Instagram und Threads: Es tritt ein einfacher 500-Fehler auf
    • Netflix: Gibt den Fehler NSES-500 zurück und auch die Hilfeseite ist beschädigt
    • Okta: Alle Login-Seiten liefern 400-Fehler
    • WhatsApp: „whatsapp error“ wird angezeigt
    • Amazon: Größtenteils funktionsfähig, aber einige Funktionen brechen zufällig
    • AWS: Die Login-Konsole liefert 400-Fehler und fällt aus
    • Apple Support: Kann die Geräteliste nicht laden
    • Best Buy: Navigation funktioniert, Suche jedoch nicht
    • eBay: Größtenteils behoben, aber einige Teile liefern weiterhin 400-Fehler
    • Home Depot: Behebung geplant
    • Intuit: Die einzige Website, die die Fehlerursache identifizierte
    • Outlook: Ein weiterer Fall von 400-Fehlern

Schwierige Korrekturen zwischen Standard und Kompatibilität

  • Probleme in einer 30 Jahre alten Basisspezifikation zu beheben, ist äußerst schwierig, und für dieses Problem gibt es möglicherweise keine gute Lösung
  • Auf Browser-Seite wurde geprüft und daran gearbeitet, solche Cookies zu blockieren
  • Einseitiges Blockieren ist wegen Kompatibilitätsproblemen komplex
    • Nicht-ASCII-Cookies kommen insgesamt in weniger als 0,01 % aller Cookies vor
    • Telemetrie zeigt, dass sie in Ländern wie Argentinien, Mexiko und Finnland deutlich häufiger auftreten
    • Mozilla hat die schnell aktivierbare Einstellung network.cookie.blockUnicode implementiert, schaltet sie aber wegen Verhaltensunterschieden zu Chromium nicht ein
  • Auch serverseitige Korrekturen könnten möglich sein, betreffen aber Millionen Websites sowie die interne Fehlerbehandlung in Sprachen und Frameworks
    • Bei Anbietern wie Facebook oder Netflix lassen sich möglicherweise Gegenmaßnahmen umsetzen, aber durchschnittliche Website-Betreiber haben oft weder Zeit noch Möglichkeiten dafür
  • Eine grundlegende Lösung bestünde darin, dass die IETF HTTP Working Group die Cookie-Spezifikation intern angleicht und streng festlegt, wie Cookie-Verarbeitungssysteme arbeiten sollen
    • Ob Nicht-ASCII-Zeichen erlaubt sind, sollte auf Server-Seite und bei User Agents gleich behandelt werden
    • Die Verarbeitungsschritte von Browsern, Sprachen und Frameworks sollten wie in modernen W3C-Standards wie Content Security Policy ausdrücklich beschrieben werden
    • Dass ein einziges fehlerhaftes Cookie auch die Verarbeitung anderer Cookies stoppt, ist schwer akzeptabel, weil es zu verschiedensten unerwarteten Ausfällen führen kann

Vorgeschlagenes Verfahren zur Cookie-Verarbeitung

  • Ausgehend von field-value wird anhand von ; und , eine Liste von raw-cookie-pair-Elementen gebildet, wobei das Komma nicht als Synonym für das Semikolon behandelt wird
  • Jedes raw-cookie-pair wird in folgender Reihenfolge verarbeitet
    • Wenn kein = vorhanden ist, wird zum nächsten Pair weitergegangen
    • Führende und nachfolgende Leerzeichen werden entfernt
    • Vor dem ersten = wird cookie-name-octets, danach cookie-value-octets verwendet
    • Beginnt der Wert mit einem doppelten Anführungszeichen, wird ein führendes Anführungszeichen entfernt; existiert ein abschließendes Anführungszeichen, wird auch dieses entfernt
    • Wenn Name oder Wert eine Form haben, die der Server nicht akzeptieren kann, wird dieses Pair übersprungen
    • Das verbleibende Tupel [cookie-name-octets, cookie-value-octets] wird serverdefiniert weiterverarbeitet
  • Zusätzlich wird vorgeschlagen, dass Server Tupel ablehnen, deren Cookie-Name kein Token ist, und Cookie-Werte verwerfen, die Oktette außerhalb von cookie-octet enthalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-22
Meinungen auf Hacker News

  • Cookies sind voller seltsamer Fallstricke und unbequemer Verhaltensweisen, funktionieren aber in 99,95 % der Fälle gut. Mein liebstes Cookie-Minenfeld ist Cookie Shadowing: Wenn man Cookies mit demselben Namen setzt, die sich nur in wichtigen Attributen wie Domain oder Pfad unterscheiden, entstehen gleichzeitig mehrere nahezu gleiche Cookies, und weder Backend noch JS haben eine Möglichkeit zu unterscheiden, welches welches ist.
    Man kann auf https://example.com/somepath gehen und Folgendes in die Browser-Konsole eingeben:
    document.cookie = "foo=a";
    document.cookie = "foo=b; domain=.example.com";
    document.cookie = "foo=c; path=/somepath";
    document.cookie
    Bei mir war das Ergebnis 'foo=c; foo=a; foo=b'

    • In der Firma hat irgendjemand, keine Ahnung wer, Staging- und Entwicklungsumgebungen auf dieselbe Domain gelegt, und der gesamte riesige Konzern folgt diesem Muster.
      Das ist wirklich ein gewaltiger Fehler.
    • Ich habe das Gefühl, dass sich damit ein großer Teil des seltsamen Verhaltens erklären ließe, das entsteht, wenn man im selben Browser auf einer Website mehrere Konten nutzt.
    • Wenn man sich unter /somepath befindet, wirkt es ziemlich plausibel, von den drei Werten den spezifischsten, also C, zu bekommen. Da alle Werte der Reihe nach zurückgegeben werden, kennt man sowohl den pfadspezifischen als auch den globalen Wert; das fühlt sich wie der beste Kompromiss an.
      Allerdings gefällt mir der magische document.cookie-Setter nicht, aber das Ding ist nun einmal schon fast 30 Jahre alt.
    • Zur Info: Technisch gesehen ist der Punkt vor der Domain nicht erlaubt und wird ignoriert: https://www.rfc-editor.org/rfc/rfc6265#section-4.1.2.3
      Kürzlich kam das Thema wieder hoch, als jshttp/cookie die Validierung verschärft hat: https://github.com/jshttp/cookie/pull/167
      Nach diesem PR wurde die Validierung wieder etwas gelockert, ähnlich wie der im Artikel erwähnte Browser-Code.
      Die ursprüngliche Änderung begann bei uns, als wir einen Bug suchten, bei dem ein Cookie-Header durch simples Aneinanderhängen von Strings ohne Encoding gebaut wurde. Gelegentlich enthielten Werte Leerzeichen, wodurch Requests kaputtgingen; um das zu vermeiden, wollten wir Entwicklern die Nutzung von serialize() aus jshttp/cookie empfehlen, stellten aber fest, dass die Validierung dieser Funktion nicht ausreichte, um den von uns gesehenen Bug zu erkennen.
      Als ein Fix vorgeschlagen wurde, entdeckte jemand anderes, dass die Validierung so locker war, dass man JS in das Namensfeld eines Cookies einschleusen und es an anderer Stelle wie einen Wert interpretieren lassen konnte. Das wurde zu einem ziemlich ungewöhnlichen Code-Injection-Pfad.
    • Stimmt, da gibt es wirklich viele Gefahrenquellen. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng behandelt dieses Problem und verwandte Ärgernisse ausführlich.

  • Der Artikel erwähnt den Rust-Ansatz, aber anders als in anderen Sprachen enthält die Rust-Standardbibliothek keine Cookie-Verarbeitung. In Wirklichkeit schaut man sich also das Verhalten des Drittanbieter-cookie-Crates an, und es enthält auch eine Option für Percent-Encoding wie bei Ruby: https://docs.rs/cookie/0.18.1/cookie/

    • So läuft das eben: Wer sich früh einen guten Namen sichert, wird de facto standardisiert.

  • Im HTTP-Protokoll scheinen praktisch zehntausend verschiedene Protokolle zu stecken. Browser und Webserver haben alle möglichen Funktionen angeflanscht, jede mit Spezifikationen und De-facto-Spezifikationen, und all das wird unter dem nahezu universellen Dach HTTP transportiert.
    Der Client kann nicht angeben, mit welcher Version dieser zehntausend Nicht-Spezifikationen er kompatibel ist, und der Server genauso wenig. Der Grund, warum man die Spezifikation nicht upgraden kann, ist, dass die übrigen Clients sie nicht verstehen und es keine Abwärtskompatibilität gibt.
    Übrig bleibt also zufälliges Chaos, auf das sich niemand einigen und das niemand reparieren kann. Und ohne geplante Abschaffung müssen wir schlechte Entscheidungen aus der Vergangenheit weiter mitschleppen.

    • Schuld sind auch miserable Middleware-Geräte, die Protokolle blockieren, die sie nicht verstehen. Nach dem Motto „standardmäßig fehlschlagen lassen ist sicherer“, sodass künftig für immer jeder neue Anwendungstraffic über HTTP getunnelt werden muss, wenn er im echten Internet funktionieren soll.
    • Ehrlich gesagt habe ich mich inzwischen mit dieser Welt abgefunden und bin mir nicht einmal sicher, ob mir eine Welt mit geplanter Abschaffung besser gefallen würde.
    • Wenn man nicht will, dass ein Monopolist saubere Spezifikationen festlegt und willkürlich die Abschaffung erzwingt, muss man als Preis dafür Anarchie akzeptieren.

  • Vor etwa 10 Jahren habe ich in einem Projekt Cookie-basierte Sessions implementiert und mich wirklich abgemüht zu debuggen, warum die Authentifizierung in Safari funktionierte, in Chrome aber nicht. Ich weiß nicht mehr genau, welcher von beiden es war, aber ein Browser setzte das Cookie überhaupt nicht, wenn das Format nicht stimmte.
    Wir machten nichts besonders Seltsames; meiner Erinnerung nach war es so etwas wie der Unterschied zwischen - und _.

    • Ich glaube, zwischen Safari und Chrome gab es einen Unterschied bei der Groß-/Kleinschreibung. Vielleicht war es der Set-Cookie-Header.
      Früher konnte ich wegen dieses Problems einmal kein camelCase für Cookie-Keys verwenden.
      Über die Suche finde ich das genaue Issue aber nicht mehr.

  • Schon kurz nach Einführung von Cookies galt als vernünftige Nutzung wohl, nur undurchsichtige Tokens darin abzulegen, damit der Server den Client beim nächsten Mal wiedererkennt, und alles Weitere serverseitig zu speichern.
    Ich verstehe nicht, warum es ein Problem sein soll, dass der Client prinzipiell Werte verarbeiten kann, die der Server niemals senden würde. Man sendet solche Werte einfach nicht und muss sich keine Rätsel wie „Was passiert, wenn man das doch sendet?“ machen.

    • Cookies sind alte Technik. Sie gehörten zu den ersten Dingen, die in den 90ern eingeführt wurden, als das Web noch jung war, und schlechte Ideen haben sich mehrfach wiederholt.
      Trotzdem sind sie der einzige Ort zum Speichern undurchsichtiger Tokens, also muss man sie für Authentifizierung verwenden.

  • Das Parsen von Cookie-Headern ist ein Durcheinander. Der „Standard“ spiegelt das Verhalten, das in der Praxis existiert, nicht wider; Backend-Server, Libraries und Frameworks akzeptieren jeweils unterschiedliche Formate, und Browser machen noch einmal etwas anderes.
    Wenn man Frontend und Backend vollständig kontrolliert, ist das kein großes Problem, aber sobald man unterschiedliche Dinge miteinander integrieren muss, wird die Situation sehr schnell absurd.

  • Cookies wirken wie ein großes, komplexes Chaos, und zugleich sind sie wegen der Abwärtskompatibilität kaum noch zu ändern. In so einem Fall wäre es vielleicht richtig, einen komplett separaten neuen Mechanismus zu schaffen.
    Man könnte zum Beispiel einen Mechanismus wie NewCookie neu spezifizieren und von Grund auf so entwerfen, dass er konsistent funktioniert. Moderne Sicherheitsmaßnahmen könnten eingebaut werden, dazu eine strengere Spezifikation und ordentliche Unicode-Unterstützung.

    • Interessant, dass NewCookie erwähnt wird; tatsächlich gab es bereits den inzwischen verworfenen Set-Cookie2-Header: https://stackoverflow.com/q/9462180/3474615
    • NewCookie entspricht grob dem Local Storage des Browsers.
      Zumindest für einige Anwendungsfälle ist das so, auch wenn es natürlich nicht direkt in Header integriert ist.
    • Das Kernproblem scheint zu sein, dass Cookies zu eng mit Tracking verflochten sind. Wenn man heute bessere Cookies bauen wollte, würde man vermutlich von Datenschutzbefürwortern blockiert, die nicht wollen, dass ein solches Konzept überhaupt existiert.
      Weil Cookies bereits existieren, sind wir an sie gebunden.
    • Der sicherste Ort, um clientseitigen Zustand zu speichern, sind DOM und URL. Das deckt nicht alle Anwendungsfälle ab, aber Dinge wie den Bereich, in dem man auf vorab autorisierte Links in E-Mails klickt, schon.
      Ich habe einen ganzen Monat damit verbracht, einem Problem nachzugehen, bei dem iOS Safari willkürlich Cookies von Domains verschluckt hat, die von Kunden kontrolliert werden. Bei Domains wie Google, Twitter oder Facebook habe ich nie gesehen, dass Sitzungszustand auf diese Weise verschwindet.
    • Der Name sollte besser sein als NewCookie. Vorschläge wie SuperCookie, UltraCookie oder BetterCookie wären möglich.
      Etwas ernsthafter: Man sollte das Wort Cookie vermeiden und dem Ganzen einen völlig anderen Namen geben. An dem Wort Cookie hängt zu viel Ballast.

  • Der Autor begann damit, das Ergebnis von JSON.stringify in ein Cookie zu stecken; überraschend war eher, dass es nicht daran lag, dass jemand ein Semikolon in das stringifizierte JSON eingefügt hatte.
    Die meisten Probleme rund um Cookies scheinen zu entstehen, wenn man versucht, beliebige Benutzereingaben in Cookies zu stecken. Das sollte man nicht tun. Wenn man nur alphanumerische ASCII-Strings fester Länge verwendet, wie bei Authentifizierungstokens, ist es in Ordnung.

  • Ich stimme zu, dass das ein ziemliches Minenfeld ist.
    Als Entwickler besteht der Workaround darin, Werte als URL-sicheres Base64 zu kodieren. Dann bekommt man rohe Bytes und kann intern jede gewünschte Repräsentation verwenden. Allerdings hat man, wie im Artikel gesagt, keine 100%ige Kontrolle. Es ist schließlich ein User Agent, und das sollte auch so sein.
    Ich wünschte, mehr User Agents würden Standardkonformität gegenüber „Bytes auf der Leitung und Beten“ bevorzugen. Die 400-Antworten in den Screenshots sind spezifikationskonforme Antworten. Besser wäre es wohl gewesen, wenn Header von Anfang an UTF-8 gewesen wären oder zunächst ASCII und später UTF-8 erlaubt worden wäre. Ersteres ist kausal allerdings schwierig, und Letzteres kann weiterhin Probleme verursachen, weil dadurch Werte legal würden, die ursprünglich illegal waren.

    • Wenn man URL-sicheres Base64 sagt, muss man unbedingt genau angeben, was gemeint ist. base64url-Encoding ist in etwa 3% der Fälle nicht kompatibel mit base64 plus URL-Encoding; in der Entwicklung übersieht man das leicht, aber in Produktion knallt es garantiert.
    • In Cookie-Werten dürfen die Zeichen =, / und + vorkommen, daher kann man auch die Standard-Base64-Kodierung verwenden. :)

  • Der Artikel macht sich über Postels Gesetz lustig, aber wenn die Seite, die Cookies setzt, beim Senden konservativ gewesen wäre, hätte es diesen Artikel gar nicht gebraucht.

    • Der Spott ist verdient. Postels Gesetz war eine schreckliche Idee und hat überall Minenfelder geschaffen.
      Manchmal sind diese Minen nicht nur einfache Bugs, sondern große Sicherheitslücken.
      Wenn ein Client Daten sendet, die nicht der Spezifikation entsprechen, ist das ein Bug und sollte behoben werden. Es darf niemals selbstverständlich werden, dass der Server die Absicht errät und es akzeptiert.
    • Das Problem an Postels Gesetz ist genau, dass Sender niemals konservativ sind. Die Detailverhalten, die die meisten Empfänger akzeptieren, werden letztlich von Sendern genutzt.