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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
От прочтения новости испытывал когнитивный диссонанс, пока... 10.04.15 13:33  Число просмотров: 1411
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
От прочтения новости испытывал когнитивный диссонанс, пока не прочел твою ремарку.
Даже если отделить новость о шифровании таблиц от новости про встроенный фильтр для борьбы с SQL-инъекциями, то последняя также вызывает недоумение. Ведь для того, чтобы некий фильтр SQL сервера мог отличить полученный от клиента запрос с SQL инъекцией от штатного запроса, он должен обладать каким-то шаблоном штатного запроса или же иметь информацию о том, какие действия ожидаемы и позволены данному запросу. В обоих случаях, это совсем не очевидное решение проблемы SQL инъекций.
<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-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach