Frank Nietbelangrijk op 26/10/2017 16:16:21
De vraag is dus: Kan ik in de output van mijn script het volgende plaatsen zonder (html) escaping:
Ja, maar dat is niet aan te raden. Vanwege mogelijke ambiguïteit.
Frank Nietbelangrijk op 26/10/2017 16:16:21
of is het beter om dit te escapen en dus het volgende als output te genereren:
Ja, dat verdient de voorkeur. Vanwege mogelijke ambiguïteit.
Frank Nietbelangrijk op 26/10/2017 16:16:21
Voor onveilige data moet ik natuurlijk htmlentities() gebruiken:
Actually, htmlspecialchars() is beter omdat je anders in de knoei komt in sommige situaties (XML en afgeleiden, de bron hiervoor moet ik je schuldig blijven, maar dit was min of meer de uitkomst van mijn htmlentities() vs htmlspecialchars() onderzoekje).
Frank Nietbelangrijk op 26/10/2017 16:16:21
Maar als een variabele veilig genoeg is (altijd een nummer of een tekst uit een whitelist) dan lijkt mij dat weer wat overkill.
Ik ga hier herhalen wat ik in de andere thread al zei: het is gewoon makkelijker om regels consequent toe te passen. Als je namelijk een keer escaping weglaat omdat dit niet nodig is dan moet iemand (anders die jouw code bekijkt) nadenken en dingen controleren om na te gaan dat het echt de bedoeling was dat iets niet geescaped diende te worden. Al deze overhead heb je niet als je gewoon overal escaped, of dit nu nodig is of niet. Keep It Simple.
Overkill wellicht, maar dit traint je ook om beducht te zijn op user input / externe data in je applicatie, die altijd aandacht verdient.
En als je dan niet escaped, vermeld dan een expliciete reden waarom dit niet hoeft. Dan stuur je een collega ook niet met een kluitje het riet in. En als het al geescaped was, heb je hier geen omkijken naar.
Rob Doemaarwat op 26/10/2017 19:19:48
Edit: O, ik zie dat ik wat gemist heb in de originele thread; daar wordt hetzelfde al uitgekauwd.
Voorgekauwd? Uitgekauwd? Meh.
Anyhoo, in een hele simpele optiek moet je het denk ik als volgt zien. Je produceert meestal een HTML document. Daarin zitten dynamische delen afkomstig van een externe bron. Deze delen dienen meestal niet als HTML geïnterpreteerd te worden. Hiervoor zet je escaping-functionaliteit in om dit te garanderen.
Daarnaast heb je in wat verder ontwikkelde applicaties een interne navigatie. Om je applicatie vrij verplaatsbaar te houden zouden alle interne links dynamisch gegenereerd moeten worden. Op basis van servervariabelen, configuratie-instellingen et cetera. Idealiter introduceer je hiervoor een soort van
linkfunctie.
Het is echter niet de taak van deze functie om aannames te doen in welke context deze gebruikt gaat worden. Deze linkfunctie zou namelijk ook in JavaScript ingezet kunnen worden en dan gelden er andere regels. Voor het escapen is een functie natuurlijk ook handig. Dit omdat je dan centraal -ook weer op grond van een serverinstelling of configuratie-variabele- bijvoorbeeld een character encoding kunt regelen maar misschien nog belangrijker (in beide gevallen):
je voorkomt hardcoding.
Het niet uitschrijven van interne links maar het variabel houden hiervan middels een functie zorgt ervoor dat je applicatie niet verandert in een baksteen. Het escapen van output via een functie stelt je in staat om dit mogelijk aan extra regels te onderwerpen of dingen centraal aan te passen. Maar elk van deze functies heeft een eigen, en
enkele verantwoordelijkheid: de een is bedoeld voor het (in welke context dan ook) genereren van links, het ander is (specifiek) bedoeld voor het escapen van (het ontdoen van enige speciale betekenis van) DATA in HTML.
En dan zijn er nog aparte regels voor de key-value paren van querystringparameters (voor de duidelijkheid: we hebben het hier over hyperlinks in <a href="..."> tags). Deze dienen (eigenlijk) beide ge-urlencode() te worden zodat, wederom, deze data wordt ontdaan van enige speciale betekenis binnen de URL. Vaak kies je de keys zelf zodat dit om te beginnen niet voor problemen zorgt met interpretatie (toch?) maar better safe than sorry wellicht. Dit alles kun je opnemen in de eerdergenoemde linkfunctie waaraan je een $args (array van key-value paren) argument ofzo toevoegt.
Vervolgens is deze gebakken link... weer DATA die van buitenaf afkomstig is en niet als HTML geïnterpreteerd dient te worden, dus hier gooi je, als je deze in een <a href="..."> tag gebruikt weer de escaping-functie over, dit verschilt verder niet van andere externe data in je applicatie en deze behandel je dus ook gewoon weer precies hetzelfde.
Ik heb nu een heel relaas geschreven om te onderbouwen
waarom ik doe wat ik doe. Het is simpel, het is veilig, het is consistent. Deze aanpak zou ik niet zondermeer opvolgen, maar ook niet op voorhand afschrijven omdat je niet dezelfde weg hebt afgelegd als ik. Misschien is de enige manier om tot deze conclusies te komen zelf deze weg te bewandelen. Ook ben ik zeer benieuwd of er ook echt andere aanpakken zijn die hetzelfde bereiken, maar dan ben ik vooral geïnteresseerd in het
waarom, en niet zozeer in de vorm.
Dit klinkt misschien arrogant, maar zo is het niet bedoeld. We bevinden ons allen in hetzelfde landschap, maar afhankelijk van waar je staat zie je mogelijk andere dingen. Of zie je dezelfde dingen vanuit een andere hoek.
