Niet "ontsmetten" invoer als middel om SQL-injectie te voorkomen - plaatsaanduidingen gebruiken (of juist ontsnappen) , altijd. Wees consistent. Wees veilig. Het probleem is al opgelost.
Deze zaak is "veilig" vanwege het beperkte domein van de base64_encode functie. Echter..
Het is slechte praktijk en het opslaan van base64-gecodeerde waarden (zodat de getoonde query kan werken) heeft verschillende negatieve implicaties als het verandert de opgeslagen informatie:het vernietigt de volgorde van waarden, maakt de informatie niet triviaal doorzoekbaar , vereist een extra stap "coderen/decoderen", en zelfs verbruikt meer ruimte - au!
Dus, hoewel er specifieke gevallen kunnen zijn om data te coderen met base64, is deze benadering niet zeer geschikt als middel om SQL-injectie te verminderen .
Het probleem wordt veroorzaakt door toegang tot SQL via een tekstprotocol waar de query-opdracht/vorm en waarden zijn vermengd. Het gebruik van correct ontsnappingstechnieken (bijv. mysql_real_escape_string ) lost dit op door ervoor te zorgen dat de informatie een escapecode heeft, zodat de SQL-tekst wordt geparseerd zoals bedoeld - echter, in tegenstelling tot een stap met base64-codering, doet het niet daadwerkelijk de verstrekte informatie wijzigen!
Deze is exact wat tijdelijke aanduidingen bieden ! Tijdelijke aanduidingen zijn de algemeen correcte benadering en moet worden aangemoedigd. Tijdelijke aanduidingen laat toe dat de query en waarden worden verzonden naar de database afzonderlijk indien ondersteund door de bibliotheek/database; en worden nagebootst door op een andere manier te ontsnappen. Correct gebruik van plaatsaanduidingen elimineert SQL-injectie en de noodzaak van gebruikerscode om waarden te vermengen met SQL-opdrachttekst, wat het schrijven en onderhouden van query's ook gemakkelijker kan maken.
Om te voorkomen dat "individuele programmeurs" vreselijke queries schrijven, is de oplossing voorkomen ad-hocquery's worden niet verspreid in code:verzamel de bewerkingen voor gegevenstoegang in een Data Access Layer ( DAL) (eventueel in combinatie met een ORM) en leg alleen relevante acties bloot, zodat correct gebruik van SQL binnen de DAL wordt gegarandeerd. Bij eenvoudigere projecten is de DAL ook een geschikte locatie om de business rules voor sanitatie en andere validatielogica centraal te beheren.
Nauwkeuriger:
-
Ontsmetten waarden voor bedrijfsregels; dit zou "slechte informatie" moeten voorkomen, zoals een gebruikersnaam die te kort is, beperkte tekens bevat of anderszins niet voldoet aan de zakelijke vereisten.
-
Gebruik tijdelijke aanduidingen om SQL-injectie te voorkomen . Dit is strikt gerelateerd aan het overbrengen van de gegevens naar SQL en heeft geen invloed op de informatie daarin.