Querystring ontleden

Een query string mag dezelfde naam meerdere keren dragen, en `label=a&label=b` is de gewone vorm van een meervoudige keuze. Wie dat in een woordenboek laadt, houdt alleen de laatste waarde over — gegevensverlies waar geen enkele waarschuwing op wijst.

Hier krijgt elk voorkomen een eigen regel. Dat telt zwaarder dan het klinkt, want de frameworks zijn het onderling niet eens: PHP wil `label[]=a&label[]=b`, Rails leest de blokhaken anders en Express heeft er meerdere standen voor. Komt een meervoudige keuze half aan, dan zit de oorzaak vrijwel altijd hier.

De invoer hoeft geen compleet adres te zijn. Een query string met of zonder het vraagteken ervoor werkt net zo goed als een hele URL, waar de query dan uit wordt gehaald — handig, want wat je uit een statistiekexport of een logbestand kopieert is zelden de complete regel.

Het wordt herkend aan de aanwezigheid van een vraagteken of een isgelijkteken. Invoer zonder allebei is geen query string maar gewone tekst en wordt ook niet zo behandeld — een regel die vanzelfsprekend klinkt en zonder welke een compleet adres als één parameternaam zou worden gelezen.

In een query string betekent `+` van oudsher een spatie. Dat komt uit `application/x-www-form-urlencoded`, de vorm waarin HTML-formulieren versturen, en het is ouder dan de huidige URL-specificatie; het heeft standgehouden omdat formulieren het blijven doen.

Het gevolg is een valkuil: een echte plus binnen een waarde moet als `%2B` worden geschreven of hij verdwijnt. Dat raakt vooral internationale telefoonnummers en adressen met subadressering — een `[email protected]` wordt bij het lezen `naam [email protected]`, en de bezorging faalt op een plek waar niemand kijkt.

Een doorstuurdoel als parameter is het meest voorkomende geval van geneste codering: de waarde van `terug` is zelf een URL waarvan de schuine strepen en vraagtekens ontsnapt moeten zijn om het buitenste adres niet te breken. Bij het decoderen wordt het weer een leesbaar adres.

Je ziet hier ook of iemand twee keer heeft gecodeerd: staat er in de gedecodeerde waarde nog een `%2F`, dan is de invoer twee keer door een codeerder gegaan. En wie zo’n doorstuurdoel ontvangt, hoort het tegen een lijst toegestane hosts te leggen — open redirects ontstaan precies op dit punt.

Standaard worden de waarden gedecodeerd, want dat is de bedoeling van de pagina. De schakelaar voor de ruwe vorm is geen versiering: wordt er een handtekening over de query string berekend, dan telt de exacte gecodeerde schrijfwijze, en een verschil tussen `%20` en `+` beslist tussen aannemen en weigeren.

Hij is even nuttig om dubbele codering op te sporen. Een `%2520` in de ruwe waarde is het onweerlegbare bewijs dat er ergens in de keten een al gecodeerde waarde opnieuw is gecodeerd; in de gedecodeerde uitkomst blijft daar alleen een verdachte `%20` van over.

`utm_source`, `utm_medium`, `utm_campaign`, `utm_term` en `utm_content` komen uit Urchin, het pakket waar Google Analytics uit is ontstaan — vandaar de naam. Ze doen op de server niets: het is tekst die een meetscript in de browser uitleest.

Omdat ze niets doen, kun je ze zonder gevolgen weghalen als je een link doorstuurt en de statistiek van de afzender niet met de jouwe wilt mengen. En omdat ze in het adres staan, belanden ze in geschiedenissen, in gedeelde links en in bladwijzers — de reden dat sommige nieuwsbrieflinks absurd lang zijn.

Adressen belanden in het serverlogboek, in de geschiedenis van de browser, in de referrer-header van de volgende klik en vaak in het logboek van een proxy onderweg. Een wachtwoord, een sessiesleutel of een token in een parameter staat dus op minstens vier plekken opgeslagen waar niemand aan heeft gedacht.

Voor bevestigings- en herstellinks, waar het niet te vermijden is, luidt de regel: korte geldigheid, eenmalig gebruik, en meteen na het openen uit het adres halen. Zie je hier een waarde die eruitziet als een geheim, dan is dat de bevinding — niet het feit dat hij zich liet decoderen.

Een `?debug` zonder waarde, een `?a=` met lege waarde en een parameter die er helemaal niet staat, zijn drie verschillende dingen, en frameworks behandelen ze verschillend: soms als lege tekst, soms als `true`, soms als niet aanwezig. Hier worden ze getoond zoals ze in de tekst staan.

Dat is relevanter dan het lijkt. Een schakelaar die als kale naam wordt meegegeven, komt in sommige talen binnen als lege waarde en wordt daar als onwaar beoordeeld — de parameter staat er, de functie gaat niet aan, en in geen enkel logboek valt iets op.

Voor de meeste servers is de volgorde van parameters betekenisloos: `?a=1&b=2` en `?b=2&a=1` leveren dezelfde verwerking op. Daarom worden ze hier getoond in de volgorde waarin ze staan en niet gesorteerd — wat er staat is wat je wilt zien.

Er zijn twee uitzonderingen die geld kosten. Een cache die de hele URL als sleutel gebruikt, ziet twee verschillende adressen en bewaart hetzelfde antwoord twee keer. En een handtekening over de query string is per definitie volgordegevoelig, wat de reden is dat schema’s als AWS Signature versie 4 voorschrijven dat je eerst sorteert.

Oude aanbevelingen stonden toe dat een puntkomma in plaats van een ampersand parameters scheidt, zodat een URL in HTML geen `&` nodig had. Die aanbeveling is ingetrokken, en moderne browsers en servers scheiden alleen nog op de ampersand.

In bestaande systemen leeft het door: sommige oude CGI-scripts en enkele Java-omgevingen accepteren de puntkomma nog. Zie je een parameterwaarde waar een puntkomma middenin staat, kijk dan of de tegenpartij daarop splitst — dat is het verschil tussen één waarde en twee, en het valt pas op als er iets niet klopt.

Anders dan bij namen van HTTP-headers maakt het hoofdlettergebruik in een parameternaam uit: `?page=2` en `?Page=2` zijn voor de meeste servers twee verschillende parameters. Hier worden ze dan ook als twee regels getoond, want dat is wat er staat.

Het duikt op bij handgeschreven links, bij documentatie die de naam anders spelt dan de code hem leest, en bij systemen die uit een andere taal zijn overgezet. Ziet een parameter er goed uit en doet hij niets, kijk dan naar de hoofdletters voordat je verder zoekt.

Query strings uit logboeken en uit statistiekexports dragen regelmatig persoonsgegevens: zoektermen, e-mailadressen als parameter, identifiers die aan een account te koppelen zijn. Omdat het ontleden op de pagina zelf gebeurt, verlaat daar niets van je machine.

Dat is de voorwaarde om zo’n export met een onlinehulpmiddel te bekijken. Een dienst die het op een server zou ontleden, had de regel ontvangen en zou hem in haar logboeken hebben staan — met precies het soort gegevens waarvan de verstrekking de reden is dat de meeste interne richtlijnen bestaan.