SQL injection — это намеренное внесение в базу данных вне системы. | Хакинг
Запись сообщества Хакинг
SQL injection — это намеренное внесение в базу данных вне системы.
Давайте немного углубимся через ещё одну аналогию. Допустим, мы работаем официантом в элитном ресторане. Гости периодически просят изменить состав блюд. Официант отмечает, какие изменения внести в меню.
Недобросовестный официант анализирует и понимает, что на кухне не раздумывая выполняют любой запрос. Поэтому можно внести свои собственные изменения в заказ и повара безоговорочно приготовят блюдо. И он пишет на очередном рецепте:
«ДОБАВИТЬ перец И УБРАТЬ сахар».
Вот и всё. Пранк удался. В нашем примере, кухня — это база данных. SQL-запросы — заказы от официантов.
Если у базы данных нет фильтрации запросов, то злоумышленник может манипулировать данными: получать данные пользователей (в том числе логин и пароль), размещать файлы, заменять значения. Как же злоумышленник может отправлять такие запросы? Это можно сделать через параметры HTTP, добавив в адресной строке параметры:
“http://some.site.ru/test/index.php?name=1′ UNION SELECT 1,2,3,4,5 —+ &password=1234”
Не углубляясь в то, как мы можем сами попробовать хакнуть свою базу данных, разберёмся в причинах уязвимости и посмотрим, как можно защититься.
Во-первых, в запросе должно быть экранирование спецсимволов — игнорирование исполняемым кодом спецсимволов, которые используются в синтаксисе языка программирования. Если один из спецсимволов пропал, то сервер воспринимает его, как часть команды — уязвимость есть.
Во-вторых, проверяем, чтобы при намерено кривом запросе не выводились ошибки, через которые можно сделать выводы о составе базы данных. Например, ошибка “Unknown column ‘4’ in ‘order clause’” говорит о том, что данные из таблицы выбираются по трём колонкам или меньше.
Сегодня существует множество фреймворков и библиотек, которые предоставляют защиту от SQL-инъекций.
Давайте немного углубимся через ещё одну аналогию. Допустим, мы работаем официантом в элитном ресторане. Гости периодически просят изменить состав блюд. Официант отмечает, какие изменения внести в меню.
Недобросовестный официант анализирует и понимает, что на кухне не раздумывая выполняют любой запрос. Поэтому можно внести свои собственные изменения в заказ и повара безоговорочно приготовят блюдо. И он пишет на очередном рецепте:
«ДОБАВИТЬ перец И УБРАТЬ сахар».
Вот и всё. Пранк удался. В нашем примере, кухня — это база данных. SQL-запросы — заказы от официантов.
Если у базы данных нет фильтрации запросов, то злоумышленник может манипулировать данными: получать данные пользователей (в том числе логин и пароль), размещать файлы, заменять значения. Как же злоумышленник может отправлять такие запросы? Это можно сделать через параметры HTTP, добавив в адресной строке параметры:
“http://some.site.ru/test/index.php?name=1′ UNION SELECT 1,2,3,4,5 —+ &password=1234”
Не углубляясь в то, как мы можем сами попробовать хакнуть свою базу данных, разберёмся в причинах уязвимости и посмотрим, как можно защититься.
Во-первых, в запросе должно быть экранирование спецсимволов — игнорирование исполняемым кодом спецсимволов, которые используются в синтаксисе языка программирования. Если один из спецсимволов пропал, то сервер воспринимает его, как часть команды — уязвимость есть.
Во-вторых, проверяем, чтобы при намерено кривом запросе не выводились ошибки, через которые можно сделать выводы о составе базы данных. Например, ошибка “Unknown column ‘4’ in ‘order clause’” говорит о том, что данные из таблицы выбираются по трём колонкам или меньше.
Сегодня существует множество фреймворков и библиотек, которые предоставляют защиту от SQL-инъекций.
