http://www.evilcoder.org/2004/06/02/sql-injection-voor-beginners/

Twee woorden: Input Validatie.

Controlleer alles wat een client naar je zend. Controlleer bijv. of nummers ook daadwerkelijk nummers zijn (en geen andere karakters bevatten). Controleer of een e-mail adres een e-mail adres is. Alles wat niet door de controle komt verwerk je simpelweg niet.

Misschien even een paar challenges oefenen? https://www.certifiedsecure.com

Een woord: FOUT

Input validatie is heel goed maar gaat je absoluut niet 100% wapenen tegen SQL injectie. Hoe ga je dan een vrij tekst veld controleren? Ga je dan scannen op enkele of dubbele quotes? Succes! (en wacht maar tot je website gehacked wordt).

Het enige juiste om te doen is je SQL statement niet op te bouwen door strings aan elkaar te plakken en daar de values tussen te plakken maar door gebruik te maken van parametrized queries of parameter binding. En als je nog een stapje verder wilt gaan maak je gebruik van stored procedures (met parameter binding) en zorg je dat het account wat de website gebruikt om de database te benaderen verder 0 lees en/of schrijfrechten heeft in de database.

Wat ook geen garantie is...

http://palizine.plynt.com/issues/2006Jun/injection-stored-procedures/

Het gebruikt van stored procedures is ook niet bedoeld om SQL injectie tegen te gaan maar als extra laag van beveiliging in je database. Je geeft de webapplicatie daarmee alleen toegang tot de de database via een door jou gedefinieerde interface. Je hoeft het account dus niet volledige rechten te geven (wat helaas wel common practice is) op de tabellen of zelfs helemaal geen rechten (zelfs geen SELECT rechten).

Maar de basis blijft toch het escapen van user-input. Bijvoorbeeld met mysql_real_escape_string().

Op de site van owasp.org staan handige voorbeelden voor verschillende talen.

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Meer uitleg over SQL injectie:
https://www.owasp.org/index.php/SQL_Injection
https://www.owasp.org/index.php/Blind_SQL_Injection

http://www.pfz.nl/wiki/sqlinjectie/

Mischien een zeer stomme beredenering: maar als je ' in je URL's afvangt met een (dure) WAF oplossing, kan je dan nog steeds vatbaar zijn voor SQL injection?

Ja.

Als je behulpzaam was geweest had je ook een voorbeeld genoemd (en liefst iets wat echt mogelijk is).

Ik heb geen ervaring met het bypassen van een Web Application Firewall. Als ik google, dan vind ik een pagina met voorbeelden:
http://kaoticcreations.blogspot.nl/p/sql-injection-waf-bypassing.html

Beste resultaat boek je door meerlaags beveiliging toe te passen. Er kan altijd wat tussendoor sneaken maar je maakt t gaatje wel steeds kleiner. Begin wel bij het begin:

Bij homebrew web-apps:
- schone code en invoercontrole, zorg dat alle sql-achtige tekens eruit worden gefilterd of worden ge-escaped

- web-app databaseaccountsegmentering, standaard gebruiken webapps 1 account om bij de database te komen. Splits dit op. Een gebruikerslogin/mutatie gebruikt andere tabellen dan de zoekfunctie in de webapp, beperk de toegang van die accounts in de database. (deze aanpak wordt helaas niet(niet vaak) toegepast in COTS web-apps) Een SQL-injectie geeft dan maar toegang tot een beperkte dataset in de database.

- Multi-tiering / Opsplitsen van de database. Je kan ook bijvoorbeeld je gebruikersadministratie (bevat persoonsgegevens dus valt onder WBP) onderbrengen in een andere database en die op een andere manier beschikbaar maken aan je webapp. Denk aan een SOAP/XML-koppeling met een eigen minimalistische front-end.

Bij commercial of the shelf (COTS) web-apps:
- HOU JE UPDATES BIJ. Werk deze direct bij zodra er (security )updates voor uitkomen en zorg dat je eigen patches en aanpassingen gelogd worden (change management).


Algemeen:
- installeer een web application firewall en/of IPS, (ook weer: UPDATES UPDATES UPDATES!)
- En tot slot monitoring, monitoring, monitoring, blijf je logs controleren en analyseren. Hier is een boel goeie tooling voor te krijgen, denk aan splunk en logwatch. Zo krijg je vreemde zaken wel in t snotje, mocht er nog wat tussendoor sneaken.

SQL injection wordt veroorzaakt doordat gebruikers input wordt geinterpreteerd als SQL code.

Interpretatie kan volledig worden voorkomen door gebruik te maken van prepared SQL statements i.p.v. dynamisch SQL statements op te bouwen door velden en code achter elkaar te plakken.

-- Ron