Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
В первом случае, если фильтр не имеет шаблона исходного... 13.04.15 10:56 Число просмотров: 1907
Автор: Den <Денис Т.> Статус: The Elderman
|
> Если совсем навскидку, типовая инъекция - втыкание кавычки,
> после которой либо через ; свою команду, либо какой-нибудь
> OR, фактически убирающий проверку. В первом случае нужно
> отслеживать запросы с несколькими командами и либо отсекать
> все, что идет после ;, либо отсекать там потенциально
> опасные запросы. Во втором - проверять логические операции,
> способные сводить все выражение к безусловному true/false.
>
> Естественно, не панацея, но какую-то часть проблем уберет.
В первом случае, если фильтр не имеет шаблона исходного запроса, безосновательно делать предположения о том, какие именно SQL операторы инжектированы. Даже если фильтр будет знать о количестве SQL операторов в исходном запросе, этих данных не достаточно, чтобы принять решение об исполнении или неисполнении запроса целиком (атомарно), так как такой подход не защищает от инжектирования подзапросов или UNION операторов к исходному SQL оператору, позволяющего неавторизованно выдергивать данные из других таблиц и помещать их в выходные данные исходного запроса.
Во втором случае, чтобы отсечь потенциально опасные запросы, фильтру необходимо знать, какие именно действия разрешены для каждого SQL оператора полученного запроса, что весьма нетривиально в реализации и влечет за собой необходимость передачи в фильтр всё тогоже шаблона исходного запроса, к примеру, в формате функции c++ - "printf".
ИМХО, проблема решается тривиально - корректными клиентскими библиотеками доступа к данным SQL сервера и использованием параметризованных запросов. В общем, я так и не понял, зачем MariaDB нагородили этот фильтр.
|
|
<site updates>
|
|
От прочтения новости испытывал когнитивный диссонанс, пока... 10.04.15 13:33
Автор: Den <Денис Т.> Статус: The Elderman
|
От прочтения новости испытывал когнитивный диссонанс, пока не прочел твою ремарку.
Даже если отделить новость о шифровании таблиц от новости про встроенный фильтр для борьбы с SQL-инъекциями, то последняя также вызывает недоумение. Ведь для того, чтобы некий фильтр SQL сервера мог отличить полученный от клиента запрос с SQL инъекцией от штатного запроса, он должен обладать каким-то шаблоном штатного запроса или же иметь информацию о том, какие действия ожидаемы и позволены данному запросу. В обоих случаях, это совсем не очевидное решение проблемы SQL инъекций.
|
| |
от простых инъекций защититься можно 10.04.15 19:03
Автор: dl <Dmitry Leonov>
|
Если совсем навскидку, типовая инъекция - втыкание кавычки, после которой либо через ; свою команду, либо какой-нибудь OR, фактически убирающий проверку. В первом случае нужно отслеживать запросы с несколькими командами и либо отсекать все, что идет после ;, либо отсекать там потенциально опасные запросы. Во втором - проверять логические операции, способные сводить все выражение к безусловному true/false.
Естественно, не панацея, но какую-то часть проблем уберет.
|
| | |
В первом случае, если фильтр не имеет шаблона исходного... 13.04.15 10:56
Автор: Den <Денис Т.> Статус: The Elderman
|
> Если совсем навскидку, типовая инъекция - втыкание кавычки,
> после которой либо через ; свою команду, либо какой-нибудь
> OR, фактически убирающий проверку. В первом случае нужно
> отслеживать запросы с несколькими командами и либо отсекать
> все, что идет после ;, либо отсекать там потенциально
> опасные запросы. Во втором - проверять логические операции,
> способные сводить все выражение к безусловному true/false.
>
> Естественно, не панацея, но какую-то часть проблем уберет.
В первом случае, если фильтр не имеет шаблона исходного запроса, безосновательно делать предположения о том, какие именно SQL операторы инжектированы. Даже если фильтр будет знать о количестве SQL операторов в исходном запросе, этих данных не достаточно, чтобы принять решение об исполнении или неисполнении запроса целиком (атомарно), так как такой подход не защищает от инжектирования подзапросов или UNION операторов к исходному SQL оператору, позволяющего неавторизованно выдергивать данные из других таблиц и помещать их в выходные данные исходного запроса.
Во втором случае, чтобы отсечь потенциально опасные запросы, фильтру необходимо знать, какие именно действия разрешены для каждого SQL оператора полученного запроса, что весьма нетривиально в реализации и влечет за собой необходимость передачи в фильтр всё тогоже шаблона исходного запроса, к примеру, в формате функции c++ - "printf".
ИМХО, проблема решается тривиально - корректными клиентскими библиотеками доступа к данным SQL сервера и использованием параметризованных запросов. В общем, я так и не понял, зачем MariaDB нагородили этот фильтр.
|
| | | |
в первом случае можно отсекать хотя бы всякие drop table 14.04.15 01:15
Автор: dl <Dmitry Leonov>
|
При передаче из программ вообще не так уж часто используются несколько команд в одном запросе, ну и можно считать, что нефиг таким опасным командам идти в комбинации с другими.
Во втором случае достаточно анализировать логические операции на предмет тривиального результата (типа 1=1 или сводящегося к нему).
C union хуже, но это первые варианты, которые пришли в голову, наверняка там полно разных эвристик.
Естественно, нормальные клиентские библиотеки все это и так лечат.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
