информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
В первом случае, если фильтр не имеет шаблона исходного... 13.04.15 10:56  Число просмотров: 1724
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> Если совсем навскидку, типовая инъекция - втыкание кавычки,
> после которой либо через ; свою команду, либо какой-нибудь
> OR, фактически убирающий проверку. В первом случае нужно
> отслеживать запросы с несколькими командами и либо отсекать
> все, что идет после ;, либо отсекать там потенциально
> опасные запросы. Во втором - проверять логические операции,
> способные сводить все выражение к безусловному true/false.
>
> Естественно, не панацея, но какую-то часть проблем уберет.

В первом случае, если фильтр не имеет шаблона исходного запроса, безосновательно делать предположения о том, какие именно SQL операторы инжектированы. Даже если фильтр будет знать о количестве SQL операторов в исходном запросе, этих данных не достаточно, чтобы принять решение об исполнении или неисполнении запроса целиком (атомарно), так как такой подход не защищает от инжектирования подзапросов или UNION операторов к исходному SQL оператору, позволяющего неавторизованно выдергивать данные из других таблиц и помещать их в выходные данные исходного запроса.
Во втором случае, чтобы отсечь потенциально опасные запросы, фильтру необходимо знать, какие именно действия разрешены для каждого SQL оператора полученного запроса, что весьма нетривиально в реализации и влечет за собой необходимость передачи в фильтр всё тогоже шаблона исходного запроса, к примеру, в формате функции c++ - "printf".

ИМХО, проблема решается тривиально - корректными клиентскими библиотеками доступа к данным SQL сервера и использованием параметризованных запросов. В общем, я так и не понял, зачем MariaDB нагородили этот фильтр.
<site updates> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach