информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяВсе любят медГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
от простых инъекций защититься можно 10.04.15 19:03  Число просмотров: 1759
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Если совсем навскидку, типовая инъекция - втыкание кавычки, после которой либо через ; свою команду, либо какой-нибудь OR, фактически убирающий проверку. В первом случае нужно отслеживать запросы с несколькими командами и либо отсекать все, что идет после ;, либо отсекать там потенциально опасные запросы. Во втором - проверять логические операции, способные сводить все выражение к безусловному true/false.

Естественно, не панацея, но какую-то часть проблем уберет.
<site updates>
MariaDB добавляет шифрование и защиту от SQL-инъекций 09.04.15 18:30  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
MariaDB добавляет шифрование и защиту от SQL-инъекций
ZDNet http://www.zdnet.com/article/mariadb-corp-picks-off-speed-bottlenecks-and-tightens-anti-sql-injection-measures/

Готовящаяся к выходу версия 10.1 популярного форка MySQL MariaDB будет включать встроенный фильтр для борьбы с SQL-инъекциями и шифрование таблиц, полученное в подарок от Google, перешедшего на MariaDB около года назад.
Забавно, как эти два факта склеились в один у The Register [ http://www.theregister.co.uk/2015/04/09/mariadb_google_security_injection/ ]: по их версии, "Google is dropping encryption into MariaDB, the fork of Oracle’s MySQL, to help shut out SQL injection attacks" ("Google встраивает шифрование в MariaDB, чтобы помочь бороться с SQL-инъекциями") - что, конечно, является полным бредом.


Полный текст
От прочтения новости испытывал когнитивный диссонанс, пока... 10.04.15 13:33  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
От прочтения новости испытывал когнитивный диссонанс, пока не прочел твою ремарку.
Даже если отделить новость о шифровании таблиц от новости про встроенный фильтр для борьбы с SQL-инъекциями, то последняя также вызывает недоумение. Ведь для того, чтобы некий фильтр SQL сервера мог отличить полученный от клиента запрос с SQL инъекцией от штатного запроса, он должен обладать каким-то шаблоном штатного запроса или же иметь информацию о том, какие действия ожидаемы и позволены данному запросу. В обоих случаях, это совсем не очевидное решение проблемы SQL инъекций.
от простых инъекций защититься можно 10.04.15 19:03  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Если совсем навскидку, типовая инъекция - втыкание кавычки, после которой либо через ; свою команду, либо какой-нибудь OR, фактически убирающий проверку. В первом случае нужно отслеживать запросы с несколькими командами и либо отсекать все, что идет после ;, либо отсекать там потенциально опасные запросы. Во втором - проверять логические операции, способные сводить все выражение к безусловному true/false.

Естественно, не панацея, но какую-то часть проблем уберет.
В первом случае, если фильтр не имеет шаблона исходного... 13.04.15 10:56  
Автор: Den <Denis> Статус: 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 хуже, но это первые варианты, которые пришли в голову, наверняка там полно разных эвристик.

Естественно, нормальные клиентские библиотеки все это и так лечат.
1




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


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