Door
Ozzie PHP
op 12-02-2019 15:07
gewijzigd op 12-02-2019 15:09
5.719 views
Ik programmeer al weer een tijdje en toen ik jaaaaren geleden met PHP begon werd aangeraden om strings en variabelen altijd te concatten en enkele quotes te gebruiken.
Okay jongens, nog een keer, heel langzaam vanaf het begin.
Het probleem van het weglaten van quotes als deze "niet nodig zijn" is het volgende:
Elke keer als je een stuk code ziet waarbij dit het geval is zou er een kleine alarmbel af moeten gaan waarbij je denkt: "Hé, hier zijn geen quotes gebruikt, wat is hier aan de hand?". Vervolgens ga je na dat er inderdaad een id gevalideerd wordt, en deze wordt ook niet geaccepteerd (als het goed is) voor opname in de query (laat staan het dan uitvoeren hiervan!) als deze niet van het goede formaat is. Vervolgens concludeer je dat alles okay is.
En dit doe jij, of mogelijk iemand anders, ELKE KEER WEER als je deze code ziet. Je moet je er elke keer van vergewissen dat dit klopt. Dit is je reinste tijdsverspilling.
Het is in ieder geval veel makkelijker (Don't Make Me Think) om ALLE externe data te voorzien van quotes, en gewoon al dit soort data te escapen. Je hoeft er dan NOOIT over na te denken of dit "veilig" is of niet.
//bar wordt ook echt null, en niet ''
$db->execute('update tabelnaam set foo = :foo, bar = :bar where id = :id',['foo' => 5,'bar' => null,'id' => 5]);
//en voor recht-toe-recht-aan werk nog korter
$db->update('tablenaam',['foo' => 5,'bar' => null],['id' => 5]);
Nooit meer na hoeven te denken over quotes, nooit meer na hoeven te denken over escapen.
>> Het is in ieder geval veel makkelijker (Don't Make Me Think) om ALLE externe data te voorzien van quotes
Ik meen ergens gelezen te hebben in de documentatie van MySQL dat het niet wordt aangeraden om een getal (bijvoorbeeld een ID) te quoten. Hoe zit dat dan?
als je SET getal = 1 doet, is het inderdaad overbodig.
maar zodra het wordt
$teller = 10;
...SET getal = $teller
vervallen we weer in het varhaal van Thomas: je moet weer terug kijken om te zien dat $teller inderdaad gevalideerd is.
Je 2e vraag met $_GET is heel duidelijk, maar elke andere variabele kán ook rare data bevatten.
Zo heb ik ooit een bug moeten zoeken waarom een van de medewerkers nooit een keuringsrapport kon opslaan en alle collega's wel.
Uiteindelijk bleek het probleem te zijn
UPDATE ..... SET medewerker = '$naam' .....
En helaas: zijn naam bevatte een '
Volkomen legitieme data, maar liet wel een query mislukken. En die naam kwam gewoon uit de database onder zijn user-gegevens (waarom niet volstaan kon worden met zijn user-id is weer een andere vraag.)
Maar ik meen dus ergens gelezen te hebben in de officiële documentatie dat je een getal niet behoort te quoten en dat dat werd afgeraden. Dus ik weet t nu ook niet.
En dit boeit echt niets of heel weinig. Althans niet voor MySQL.
Alleen wanneer je prepared statements gebruikt in MySQLi maak je gebruik van het zogenaamde "binaire protocol" waarbij er iets met types gedaan wordt, anders zijn het toch allemaal strings.
Hetzelfde geldt voor PDO, als je daar de emulatie van prepared statements niet uitzet zet PDO ook doodleuk overal quotes omheen en negeert deze de typehints als je values bind(t). En je moet de logs induiken om dit na te gaan, omdat je op geen enkele andere manier kunt zien welke concrete SQL-code nu daadwerkelijk aan je database wordt gevoerd.
Daarbij, dit is wederom een tradeoff: mogelijk lever je een heel klein beetje performancewinst in voor een eenvoudige en eenduidige werkwijze die altijd veilig is.
Of je bouwt een wrapper zoals @Rob voorstelt. Maar zelfs dan. Stuur je dan altijd eerst SQL-templates naar de database met een prepare(), zelfs als het SELECT-queries betreft? Ik zie best mogelijkheden om een mooie wrapper te bouwen, maar dat is in zekere zin allemaal abstractie en de vraag is dan wat voor meerwaarde dat heeft? Boven een rechttoe-rechtaan-aanpak in MySQLi?
En het wordt natuurlijk weer anders als je een echte database abstractie laag maakt (waar het tweede fragment van @Rob op zinspeelt?) maar ook daar zul je je moeten afvragen of die abstractie echt nodig is en zich ooit terugverdient.
Deze hele discussie is ook gewoon "backwards" omdat we het de hele tijd hebben over "het beste gereedschap" zonder hier een concrecte "klus" in te betrekken. Het laatste bepaalt het eerste, niet andersom...
Ja, als ik dat nog had kunnen terugvinden had ik het er uiteraard bij gezet.
In ieder geval wel stof tot nadenken.
>> mogelijk lever je een heel klein beetje performancewinst in voor een eenvoudige en eenduidige werkwijze die altijd veilig is.
Ja, dat stukje performancewinst boeit me niet eerlijk gezegd. Het stond er alsof het niet goed was om een getal te quoten.
Voor de rest met je eens hoor. Wat ik me wel afvraag ... ga je bijv. een id in een query dan nog escapen? Of zorg je ervoor dat je vantevoren die id al hebt gevalideerd? Wat is het beste? Eerst controleren of het een nummer is én dan ook nog escapen lijkt me overdreven?
