Почему SQL-инъекции — это опасно?

Question

[partyzanx]

Почему SQL-инъекции - это опасно?
Как их можно обойти?
Что можно сделать вместо них?

// Получение одной статьи по её id
function get_lesson_by_id($id) {
    global $db;
    $bookmarks = $db->query("SELECT * FROM entries WHERE id = $id");
    foreach ($bookmarks as $bookmark) {
    return $bookmark;
    }
}

Comments

[zvonok1337]

потому что sqlmap -u "http://localhost/index.php?id=1" --dump

[devalone]

Артём Петренков, id обычно предполагает, что это primary key, т.е. выбирается один объект, а не все.

[zvonok1337]

Артём Петренков, не говнокод, а особенности языка :)))))))))

Answer 1

[oh_shi]

Answer 2

[Rsa97]

Опасны - потому, что можно увести всю информацию из базы, ну или поломать её.
Скажем, в своём запросе подставьте $id = '1 OR true'
Защита - использование подготовленных выражений с плейсхолдерами.

Comments

[partyzanx]

А как можно переделать в плейсхолдер этот код?

function get_lesson_by_id($id) {
    global $db;
    $bookmarks = $db->query("SELECT * FROM entries WHERE id = $id");
    foreach ($bookmarks as $bookmark) {
    return $bookmark;
    }
}

[Rsa97]

partyzanx, Судя по коду, вы используете какую-то обвязку поверх стандартных PDO или mysqli. Значит ответ надо искать в документации на эту обвязку.

[Pavel Karinin]

partyzanx, а можно просто проверить $id на предмет того, является ли он допустимым

[Rsa97]

Pavel Karinin, В случае числового значения - можно, но в случае строки уже надо эскейпить или пользоваться плейсхолдерами. Подготовленные выражения лучше, если нужно передать null или использовать выражение несколько раз с разными параметрами.

[Pavel Karinin]

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

[Rsa97]

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

[Pavel Karinin]

Rsa97, ну для этого используют экранирование, усечки, белые и черные листы, кодирование...

[Rsa97]

Pavel Karinin, Так подготовленный запрос просто заменяет экранирование, позволяя не беспокоиться о контроле данных с технической стороны. Логический контроль всё равно необходим, но сам по себе он может что-то пропустить. Фрагмент SQL-запроса в комментарии на техническом форуме вполне приемлем.

[Pavel Karinin]

Rsa97, Ok)) это можно обойти. Как обойти усечки? Как обойти кодирование?

[Rsa97]

Pavel Karinin, А что понимается под усечками и кодированием?

[Pavel Karinin]

Усечка - это больше "сленг", и мягко говоря странный подход, но я такое видел: строку разбивают на куски и делают последовательные UPDATE, но в одном пакете

Кодирование - это кода строку вообще особо не проверяют, а сразу преобразуют в например в base62, в base64 или тупо записывают как массив байтов.

[Rsa97]

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

[Pavel Karinin]

@Rsa97

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

полностью согласен, поэтому считаю метод странным очень

При кодировании теряется возможность поиска по строке.

Тоже верно. Поэтому в игру вступают белые и черные листы, но с ними такая марока...

[Rsa97]

Pavel Karinin, Белые и чёрные списки всё равно нужны, например, для исключения или маскирования обсценной лексики. Но как применить их ко вполне допустимой на техфоруме теме SQL-запросов? Скажем, добавление комментария

"INSERT INTO `comments` (`news_id`, `user_id`, `comment`) 
    VALUES ({$newsId}, {$userId}, '{$comment}');"

И комментарий:
А если так, '); DROP TABLE `comments`; --
Здесь остаётся либо эскейпить $comment, либо делать подготовленный запрос с плейсхолдерами.
Ну и, если надо вставить в какое-то поле null, то придётся либо добавлять отдельное условие, либо таки опять пользоваться плейсхолдерами.

Answer 3

[devalone]

Потому что можно сделать всё, на что имеет право текущий пользователь БД. Например:
1; DROP TABLE entries; --
превратится в запрос

SELECT * FROM entries WHERE id = 1; DROP TABLE entries; --

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

Что можно сделать вместо них?

google://sql prepared statement

Comments

[hOtRush]

ERROR 1008 (HY000): Can't drop database 'entries'; database doesn't exist

[devalone]

hOtRush, там должно быть table, исправил)

Answer 4

[h4r7w3l1]

Sql Injection это не вершина "опасности". По CVE score порядка 6-7.
Конечно же все зависит от конфигурации ПО, привилегий, обновлений и т.д.
Но стоит учесть тот факт, основная масса уязвимостей типа sql inj все же не union с error base, в 80% blind, что затруднит проведение эксплуатации, а если админ не будет спать в одном ботинке, то вовсе исключить, и исправить.
На получение структуры может уйти сутки двое. Не будем забывать еще и про WAF'ы, cloudflare, incapsula.

Хорошо, даже в случае спящего админа, допустим было получены записи с привилегированными запясями ресурса. Опять же вопрос к разработчику.. С md5,sha1 все ясно, а будь в blowfish хотябы 8мизначный пароль даже прописью, такой фактор обычно просто откладывается, ибо соблюдая методы минимальных парольных политик и шифрования может подарить безопасность довольно на долго (конечно не исключая плавновую смену паролей).

Предположим цель жизни было скомпрометировать сервис, и бедолага потратил порядка недели на раскрутку скули, обходы waf, и перебор хеша админа. Надеюсь же php настроен адекватно, и нету всяких привелегий у юзера mysql типа grand dba. Но и даже в таком случае можно уберечь конфеденциальные данные, даже при условии полного слива БД. Шифруйте важные данные, храня ключ не в бд. Такой best практайс встречаеться довольно редко, обычно на гигантских ресурсах, да еще с "вкусной" для злоумышленников сферой деятельности.
Да вприцнипе как пример подобного - стандарт хранения кредитных карт, если админ желает их логировать. braintree и куча других решений, да еще с мощным мониторингом, и крутыми фичами.

По сути довольно тривиальные шаги если позволяет специфика и нагрузки ресурса.

Но все же черт страшен как его малюют) У талантливого хакера будет на один вектор атаки всегда больше чем примененные средства защиты и фикса. Вообще не стоит забывать про еще несколько десятков куда посерьезней уязвимостей чем инъекции. И понимать что впорос только во времени. Рано или поздно появиться лазейка, не учтет админ, или очередная 0day.. И плакали все труды по обороне