URL-codering voor spaties: %20 of plus?

Een spatie in URL-gegevens wordt meestal %20, maar bij serialisatie van formulierqueries wordt ze +. Beide kunnen correct zijn. De juiste uitvoer hangt af van de bestemming: gebruik procentcodering voor een afzonderlijke URI-component en de plusconventie alleen als de ontvangende verwerking gegevens volgens application/x-www-form-urlencoded verwacht.

De ClockTools URL-encoder maakt die context duidelijk met de profielen URI Component, Full URL en Form Data. Plak green tea, wissel van profiel en vergelijk de uitvoer voordat u applicatiecode verandert.

Begin met de bestemming

Vraag niet: “Welk symbool betekent altijd spatie?” Vraag welke parser de waarde zal ontvangen.

Voor een padsegment, fragmentwaarde of afzonderlijke querywaarde is procentcodering de betrouwbare weergave. De UTF-8-byte van een spatie is hexadecimaal 20, dus het procentgecodeerde drietal is %20.

Bij HTML-formuliergegevens gebruikt de serialisatieconventie + voor spaties en %2B voor een letterlijk plusteken. De WHATWG URL-standaard definieert dit form-urlencoded-gedrag apart van algemene URL-verwerking.

De URI-syntaxis in RFC 3986 definieert een procentgecodeerd octet als % gevolgd door twee hexadecimale cijfers. De specificatie onderscheidt ook gereserveerde scheidingstekens van niet-gereserveerde gegevenstekens. Daarom verschilt het coderen van één waarde van het coderen van een volledig adres.

Beslistabel: %20 of plus

De laatste rij voorkomt een veelvoorkomende fout. Als de bedoelde waarde C++ is, kan C++ door een formulierdecoder worden omgezet in C . Codeer daarom elk letterlijk plusteken als %2B voordat de formuliergegevens worden verwerkt.

Vier reproduceerbare ClockTools-tests

We hebben vier kleine invoerwaarden met de huidige tool getest. Het profiel URI Component gebruikt JavaScript encodeURIComponent. Form Data past dezelfde componentcodering toe en vervangt daarna %20 door +. Full URL gebruikt encodeURI, dat de URL-structuur behoudt.

Dit zijn deterministische omzettingen, geen bewijs voor zoekposities. U kunt ze lokaal in de browser reproduceren. De pagina werkt de uitvoer direct bij, vermeldt procent-escapes en aantallen bytes en hoeft de invoer voor de omzetting niet naar een server te sturen.

Gebruik de URL-decoder voor de omgekeerde controle. Decodeer green%20tea met het componentprofiel en green+tea met Form Data. De decoder waarschuwt bij een plus in een ander profiel, omdat de bedoelde betekenis dan dubbelzinnig is.

Wat beschermt componentcodering?

Een URL gebruikt leestekens als grammatica. In een querystring kan & een volgende parameter beginnen en scheidt = een naam van een waarde. # begint een fragment en ? begint een query. Als zo'n teken bij gebruikersgegevens hoort, kan ongecodeerde invoer de structuur veranderen.

Neem de waarde timer & alarm. Componentcodering levert timer%20%26%20alarm op. De ampersand wordt %26, zodat een parser één waarde ontvangt en alarm niet als nieuwe parameter ziet.

Codering is representatie, geen validatie of encryptie. Een procent-gecodeerde omleiding kan na decodering nog steeds naar een niet-goedgekeurde host verwijzen. Een gecodeerd script is nog steeds niet-vertrouwde invoer. Valideer toegestane schema's, hosts, parameternamen en bedrijfsregels na het parseren. Vermijd het plaatsen van wachtwoorden, tokens of andere geheimen in URL's, omdat adressen kunnen verschijnen in de geschiedenis, logboeken, analyses, schermafbeeldingen en verwijzende gegevens.

Als u een querystring vóór en na de wijziging wilt vergelijken, maakt de Tekstverschilcontrole elke veranderde escape zichtbaar. Dat is betrouwbaarder dan in een lange callback-URL één ontbrekende %25 zoeken.

Waarom creëert dubbele codering %2520?

Dubbele codering vindt plaats wanneer reeds gecodeerde tekst als onbewerkte gegevens wordt behandeld en opnieuw wordt gecodeerd.

Begin met één spatie:

space -> %20

Codeer %20 als een nieuwe component. Het procentteken wordt %25, terwijl de cijfers letterlijk blijven:

%20 -> %2520

Eén decodering zet %2520 terug naar %20. Een tweede zet %20 om in een spatie. Als uw applicatie één decodering verwacht maar een dubbel gecodeerde waarde ontvangt, ziet de gebruiker mogelijk %20 in plaats van een spatie.

De oplossing is niet steeds opnieuw decoderen tot de tekst er goed uitziet. Dat kan bewust gecodeerde scheidingstekens veranderen en beveiligingsproblemen veroorzaken. Bepaal welke laag verantwoordelijk is: precies één laag moet de component coderen en precies één bijbehorende laag moet die decoderen.

Foutopsporing bij verschillende spatiecoderingen

Gebruik deze aanpak als het ene systeem %20 verstuurt en het andere +, %2520 of een echte spatie toont.

1. Leg de onbewerkte waarde vast voordat een parser van het framework die verandert.
2. Bepaal of het veld een padsegment, querycomponent, volledige URL of formulierinhoud is.
3. Noteer de verwachte gedecodeerde waarde, inclusief letterlijke plustekens.
4. Reproduceer dezelfde invoer met het bijpassende ClockTools-profiel.
5. Decodeer één keer met het ontvangende profiel.
6. Vergelijk het resultaat met de verwachte waarde.
7. Zoek in de applicatieverwerking naar een tweede encoder of decoder als %25 onverwacht verschijnt.

Deze aanpak voor foutopsporing is bewust afgebakend. Ze scheidt de gegevenscontext van giswerk en elke stap heeft zichtbare invoer en uitvoer.

Wanneer moet u een volledige URL coderen?

Gebruik het profiel Volledige URL alleen als het adres een adres moet blijven. Het behoudt structurele leestekens zoals de dubbele punt na het schema, schuine strepen, het vraagteken, gelijkteken, ampersand en fragmentteken, terwijl het bijvoorbeeld spaties codeert.

Gebruik URI Component als een volledige URL zelf in een andere parameter is opgenomen. Een callback-adres in redirect= is bijvoorbeeld een gegeven vanuit het perspectief van de buitenste URL. Door het geneste adres als één component te coderen, voorkomt u dat de ? en & ervan onderdeel worden van de buitenste query.

Haal een adres niet telkens door verschillende profielen in de hoop op een overal veilige tekenreeks. Leg de grens expliciet vast:

outer URL structure + encodeURIComponent(inner callback URL)

De ontvangende toepassing moet de buitenste URL parseren, de callback-component extraheren, deze één keer decoderen, de resulterende binnen-URL parseren en de bestemming valideren. Codering houdt de syntaxis intact; validatie beslist of de bestemming is toegestaan.