Scripter aangeboden

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Zolang je alle delen die afkomstig zijn van een externe bron (de DATA delen in je SQL) op de juiste manier escaped dan is het onmogelijk om de werking van de query te veranderen. Hier hoef je dus helemaal geen ingewikkelde constructies voor te maken. Wanneer je met MySQLi werkt vergt het enkel wat discipline en als je van PDO gebruik maakt dan gebruik je als het goed is / ben je veroordeeld tot prepared statements. Ook daar geldt dat als je dit op de wijze toepast zoals het bedoeld is er eigenlijk niets mis kan gaan.

      Neemt niet weg dat je altijd waakzaam moet zijn en je je altijd af moet vragen:
      - in welke context je zit
      - waar de data vandaan komt
      - of er een speciale reden is om niet te escapen (in wat voor context dan ook), en dit anders wel te doen
    • Niet zozeer of uitsluitend uit voorzorg, maar meer om je werkwijze te simplificeren en te standaardiseren. Het is gewoon veel makkelijker om alles gewoon consequent te escapen, tenzij je een speciale (en gedocumenteerde) reden hebt om dit niet te doen.

      Zoals eerder aangegeven, als je dit niet overal doet dan kan elke keer de vraag rijzen of je bewust niet ge-escaped hebt of dit per ongeluk vergeten bent. Je zou hier dan elke keer over na moeten denken en jouw code moeten herinspecteren. Ain't nobody got time for that.

      Dit creëert ook een groter bewustzijn. Eigenlijk zou je je te allen tijde moeten afvragen als je met DATA uit een externe bron werkt of deze ge-escaped moet worden. Een externe bron kan ook jouw database zijn, deze bevat namelijk (indirect) ook USER DATA. Een goede instelling is om deze nooit te vertrouwen. Zelfs niet als deze in je database zit.

      Het is echter niet de bedoeling dat je op voorhand alles voor een bepaalde context escaped waar je deze DATA niet direct voor gebruikt. Zo is het niet verstandig om bijvoorbeeld htmlentities() over tekst heen te gooien als deze de database in gaat omdat je die op den duur mogelijk gebruikt/weergeeft in een HTML-context. Vermijd het escapen van input, het (bredere) devies is nog steeds

      filter input, escape output

      Met de nadruk op output, oftewel, als je data in een bepaalde context gebruikt, dan is het zaak om te escapen. Je zou je in ieder geval altijd moeten afvragen of er ge-escaped moet worden en dit dan ook altijd doen, en zoniet, zou je een aantekening moeten maken die aangeeft waarom dat daar niet nodig of gewenst is.

      Natuurlijk kun je de behandeling van DATA wel wat versoepelen op het moment dat geregistreerde gebruikers deze invoeren omdat je dan al iets beter weet wie deze personen zijn, maar dit zou nooit mogen resulteren in het zomaar accepteren van wat voor data dan ook of het blindelings verwerken hiervan, dit zou nog steeds aan alle (veiligheids)regels moeten voldoen. Je zult die data nog altijd valideren (filter input) en escapen in queries (escape output).
    • dmeigenaar wrote:

      Ik heb tot dus verre niet in enkele query mysqli_real_escape_string() staan.
      Enkel bij queries die wat toevoegen zoals $_POST bijvoorbeeld.

      Is het dan verstandig om uit voorzorg mysqli_real_escape_string() bij elke query toe te voegen?
      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.
    • AarClay wrote:

      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.