Scripter aangeboden

  • Alleen als je de waarde kan manipuleren, zoals bij $_POST, $_GET, $_COOKIE, $_SESSION, $_SERVER en $_ENV. De laatste twee zijn wat lastiger, maar het zou in de praktijk kunnen.

    Nou, nee dus. Data in je database kwam oorspronkelijk ook uit $_POST. Deze -of liever gezegd, ALLE input- zou je dus nog steeds op dezelfde manier moeten behandelen. Altijd.


    En alles van tevoren al onklaar maken (het escapen van input) is hiertoe geen oplossing.


    Het is helemaal niet erg als er potentieel "gevaarlijke data" in je database zit, zolang je deze maar op een uniforme manier behandelt. Wanneer je output altijd escaped is dit namelijk geen enkel probleem. Natuurlijk moet je zoveel mogelijk vantevoren valideren (filter input) maar dat neemt niet weg dat je alle data op dezelfde manier blijft behandelen. Dit houdt niet op als het de database in gaat.

  • Het is een misvatting om te denken dat je klaar bent met escapen wanneer de data in de database zit. Dit moet je gewoon altijd en overal doen, tenzij je een (gedocumenteerde) reden hebt om dit niet te doen.


    Het altijd consequent escapen van wat voor DATA dan ook is ook veel makkelijker, ik heb al eerder uitgelegd waarom.

  • * zucht *

    En ikzelf zie die data als input, wat je sowieso moet escapen.

    Input filter je, output escape je.


    DATA kan zowel input als output zijn.


    Beschouw code.php?id=12


    $_GET['id'] is invoer van buitenaf (USER DATA).
    Deze kun je mogelijk filteren je om te zien of deze aan een bepaald formaat voldoet als je voor het gebruik hiervan bepaalde eisen stelt.
    Bijvoorbeeld een check om te zien of dit een positief geheel getal is, ten minste gelijk aan het cijfer 1 zodat je in ieder geval een zekere garantie hebt dat het een geldig auto-increment id bevat.


    $_GET['id'] is vervolgens ook uitvoer als je:
    - deze weergeeft op je scherm (HTML-context)
    - deze vervolgens (na validatie) verwerkt in een query (SQL-context)


    Indien je deze DATA dus weer als uitvoer ergens in verwerkt dien je deze uitvoer onschadelijk te maken. Altijd en overal. Tenzij je hier een gedocumenteerde reden voor hebt om dit niet te doen.

  • Het heet dan alleen geen input. Je output DATA in de SQL-context. Dit is vervolgens weer input voor je database :). Het hangt er maar vanaf vanuit welk perspectief je kijkt.


    Als je iets vanuit A doorgeeft aan B dan is dat vanuit A gezien output en vanuit B gezien input. Je kunt niet in beide gevallen spreken van "input". Alleen uit optiek van B is dit input.


    Het escapen van input zou zoiets zijn als htmlspecialchars() heengooien over data die de database ingaat. Maar dat streeft het doel voorbij en heeft zijn eigen problematiek. In heel veel gevallen is het op voorhand escapen van input (en dat zal dus altijd voor een of meer specifieke contexten zijn) niet handig. Het escapen doe je doorgaans pas... als (dus net voordat) je het gebruikt in een specifieke context. Hier zijn trouwens wel uitzonderingen op, maar dat is echt maar een handjevol.


    Ten einde allerlei spraakverwarring te voorkomen en het wijdverbreide devies is het dus nog steeds "filter input, escape output" en dus niet "escape input". Als jij het iets anders wilt noemen (filter banaan, escape pindakaas) mij ook best.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!