Dit geïsoleerde voorbeeld is onkwetsbaar voor injectie.
Maar u moet zich realiseren dat bescherming tegen sql-injectie niet alleen een tekenvervanging is . En omstandigheden kunnen verschillen van die u nu voor lief neemt. Uw code zou dus op de lange termijn kwetsbaar worden vanwege essentiële nadelen van deze methode :
- teken vervangen is slechts een onderdeel van vereiste opmaak
- deze specifieke vervanging kan alleen worden toegepast op snaren, waardoor andere onderdelen absoluut onbeschermd blijven.
- een dergelijke vervanging is extern aan een query-uitvoering, wat betekent dat het vatbaar is voor menselijke fouten van welke soort dan ook.
- een dergelijke vervanging is in wezen een verwijderbare maatregel, wat betekent dat deze te ver van de daadwerkelijke uitvoering van de query kan worden verwijderd en uiteindelijk kan worden vergeten.
- dit soort ontsnapping is vatbaar voor coderingsaanval , waardoor de oplossing te beperkt in gebruik is.
Er is op zich niets mis met het vervangen van tekens, maar alleen als het wordt gebruikt als onderdeel van de volledige opmaak; toegepast op het juiste querygedeelte; en gedaan door een databasestuurprogramma, niet een programmeur; vlak voor uitvoering.
Functies die u in de opmerkingen hebt voorgesteld, zijn een goede stap, maar nog steeds onvoldoende, aangezien ze onderhevig zijn aan de hierboven genoemde nadelen, waardoor ze vatbaar zijn voor allerlei soorten menselijke fouten.
En SQL-injectie is niet het enige probleem met deze aanpak, het is ook een bruikbaarheidsfout, omdat deze functie ofwel uw gegevens zou bederven, als deze wordt gebruikt als een incarnatie van late magische citaten , of maak uw code opgeblazen, indien gebruikt om elke variabele recht in de applicatiecode op te maken.
Dergelijke functies kunnen alleen worden gebruikt om een tijdelijke aanduiding te verwerken , maar natuurlijk niet door middel van een zelfgemaakte vervangingsfunctie, maar een goede functie die wordt geleverd door database-API.