Query-String zerlegen

Ein Query-String darf denselben Namen mehrfach tragen, und `tag=a&tag=b` ist die übliche Schreibweise für eine Mehrfachauswahl. Wer ihn in ein Wörterbuch einliest, verliert dabei alles außer dem letzten Wert — ein Datenverlust, den keine Fehlermeldung anzeigt.

Hier bekommt jedes Vorkommen eine eigene Zeile. Das ist wichtiger, als es klingt, denn die Frameworks sind sich uneinig: PHP will `tag[]=a&tag[]=b`, Rails deutet Klammern anders, Express hat mehrere Modi. Wenn eine Mehrfachauswahl nur teilweise ankommt, liegt es fast immer hier.

Die Eingabe muss keine ganze Adresse sein. Ein Query-String mit oder ohne führendes Fragezeichen funktioniert ebenso wie eine vollständige URL, aus der der Query dann herausgenommen wird — praktisch, denn was man aus einem Analytics-Export oder einem Log kopiert, ist selten die ganze Zeile.

Erkannt wird das daran, ob ein Fragezeichen oder ein Gleichheitszeichen vorkommt. Eine Eingabe ohne beides ist kein Query-String, sondern gewöhnlicher Text, und wird auch nicht so behandelt — eine Regelung, die banal klingt und ohne die eine ganze URL fälschlich als ein einziger Parametername gelesen würde.

In einem Query-String steht `+` traditionell für ein Leerzeichen. Das kommt aus `application/x-www-form-urlencoded`, dem Format, in dem HTML-Formulare absenden, und ist älter als die heutige URL-Spezifikation — überlebt hat es, weil Formulare es tun.

Die Folge ist eine Falle: Ein echtes Pluszeichen in einem Wert muss `%2B` geschrieben werden, sonst verschwindet es. Betroffen sind vor allem Telefonnummern in internationaler Schreibweise und E-Mail-Adressen mit Plus-Adressierung — aus `[email protected]` wird beim Einlesen `a [email protected]`, und die Zustellung scheitert an einer Stelle, an die niemand schaut.

Ein Weiterleitungsziel als Parameter ist der häufigste Fall verschachtelter Kodierung: Der Wert von `next` ist selbst eine URL, deren Schrägstriche und Fragezeichen prozentkodiert sein müssen, damit sie nicht die äußere Adresse zerlegen. Dekodiert wird daraus wieder eine lesbare Adresse.

Hier zeigt sich auch, ob jemand doppelt kodiert hat: Steht im dekodierten Wert noch `%2F`, war die Eingabe zweimal durch einen Kodierer gelaufen. Und wer eine solche Weiterleitung entgegennimmt, sollte das Ziel gegen eine Liste erlaubter Hosts prüfen — offene Weiterleitungen entstehen genau an dieser Stelle.

Standardmäßig werden die Werte dekodiert, denn das ist der Zweck der Seite. Der Schalter für die rohe Form ist trotzdem kein Zierrat: Wenn eine Signatur über den Query-String gebildet wird, zählt genau die kodierte Schreibweise, und ein Unterschied zwischen `%20` und `+` entscheidet dann über Annahme oder Ablehnung.

Ebenso nützlich ist die rohe Ansicht bei der Suche nach doppelter Kodierung. Ein `%2520` im Rohwert ist der eindeutige Beleg dafür, dass irgendwo in der Kette ein bereits kodierter Wert erneut kodiert wurde — im dekodierten Ergebnis sieht man davon nur noch ein verdächtiges `%20`.

`utm_source`, `utm_medium`, `utm_campaign`, `utm_term` und `utm_content` stammen aus Urchin, dem Werkzeug, aus dem Google Analytics hervorging — daher der Name. Sie tun serverseitig nichts; sie sind Text, den ein Analyseskript im Browser ausliest.

Weil sie nichts tun, kann man sie gefahrlos entfernen, wenn man einen Link weitergibt und die Statistik des Absenders nicht mit der eigenen Weitergabe vermischen möchte. Und weil sie in der Adresse stehen, landen sie in Verlaufslisten, in geteilten Links und in Lesezeichen — der Grund, warum manche Newsletter-Links auffällig lang sind.

Adressen landen im Zugriffsprotokoll des Servers, im Browserverlauf, in der Referrer-Kopfzeile beim nächsten Klick und oft in einem Proxy-Log dazwischen. Ein Passwort, ein Sitzungsschlüssel oder ein Token in einem Parameter ist damit an mindestens vier Orten gespeichert, an die niemand gedacht hat.

Für Bestätigungs- und Zurücksetzen-Links, bei denen es sich nicht vermeiden lässt, gilt deshalb: kurze Gültigkeit, einmalige Verwendung, und beim Aufruf sofort aus der Adresse entfernen. Wenn du hier einen Wert siehst, der wie ein Geheimnis aussieht, ist das der Befund — und nicht der Umstand, dass er sich dekodieren ließ.

Ein `?debug` ohne Wert, ein `?a=` mit leerem Wert und ein fehlender Parameter sind drei verschiedene Dinge, und die Frameworks behandeln sie unterschiedlich: mal als leere Zeichenkette, mal als `true`, mal als nicht vorhanden. Hier werden sie als das angezeigt, was in der Zeichenkette steht.

Das ist häufiger relevant, als man denkt. Ein Schalter, der als bloßer Name übergeben wird, kommt in manchen Sprachen als leerer Wert an und wird dort als falsch gewertet — der Parameter ist gesetzt, die Funktion bleibt aus, und in keinem Log steht etwas Auffälliges.

Für den Server ist die Reihenfolge der Parameter fast immer belanglos. Für alles, was den Query-String als Zeichenkette behandelt, ist sie entscheidend: Ein Cache-Schlüssel, eine Signatur oder ein Vergleich zweier Adressen liefern bei vertauschten Parametern unterschiedliche Ergebnisse.

Deshalb sortieren Signaturverfahren wie AWS Signature Version 4 die Parameter, bevor sie hashen, und deshalb normalisieren gute Caching-Ebenen die Reihenfolge. Wenn zwei Adressen dieselbe Seite meinen und trotzdem verschieden behandelt werden, ist das eine der ersten Stellen zum Nachsehen.

Query-Strings aus Logs und Analytics-Exporten enthalten regelmäßig Personenbezug: Suchbegriffe, E-Mail-Adressen als Parameter, Kennungen, die sich einem Konto zuordnen lassen. Weil hier in der Seite zerlegt wird, verlässt nichts davon dein Gerät.

Das ist die Voraussetzung dafür, dass sich ein solcher Export überhaupt mit einem Online-Werkzeug ansehen lässt. Ein Dienst, der auf einem Server zerlegt, hätte die Zeile gesehen und in seinen Protokollen — bei genau der Art von Daten, deren Weitergabe der Grund für die meisten internen Richtlinien ist.

Die andere Seite beantwortet, wohin eine Adresse zeigt: Host, Port, Pfad, Anker. Der Anlass ist ein verdächtiger Link oder eine kaputte Weiterleitung, und der Blick geht auf den Anfang der Adresse.

Hier geht der Blick nach hinten. Der Anlass ist ein Export mit dreißig Parametern, eine Mehrfachauswahl, die nicht ankommt, ein Wert, der doppelt kodiert wurde. Beide benutzen dieselbe Engine, und getrennt sind sie, weil die Erklärungen es sind — Punycode und Zugangsdaten dort, Pluszeichen und wiederholte Schlüssel hier.