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();
	}

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

Друга широко използвана практика е използването на процедури на сървъра за базата от данни, вместо подаването на директни заявки. Тази практика не винаги може да гарантира коректно филтриране!

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