C, PHP, VB, .NET

Дотук разгледахме най-често срещаният проблем, позволяващ вмъкване на нежелан SQL код - лошо филтриране на входните данни. Отбелязахме, че е по-добре да даваме множество от позволени стойности на входните данни, а не просто да забраняваме непозволените символи. За да обясним защо ще демонстрираме чрез пример, в който няма да използваме кавички при изпълнение на заявката. Нека например изпращаме следната заявка:

	$sql = "SELECT * FROM stats WHERE id=$id"

В случая полето с име "id" е от тип int и поради тази причина не е нужно ограждането на стойността в кавички. Ако подадем например числото "5" ще се генерира следната заявка към базата от данни:

	SELECT * FROM stats WHERE id=5;

Ако обаче подадем "23 OR 1=1" ще се получи:

	SELECT * FROM stats WHERE id=23 OR 1=1;

Тази заявка очевидно е винаги валидна и ще изкара всички данни от базата от данни. В нея не използвахме нито един непозволен символ. Възможностите за пробив са много, в зависимост от вида на заявката. При заявка от тип UPDATE или DELETE например може да се достигне до фатални за базата от данни резултати.

Как да се защитим? Отговорът е ясен - валидирайте не само подадените символи, но и самите типове данни:

	if(is_numeric($id){
		$sql = "SELECT * FROM stats WHERE id=$id"
		...
	}
	else{
		echo "Are you trying to do SQL injection?";
		exit();
	}

Възможно е и използване на вградените функции на сървъра за база от данни, но на практика е по-добре да валидирате в собственото приложение (а защо не и по двата начина?).

Един начин категорично да предотвратим SQL Injection е да използваме параметризирани заявки, т.е. такива, при които първо компилираме скрипта, а после вмъкваме параметрите. По този начин се гарантира, че няма как да бъде променена логиката на заявката (и да се вмъкне OR условие или подобна промяна на изходния програмен код). Друга подобна възможна практика е да използваме на съхранени процедури, вместо да подаваме на директни заявки. В крайна сметка ако трябва да градираме защитата от по-опасна към по-добра практика (от гледна точка на възможност за допускане на неволни грешки), класацията ще изглежда така:

1. Използване на стандартни заявки, като се прави винаги escape на кавички и допълнително внимание към променливи, които не са текстови низове;
2. Валидиране на всички параметри чрез регулярни изрази;
3. Валидиране на всички параметри чрез регулярни изрази и допълнителен escape на всички кавички (за всеки случай, ако случайно допуснем грешка в регулярния израз);
4. Използване на параметризирани заявки или съхранени процедури;
5. Използване на параметризирани заявки или съхранени процедури, и валидиране на всички параметри чрез регулярни изрази (така няма да изпълняваме въобще заявки, които няма смисъл да се изпълняват).

Отново ще припомним и едно друго, вече споменато основно правило за базите от данни - давайте толкова привилегии на потребителя, колкото са му нужни! Грешен подход е да имаме един потребител за базата от данни, който се използва за всички видове заявки.