Comments 19
Логичнее было бы использовать ОРМ, а WAF тут недавно обсирали с примерами.
В 2017 мы только приступили к разработке Nemesida WAF, на тот момент действительно, были «детские болячки». Если на самом деле интересна точность его работы в 2021 году, можете почитать в статье Я твой WAF payload шатал.
Послушайте, этот чёс становится уже неприличным.
Я сначала хотел написать про техническую неграмотность статьи, но тут дело даже не в этом.
Тут даже попытки нет написать технический текст, а просто механический спам, когда для новой статьи просто берется половина старой и разбавляется копипастой из гугля. Ну увольте уже этого копирайтера, мало того что он в теме не разбирается от слова "совсем" — он же русским языком не владеет:
Объекты базы данных требуют, чтобы разработчик сгруппировал один или несколько операторов SQL в логическую единицу для создания плана выполнения. Последующие исполнения позволяют автоматически параметризовать операторы. То есть, это тип кода, который можно сохранить и многократно использовать в последующем. Когда необходимо выполнить запрос, вместо того, чтобы писать его, можно будет вызвать хранимую процедуру.
Какие еще "объекты"? Чего и у кого они требуют? При чем здесь инъекции?
Здесь совсем ничего не говорится про то, каким образом хранимая процедура может обеспечить защиту (не говоря уж про то, в каких случаях не сможет), а какой-то бубнёж про многократное использование запросов.
Сам чеклист — это обычная бессмысленная копипаста, в которой перепутаны уязвимость, её использование, и "минимизация последствий". При том что к защите имеет отношение только первое. И которая которая не дает четких указаний, а перечисляет несколько путанных, противоречащих друг другу, и неполных рекомендаций. Вот наличие таких статей как раз и приводит к появлению уязвимостей, поскольку читатель не получает четкой картины, а только какие-то невнятные пассы руками, и наверняка допустит ошибку, пытаясь реализовать противоречивые рекомендации.
Уязвимость — это сама возможность изменить код запроса. С ней и надо бороться.
А все эти "Соблюдение условия WHERE", "объединение запросов", "комментирование" — это, во-первых, далеко не полный список, но главное — это разные варианты эксплуатации этой уязвимости. И бороться с ними — столь же интеллектуальное занятие, как "бороться" с каждой каплей дождя отдельно вместо того чтобы открыть зонтик.
Рекомендации невнятные и технически неграмотные. Следует ли применять все перечисленные пункты вместе? (спойлер: нет). Список неполный и не гарантирует защиту. Какие-то мифические функции типа mysqli($str). В кучу навалена защита от инъекций, минимизация последствий, и заведомо неэффективные способы типа WAF (который, являясь черным списком, по определению не гарантирует защиту) Код в примерах написан так, что автор явно видит его впервые в жизни, не понимая ни одной написанной строчки. Вот это прям серьёзно? Давать другим рекомендации, не понимая смысла того что пишешь?
Неправильно. В статье есть даже пример
не понимаю как сделать нужный запрос без знания структуры и получить вывод результата
В статье есть пример, как через инъекцию получить структуру
union select null,null,table_name,null from information_schema.tables --и в ответе веб-приложения мы увидим список всех таблиц, в том числе и системных. Чтобы не отображать системные таблицы, которые редко будут представлять интерес, можно видоизменить запрос:
union select null,null,table_name,null FROM information_schema.tables WHERE table_schema=database() --В таком случае будут показаны только те таблицы, которые присутствуют в текущей базе данных. Стоит также отметить, что для разных СУБД синтаксис будет отличаться, но так или иначе везде можно встретить information_schema или его аналог для просмотра структуры всех БД.
В конце концов можно воспользоваться специализированными инструментами типа SQLmap
вопрос практики
Либо знание структуры либо получается банальный подбор
union select null,null,table_name,null FROM information_schema.tables WHER
вы не можете с уверенностью сказать что 3е поле не int, тем более не можете утверждать что в интересующей вас выборке 4 поля
вы так же не можете с уверенностью сказать что оно вообще выводится
Он тебе не ответит. Потому что не разбирается в инъекциях. Это нанятый за малый прайс писатель, который занимается продвижением товара на хабре.
А целом-то да, эксплуатация инъекций — это чаще всего унылый подбор и перебор.
Что касается типов данных, то вы также правы, но отчасти. Даже если в каком-то поле используется определенный тип данных, то ничто не мешает использовать во всех полях значение NULL, суть которого кроется в его названии. Более подробно про это значение можете ознакомиться в статье на Википедии
И да, верно подсказали, что зачастую поиск и эксплуатация SQL-инъекций — это как унылый перебор таблиц, если union based используется, так и не менее унылый посимвольный перебор для дампа информации из бд в случае blind SQLi.
Чек-лист устранения SQL-инъекций