Комментарии 11
Без части, объясняющей, в каких условиях и при НЕсоблюдении каких правил инъекции возможны, и что необходимо сделать, чтобы они стали невозможны, ценность статьи близка к нулевой.
Тем более что описанное применимо далеко не к каждой СУБД.. например, в MySQL ни один из примеров не сработает - хоть вводи их в клиента прямо с инъекцией.
И да - если в абзаце размещаете запрос, то не надо ставить в этом абзаце финальную точку. Запросу это неполезно.. значениям и ссылкам, впрочем, тоже.
К вышесказанному я бы добавил, что в подобных статьях надо обязательно разделять понятия уязвимости и эксплуатации уязвимости.
Потому что никаких "слепых уязвимостей" не бывает.
Уязвимость всегда только одна — возможность модифицировать код SQL.
А вот способов использовать, или эксплуатировать эту уязвимость — бесконечное количество.
Важным следствием понимания этого факта является простое правило — что защищаться следует не от бесконечного количества разных вариантов эксплуатации, а от одной простой уязвимости, соблюдением двух простых правил:
- любые данные попадают в запрос только через символы подстановки
- любые другие элементы запроса — только после фильтрации через белый список разрешенных значений
" "слепых уязвимостей" не бывает " - в первоисточнике так написано, так и осталось в данной публикации. Скорее всего должно было звучать как "Уязвимости слепых SQL-инъекций" т.к. в оригинале идет разбор именно слепой SQL-инъекции
Да какая разница-то, что где написано? Я не про статью писал, а про инъекции.
Тем более что так пишут все кому не лень. Привычная ошибка типа "силиконовой долины".
Если уж говорить о том, как "должно быть", то я повторюсь — "слепых" инъекций не бывает. Уязвимость бывает только одна: это возможность манипулировать кодом SQL. Возможность сделать эту самую инъекцию. И она не может быть слепой или не слепой. Она может только быть или не быть.
"Слепая инъекция" — это не отдельный тип инъекций, как можно подумать из названия. А просто набор техник, эксплуатирующих ту же самую уязвимость, просто в некотором ограниченном окружении. Частный случай, который на самом деле не стоит выделения в отдельную категорию.
Поэтому корректно можно говорить только о попытках обнаружения (или эксплуатации) SQL инъекции вслепую, т.е. без вывода запрошенной информации.
Вообще, все эти разглагольствования про инъекции — столь же благодатный материал для статей, сколь и бессмысленный. Как я писал выше, количество разных вариантов эксплуатировать инъекцию — бесконечно. Можно писать целые тома с продолжением. А можно просто взять учебник по SQL. Потому что эксплуатация — это не про "инъекции", а про доскональное знание синтаксиса SQL и нетривиальные способы его применения.
Статья является переводом, почему не указываете первоисточник? Ведь можно не ждать следующих статей, а почитать самостоятельно и выполнить лабораторные работы по каждой теме на той же информационной площадке.
А можно ссылку на оригинал?
Благодарю!
Но вообще таких материалов в сети навалом, можно легко нагуглить хоть десяток.
Другое дело что сам формат таких статей мне кажется бессмысленным. По сути они ничем не отличаются от дурацкого комикса про мальчика Бобби, с его единственным вариантом DROP TABLES.
Как я говорил выше, реальные инъекции — это не про подборки готовых рецептов, а про мануал по СУБД штудировать + умение нестандартно мыслить + феноменальную усидчивость. Про это, кстати в статьях не пишут. Что взлом чаще всего — это дико изматывающий процесс постоянных проб и ошибок с совершенно мизерным выхлопом.
Вот, кстати, совершенно гениальная история взлома: https://habr.com/ru/articles/708384/
Хотя он и не про инъекции, но примерно показывает сам процесс.
Публикации
SQL-инъекции для самых маленьких