Onderwerp: Hoe voorkomen van 'grootschalige SQL-injectie'

De laatste dagen lees ik regelmatig over de grootschalige aanvallen met sql-injecties. Net las ik er weer een: http://www.security.nl/article/18693/1

De aanval gebruikt ... slordig programmeerwerk

Niet dat ik mezelf er toe reken uiteraard maar kan iemand uitleggen wat dan 'slordig' werk is?
Is er ook iets van een tooltje waarmee je websites kunt testen? Leuk om de oorzaak te noemen, maar hoe kan ik voorkomen/testen dat (websites op) mijn server ook de pineut is.

Je variabelen in de SQL query niet isoleren/quoten bijvoorbeeld.

lijkt me dat een website als die van Harry Kies dat toch wel goed geprogrammeerd heeft? (zie afbeelding bij artikel). Er is vast nog een andere manier

http://nl3.php.net/manual/en/functio...ape-string.php

Met voorbeeld van injection enal.

Je zou een kleine escape functie kunnen maken en daar al je variablen doorheen halen die je in een query gebruikt bijv.

Code:

<?php
function escape($string) {
    return "'".mysql_real_escape_string($string)."'";
}
?>

dan is dit bijv. veilig:

Code:

$query = "SELECT * FROM users WHERE user = ".escape($_POST['user']).";

Lees dit maar eens door:
http://www.phpfreakz.nl/downloadz/we...king_huide.pdf

Oorspronkelijk geplaatst door dinges2007

Niet dat ik mezelf er toe reken uiteraard maar kan iemand uitleggen wat dan 'slordig' werk is?
Is er ook iets van een tooltje waarmee je websites kunt testen? Leuk om de oorzaak te noemen, maar hoe kan ik voorkomen/testen dat (websites op) mijn server ook de pineut is.

Er zijn pentest tools, kan zo snel niet op de namen komen.. die je hiervoor kan gebruiken.

Slordig werk: Wat dacht je van iets als GET of POST vars zomaar in een query gebruiken? Of, ook leuk, om met mail() een e-mail te versturen..

Netjes werken: alle waardes die binnenkomen valideren/filteren/forceren. Zo mogelijk met regular expressions. Met binnenkomen bedoel ik dus ook waardes die via cookies, sessions en vanuit de database komen

De 10 basisregels voor programmeren van formulieren of GET/POST:

1) Never trust user input
2) Never trust user input
3) Never trust user input
4) Never trust user input
5) Never trust user input
6) Never trust user input
7) Never trust user input
8) Never trust user input
9) Never trust user input
10) Never trust user input

Oorspronkelijk geplaatst door Randy

De 10 basisregels voor programmeren van formulieren of GET/POST:

Interessante top10. Ben benieuwd hoe de top50 eruit ziet als deze bestaat.

Kijk ook even op deze site. Staat ook een goede uitleg met voorbeelden.

Gebruik maken van "mysql_real_escape_string" voorkomt al heel wat problemen.
Ik maak in de meeste gevallen gebruik van het volgende:

Code:

<?php
foreach($_POST as $name => $value){
	${$name} = mysql_real_escape_string($value);
}
foreach($_GET as $name => $value){
	${$name} = mysql_real_escape_string($value);
}
foreach($_SESSION as $name => $value){
	${$name} = mysql_real_escape_string($value);
}
?>

Dit staat bijv. in een config bestand die als eerst op elke pagina geïnclude wordt.

Tevens worden de functie's "addslashes" en om de variable terug te halen met "stripslashes" ook vaak gebruikt.

Naast dit is het handig i.v.m. spammers om zoveel mogelijk velden te controlleren op echtheid. Zoals een controlle op het email adres.

Oorspronkelijk geplaatst door Hostbusiness

Gebruik maken van "mysql_real_escape_string" voorkomt al heel wat problemen.
Ik maak in de meeste gevallen gebruik van het volgende:

Code:

<?php
foreach($_POST as $name => $value){
	${$name} = mysql_real_escape_string($value);
}
foreach($_GET as $name => $value){
	${$name} = mysql_real_escape_string($value);
}
foreach($_SESSION as $name => $value){
	${$name} = mysql_real_escape_string($value);
}
?>

Dit staat bijv. in een config bestand die als eerst op elke pagina geïnclude wordt.

Tevens worden de functie's "addslashes" en om de variable terug te halen met "stripslashes" ook vaak gebruikt.

Naast dit is het handig i.v.m. spammers om zoveel mogelijk velden te controlleren op echtheid. Zoals een controlle op het email adres.

Raar script... wat als ik nu een post en een get met de zelfde naam heb? Dan wordt er één overschreven... Je kan ze beter weer terugstoppen in de array waar ze vandaan komen...

Gebruike prepared statements, dan doet de SQL server de escaping en eventuele conversie naar andere datatypes voor je.
Verder een degelijk rdbms gebruiken dat geen string argumenten accepteert wanneer je integer veld queried helpt natuurlijk ook.

Geef duidelijk aan waar je de veriabele vandaan haalt. Als het in een post hoort te zitten haal het dan uit de post zodat een foute gebruiker de input niet met get variabelen kan overriden.