Заметка Sql инъекции

Archi225

Проверенный
Сообщения
62
Репутация
4
Баллы
8
Добрый день, это моя первая статья, прошу строго не судить.
Тут я вам расскажу об очень опасной уязвимости SQL, сам с ней столкнулся в 2016 году на своём проекте. Что же это такое ?
SQL-инъекцияэто атака, направленная на веб-приложение, в ходе которой конструируется SQL-выражение из пользовательского ввода путем простой конкантенации (например, $query="SELECT * FROM users WHERE id=".$_REQUEST["id"] ). В случае успеха атакующий может изменить логику выполнения SQL-запроса так, как это ему нужно. Конечно же мы понимаем, что данной уязвимости страдают исполняемые файлы с расширением .php. В случае успеха атакующий может изменить логику выполнения SQL-запроса так, как это ему нужно. Чаще всего он выполняет простой fingerprinting СУБД, а также извлекает таблицы с наиболее «интересными» именами (например «users»). После этого, в зависимости от привилегий, с которыми запущено уязвимое приложение, он может обратиться к защищенным частям бэк-энда веб-приложения (например, прочитать файлы на стороне хоста или выполнить произвольные команды.
Как защититься?
Наиболее надежным способом предотвращения SQL-инъекций является использование параметризированных SQL-параметров. К примеру, в случае с PHP это возможно с помощью пакета pears db, предлагающего интерфейс для выполнения абсолютно безопасных SQL-выражений. Обращение к БД происходит следующим образом:
Код:
$p = $db->prepare("SELECT * FROM users WHERE id = ?"); $db->execute($p, array($_GET['id'])).
Основная идея заключается в том, что если позиция параметров явно задана, то можно абсолютно безопасно передавать SQL-запросы базе данных, исключая возможность для параметров самим стать SQL-выражениями (в том числе зловредными). Стоит заметить, что другие механизмы, такие как использование принудительного приведения типов (например, с помощью функции intval()) в связке с экранированием строк такими функциями, как mysql_real_escape_string() или addslashes(), не являются абсолютно безопасными. Проблема в том, что существуют некоторые варианты для их обхода, а следовательно, к их использованию необходимо подходить с максимальным вниманием.
 
  • Мне нравится
Реакции: SOUL

Unsubdued

Администратор
Сообщения
5 930
Репутация
10 149
Баллы
266
Кстати, статейка от 2011 года :)
 

Catharsis

Проверенный
Сообщения
28
Репутация
13
Баллы
3
Добрый день, это моя первая статья, прошу строго не судить.
Тут я вам расскажу об очень опасной уязвимости SQL, сам с ней столкнулся в 2016 году на своём проекте. Что же это такое ?
SQL-инъекцияэто атака, направленная на веб-приложение, в ходе которой конструируется SQL-выражение из пользовательского ввода путем простой конкантенации (например, $query="SELECT * FROM users WHERE id=".$_REQUEST["id"] ). В случае успеха атакующий может изменить логику выполнения SQL-запроса так, как это ему нужно. Конечно же мы понимаем, что данной уязвимости страдают исполняемые файлы с расширением .php. В случае успеха атакующий может изменить логику выполнения SQL-запроса так, как это ему нужно. Чаще всего он выполняет простой fingerprinting СУБД, а также извлекает таблицы с наиболее «интересными» именами (например «users»). После этого, в зависимости от привилегий, с которыми запущено уязвимое приложение, он может обратиться к защищенным частям бэк-энда веб-приложения (например, прочитать файлы на стороне хоста или выполнить произвольные команды.
Как защититься?
Наиболее надежным способом предотвращения SQL-инъекций является использование параметризированных SQL-параметров. К примеру, в случае с PHP это возможно с помощью пакета pears db, предлагающего интерфейс для выполнения абсолютно безопасных SQL-выражений. Обращение к БД происходит следующим образом:
Код:
$p = $db->prepare("SELECT * FROM users WHERE id = ?"); $db->execute($p, array($_GET['id'])).
Основная идея заключается в том, что если позиция параметров явно задана, то можно абсолютно безопасно передавать SQL-запросы базе данных, исключая возможность для параметров самим стать SQL-выражениями (в том числе зловредными). Стоит заметить, что другие механизмы, такие как использование принудительного приведения типов (например, с помощью функции intval()) в связке с экранированием строк такими функциями, как mysql_real_escape_string() или addslashes(), не являются абсолютно безопасными. Проблема в том, что существуют некоторые варианты для их обхода, а следовательно, к их использованию необходимо подходить с максимальным вниманием.
Прошу указать источник информации.
К слову сказать, на просторах Сети относительно небольшое количество сайтов с данной уязвимостью. Обычно — это сайты, оставленные без контроля. Вполне могу заявить Вам — бессмысленно Вы скопировали информацию. Уязвимость устарела.
С уважением.
 

Unsubdued

Администратор
Сообщения
5 930
Репутация
10 149
Баллы
266
А источник, собственно, журнал Хакер от 06.12.2011
 

Catharsis

Проверенный
Сообщения
28
Репутация
13
Баллы
3

Skaiman

Разработчик
Сообщения
6 926
Репутация
6 826
Баллы
266
Надо уже понять, что здесь не школьный хакерский форум и за всякий копипаст, симпатий не получить, а вот напинать могут :)
 

Catharsis

Проверенный
Сообщения
28
Репутация
13
Баллы
3
В общем, уважаемый Archi225, не советую браться за то, в чём не смыслите. В данной ситуации Вы попробовали попробовать себя в роли специалиста по информативной безопасности. Но, попробовать, значит изучить досконально и всесторонне выбранную тему. Однажды сообщил, и сейчас повторяю — каждый мастак копировать уже представленный материал по чужим знаниям.
С уважением.
 

Unsubdued

Администратор
Сообщения
5 930
Репутация
10 149
Баллы
266
Все, блин! Убили флуд!
 
Сверху Снизу