Генерируемый запрос к базе даных должен содержать в себе логин и пароль, введенные пользователем. По этим полям БД должна найти соответствующую запись в таблице.  После обработки запроса, БД выдает найденную информацию о пользователе, которую PHP скрипт оформляет в виде HTML и возвращает пользователю.

Расcмотрим достаточно типичный фрагмент PHP скрипта, использующий SQL запрос для доступа к базе данных:

<?php
$result = mysql_db_query("database","select * from userTable where login = '$userLogin' and password = '$userPassword' ");
while($row = mysql_fetch_array($result)) {
    echo $row["fullname"];
   echo $row["email"];
    echo $row["password"];
}
mysql_free_result($result);
?>

Как видим, логин и пароль, введенные пользователем содержатся в переменных $userLogin и $userPassword. Содержимое этих переменных встявляется в запрос для отфильтровки информации именно об этом пользователе. Фильтр задается с помощью опции where команды select SQL. В данном случае, запрос выглядит таким образом: select * from userTable where login = '$userLogin' and password = '$userPassword' где userTable - имя таблицы, содержащей нужную информацию. Если переменые логина и пароля содержат значения vanya и vasya соответственно, то запрос, отсылаемый БД, примет такой вид: select * from userTable where login = 'vanya' and password = 'vasya'. Понятно, что если в базе данных отсутствует запись, в которой логин равен vanya а пароль - vasya, до запрос не пришлет ни одной строчки из БД, и скрипт ничего не выдаст. Таким образом, приведенная система обеспечивает доступ к информации только пользователя, обладающего правильным паролем и логином.

Казалось бы, такая система не содержит изъянов. На самом деле, это не так. Логика программиcтов, создававших приведенный выше пример, подразумевает, что введенные пользователем логин и пароль, будут содержаться внутри одинарных кавычек, которые жестко забиты в теле запроса. Однако, посмотрим, что произойдет, если сам пароль, введенный пользоваетелм содержит кавычку. Пусть он имеет значение vas'ya, тогда запрос примет вид: select * from userTable where login = 'vanya' and password = 'vas'ya'. При исполнении такого запроса, безусловно возникнет ошибка, поскольку кавычка из пароля, закрыла открывающую кавычку из запроса, и конец пароля ya' остался "висеть" вне условного выражения.

А если вставить в качестве пароля  такую строку: ' or 1=1 ' , то запрос станет таким: : select * from userTable where login = 'vanya' and password = '' or 1=1 '' и не будет содержать синтаксических ошибок. Зато логическое выражение станет тождественно истинным, и в ответ на этот запрос, SQL выдаст всю базу данных пользователей 8-).

Таким образом, используя символ апострофа, мы можем прникнуть в тело SQL запроса и сделать так, что бы  проверяемое условие было истинным. Если нас интересует конкретный пользователь vanya, то для получения информации о нем, можно воспользоваться такой строкой пароля: ' or login = 'vanya. При этом запрос станет таким: select * from userTable where login = 'vanya' and password = '' or login = 'vanya' . Как вы понимаете, в результате мы получим информацию именно о vanya.

Описанная уязвимость сервисов, основаных на SQL, не ограничивается несанкционированным получением информации. Поскольку в таких системах используется, как правило, MySQL, то имеется возможность не только модифицировать условное выражение в команде select, но и выйти за пределы этой  команды, и выполнить другую команду БД. Поскольку в MySQL допускается несколько команд в одном запросе, разделенных ; , то мы можем выполнить любую из этих команд, введя в поле пароля следующий код: ' ; <командаSQL> где в качестве <командаSQL> можно указать любую допустимую команду. Так например такой код: ' ; drop table 'userTable просто напросто уничтожит таблицу userTable из базы данных.

Практическое использование уязвимости