Instructeur: Zoals je tot
nu toe hebt gezien, zijn SQL-injecties erg gevaarlijk.
Ze zijn ook erg makkelijk te (mompelen) en erg makkelijk te vinden.
Je vindt ze overal op enkele echt beroemde websites.
Men probeert deze kwetsbaarheden te voorkomen met behulp van filters.
Filters kunnen het doen lijken alsof er geen exploits
zijn, maar als je beter je best doet door coderingen, verschillende
soorten coderingen of een proxy te gebruiken, kun je
de meeste van deze filters omzeilen.
Sommige programmeurs gebruiken een zwarte lijst.
Ze verhinderen bijvoorbeeld het gebruik van union, ze verhinderen
het gebruik van insert en dat soort dingen.
Nogmaals, het is niet 100% veilig.
Het kan omzeild worden.
Gebruikt u een witte lijst?
Precies dezelfde problemen als met de zwarte lijst.
De beste manier om dit te doen is uw webapplicatie zo te
programmeren dat er geen code in kan worden geïnjecteerd en vervolgens
uitgevoerd.
De beste manier om dat te doen is het gebruik van geparametriseerde verklaringen
waarbij de gegevens en de code gescheiden zijn.
De beste manier om u te laten zien wat ik daarmee
bedoel is aan de hand van een voorbeeld.
Ik houd de minste programmering in dit voorbeeld.
Ik wil niet dat het een programmeervoorbeeld wordt.
Er zitten fouten in de programmering, maar ik probeer
je meer het concept te geven dan hoe je
het moet programmeren.
De kwetsbare code die we bekeken deed dit.
Vroeger deed ik select * van accounts waar de gebruikersnaam gelijk
is aan wat we in tekstvak 1 zetten.
Dan zetten we in tekstvak1, laten
we het gewoon hier
zetten, we zeiden admin, en dan sluiten
we het citaat.
Dan kunnen we een union select doen, en iets anders
uitvoeren.
Als we klaar zijn, voegen we het commentaar toe, dat
in principe alles negeert wat erna komt.
Dus als je dit kopieert
en hier plakt, zie je
wat er gebeurt.
Nu, laten we dit wegdoen, want
dit maakt de kleuren niet mooi.
(Eigenlijk ga ik hier een opmerking over maken.
Het doet een select * van accounts waar
gebruikersnaam gelijk is aan admin,
union select en voert uit wat we willen doen.
Dit is heel erg en het is heel moeilijk om je ertegen te beschermen.
Zoals ik al zei, met filters en
zo, verbergen we alleen het probleem, we lossen het niet op.
De beste manier om dit te doen
is door de geparametriseerde verklaringen zo te gebruiken.
Dit is de veilige manier om het te doen.
Eerst bereid je je verklaring voor.
De meeste talen zoals PHP en allemaal,
hebben eigenlijk zo'n functie.
U kunt * selecteren uit rekeningen waar gebruikersnaam
gelijk is aan vraagteken.
Dan verstuur je de waarden.
Dus, PHP weet het nu.
De SQL verklaring is select * from accounts
where username is equal to something.
Dan neemt het de waarde van tekstvak1.
Dus, zelfs als we binnenkomen en we gebruiken
onze zeer stiekeme verklaring hier,
en plakken het daar in, zal
de webapplicatie weten dat de waarde hiervoor admin
union select is.
Het zal, eigenlijk, proberen om
* te selecteren van accounts waar de gebruikersnaam, en dan zal
het, eigenlijk, zijn eigen aanhalingstekens toevoegen
en proberen om een gebruikersnaam te vinden met de volgende gebruikersnaam.
Dit hele ding wordt zo uitgevoerd.
Dus, het wordt select * van accounts
waar gebruikersnaam gelijk is aan admin union select, deze
hashtag.
Wat u in het tekstvak zet, wordt als waarde verzonden.
De webapplicatie zal weten dat dit een
waarde is, geen code, en zal het nooit uitvoeren.
Dit beschermt u dus tegen SQL-injecties.
U kunt de filters gebruiken als tweede verdedigingslinie,
en ik adviseer u ook om zo min mogelijk privileges
te gebruiken.
Gebruik voor elke database een gebruiker
met de minste privileges.
Laat de gebruikers niet alles doen wat ze willen.
Als het een eenvoudige website is die alleen selectie doet, laat de
gebruiker dan alleen selecteren.
Als hij alleen moet selecteren en invoegen, sta
hem dan alleen toe te selecteren en in te voegen.
Dit is een regel die je bij alles moet aanhouden,
zelfs bij Linux-systemen.
Zorg ervoor dat de machtigingen altijd zo klein mogelijk zijn.
Elke gebruiker heeft geen extra rechten die hij
niet nodig heeft.