The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В MariaDB будет встроен механизм борьбы с атаками, манипулирующими подстановкой SQL-кода

09.04.2015 22:35

Разработчики MariaDB планируют включить в состав следующего значительного выпуска средства для защиты от атак, основанных на подстановке SQL-кода (входит в MaxScale), а также поддержку шифрования страниц хранимых данных. Противодействие подстановке SQL-кода осуществляется через применение специальных фильтров, отсеивающих потенциально опасные запросы. Реализация указанных возможностей передана проекту компанией Google, которая использует MariaDB для обеспечения работы сервиса Cloud SQL.

  1. Главная ссылка к новости (http://www.zdnet.com/article/m...)
  2. OpenNews: Представлен прокси-сервер MariaDB MaxScale
  3. OpenNews: Компания SkySQL переименована в MariaDB Corporation
  4. OpenNews: Анонсированы новые межсетевые экраны для защиты web-приложений - IronBee и openWAF
  5. OpenNews: Стабильный выпуск СУБД MariaDB 10.0
  6. OpenNews: Основная инфраструктура Wikipedia переведена с MySQL на MariaDB
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42014-mariadb
Ключевые слова: mariadb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:23, 10/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    naxsi на уровне базы?
     
  • 1.2, bav (ok), 00:28, 10/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Лавры magiс_quotes не дают кому то покоя. В одной кривоте выпиливают, значит в другую необходимо запилить — баланс, епт.
     
     
  • 2.30, Капитан (??), 20:46, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разрабы MariaDB ответили, что фильтры будет в MaxScale
     

  • 1.4, Капитан (??), 00:36, 10/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Надеюсь это увидеть только в энтерпрайз-версии, подальше от галз нормальных людей.
     
  • 1.5, cmp (ok), 00:38, 10/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    А кто определяет степень потенциальной опасности.

    Сколько лет уже существует iptables и отлично справляется со своими задачами, даже дыкри в ssl'ях позволяет затыкать, почему бы не организовать аналогичную систему проверки полей по регекспам на уровне бд.

    Если грамотно пробросить ip-клиента в связке httpd->cgi->db, то можно будет даже перебор паролей cms средствами бд отслеживать.

     
     
  • 2.18, омномномнонимус (?), 11:17, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +6 +/
    ты знаешь что такое sql-injection? при чем здесь iptables?
     
     
  • 3.22, cmp (ok), 14:07, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    при том, что и ip пакет и post-запрос из html-ки в sql это пакет, который можно сравнить c шаблоном и принять или отклонить до того как он будет передан программе.
     
     
  • 4.25, омномномнонимус (?), 15:41, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    это как гвозди забивать микроскопом.
     
  • 4.33, anonimous (?), 22:23, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    всего-то надо всякое шифрование отключить, и запросы голым текстом гнать (чтоб iptables мог их распарсить)
     
     
  • 5.37, cmp (ok), 07:41, 11/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а кто говорит о использовании именно iptables?

    Неужто так сложно понять, что iptables это небольшая прослойка котороя в данном контексте помогает защитить тысячи программ хрен знает как написанных не переписывая их.

    в чем проблема использовать другую прослойку, которя будет защищать бд и хрен знает как написанные cms.

     

  • 1.7, Xasd (ok), 02:51, 10/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Противодействие подстановке SQL-кода осуществляется через применение специальных фильтров, отсеивающих потенциально опасные запросы

    пусть они просто отсеют все НЕскомпилированные заранее SQL-запросы.

    этого будет достаточно.

    а любители вбросить произвольную SQL-строку в SQL-базу данных -- должны быть помечены как опасные элементы для SQL-базы-данных.

     
     
  • 2.8, Отражение луны (ok), 03:29, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И давно ты долбишь втихаря?) SQL тем и полезен, что можно удобно цеплять любые данные, которые тебе нужны, причем уже в готовом виде. А большинство проблем SQL инъекций решается нормальным использованием ролей.
     
     
  • 3.14, Sergey722 (ok), 09:51, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы это, того, сами-то поосторожнее с веществами. Товарищ абсолютно справедливо указывает, что в MySQL (в Марии, полагаю, тоже) уже давно поддерживаются подготовленные запросы, которые и являются защитой от SQL-инекций и, на мой непрофессиональный взгляд, не особо ограничивают полет фантазии "художника". А набор костылей, который анализирует содержание запроса... ну Вы поняли.

    З.Ы.: Грешно так говорить, но меня не покидает мысль, что те, кто не использует подготовленные запросы, должны страдать, потому что это настолько эффективное и простое решение, что не знаю кем нужно быть... Хотя есть нехорошие люди, которые в книгах по тому же ПХП описывают старые майсиквельные функции, которые не поддерживают данную возможность (и соответственно о самой возможности тоже не пишут)...

     
     
  • 4.15, anono (?), 10:52, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Не по теме, но всегда хотелось узнать почему SQL - "сиквел". Он с 86-го года уже "эскуэль".
    Или Вы аксакал в мире БД и уже в 86 имели устоявшийся опыт работы с SEQUEL? =)
     
     
  • 5.17, клоун (?), 11:13, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чтобы произносить на одном дыхании:

    си-квэл SQL
    эс-ка 1C
    ась-ка ICQ

     
  • 5.19, anono (?), 11:51, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Не по теме, но всегда хотелось узнать почему SQL - "сиквел". Он
    > с 86-го года уже "эскуэль".
    > Или Вы аксакал в мире БД и уже в 86 имели устоявшийся
    > опыт работы с SEQUEL? =)

    Неожиданно...
    И неубедительно. Тянет только на индивидуальный случай.
    Ведь есть "скуль", "мускуль".

    И где дыхания меньше:
    1. "майсиквельные функции"
    2. "мускульные функции"

    Видимо все-таки аксакал =)

     
  • 5.20, Sergey722 (ok), 12:43, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Опыт семейной жизни учит меня не быть слишком придирчивым в восприятии слов и, соответственно, я теперь не особо заморациваюсь, когда сам употребляю слова (иногда это выходит боком, но в целом выгоднее), забочусь в основном о том, чтобы меня правильно поняли. Что касается Вашего вопроса, уже очень давно я начинал читать книгу по MySQL, где автор настаивал, что в случае ЯП правильно говорить "сиквел", а в случае MySQL - "МайЭсКьюЭль" (при этом он говорил, что это не строго и сколько людей - столько мнений). Т.ч. в этом смысле я не совсем корректно выразился, но как я уже говорил не придаю значения таким вещам. Линукс / Линэкс / Гню Линэкс, какая разница? Кто в теме тот поймёт, что имеется ввиду под словом Линукс (в зависимости от контекста).
     
     
  • 6.28, Moomintroll (ok), 17:24, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не особо заморациваюсь
    > чтобы меня правильно поняли

    Ну в общем понятно ;-)

     
  • 4.16, йцу (?), 11:03, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Подготовленные запросы не предотвратят подобного:

    > $pdo->prepare("SELECT * FROM table WHERE id = {$_GET{'id'}");

    Формально здесь имеется prepared-запрос. Фактически - "имеют" разработчика этого кода.


     
  • 4.21, userd (ok), 13:02, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ...не особо ограничивают полет фантазии "художника".

    В MySQL только безымянные плейсхолдеры - типа так:
    PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';

    Для простых случаев годно, для динамически создающихся запросов и для достаточно объёмных статических это неудобно. Да, конечно, можно создать препроцессор, который преобразует именованные плейсхолдеры в безымянные и создаст отображение для преобразования словаря фактических параметров запроса в вектор. Но если все эти хлопоты только ради исключения инъекции SQL, то мне такого не нужно - у меня библиотека и без того качественно предотвращает инъекцию.

    > ...потому что это настолько эффективное и простое решение...

    Это зависит от задачи.
    Если нужно выполнить 100500 однотипных запросов, то хлопоты на создание запроса скомпенсируются. а если у вас 100500 разных запросов, то это будет чистая потеря - в прикладном коде, в нагрузке на сервер, в сетевом трафике.

     
     
  • 5.23, тоже Аноним (ok), 14:40, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Собственно, инъекции отбиваются даже простейшими обертками типа safemysql.
    А от сервера как-то ожидаешь, что он будет оптимизирован по скорости, а не по защите от дурака. Если в Марии воцарится мода "мы во избежание инъекций будем проверять ваши запросы регулярками, а вы, если что, просто докупите еще серверов" - подозреваю, народ начнет менять Марию на Мускуль обратно.
     
  • 5.31, Crazy Alex (ok), 21:31, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот и вкрутили бы именованные вместо вот этого... не знаю даже, как назвать. И какая там потеря? Просто одна фаза подготовки к исполнению запроса (парсинг SQL во внутренние структуры) выполняется заранее.
     
  • 4.24, userd (ok), 15:28, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > З.Ы.: Грешно так говорить, но меня не покидает мысль, что те, кто не использует подготовленные запросы, должны страдать, потому что это настолько эффективное и простое решение...

    Кстати, припомнилось ещё одно затруднение при использование prepared statement в mysql.
    Нетрудно представить себе ситуацию, когда появляется запрос типа
    SELECT * FROM T WHERE code IN ('1','2','4');

    использовать вариант типа
    PREPARE stmt FROM 'SELECT * FROM T where code IN ?;';
    в доступной мне версии нельзя («Parameter markers can be used only where data values should appear, not for SQL keywords, identifiers, and so forth»).

    можно

    PREPARE stmt1 FROM 'SELECT * FROM T where code IN (?);';
    PREPARE stmt2 FROM 'SELECT * FROM T where code IN (?,?);';

    и т.д.,
    но это уже из области "страдать" к пользователям подготовленных запросов, не находите?

     
     
  • 5.27, Sergey722 (ok), 16:18, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я готов признать, что есть неудобные моменты.
    Более того, возможно я не прав, ибо не профессионал в этой области.
    Но те проблемы, которые Вы привели, решаются написанием относительно простого и относительно компактного кода.
    Если я попробую представить как я пытаюсь регэкспами парсить запросы с целью отсечь вредные вставки, у меня волосы встанут дыбом и нет никакой уверенности, что я учту все варианты.
    Ок, как я уже писал, я не профи и возможно есть либы, которые решают эту задачу, но как правильно было замечено выше - это дополнительная нагрузка на сервер и, все равно, мне эта задача кажется достаточно сложной, чтобы быть уверенным, что учтены все варианты или, что в следующей версии либы не сломают какую-то проверку. Костыль остается костылем, даже если он отполирован тысячами рук...
    Что может быть проще и логичнее идеи сказать серверу: вот запрос, а вот параметры и не важно насколько эти параметры похожи на другие запросы сервер будет знать, что это параметры???
     
  • 5.29, anonymous (??), 18:32, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Нетрудно представить себе ситуацию, когда появляется запрос типа
    > SELECT * FROM T WHERE code IN ('1','2','4');

    SELECT * FROM T WHERE code IN (select column_value from table(?));

    Синтаксис оракловский, но неужели в MariaDB нельзя массивы передавать?
    Единственную ситуацию встречал когда конкатенация запроса "кажется" проще,
    это когда неизвестно количество параметров которые буду в WHERE.
    Например на веб странице можно заполнить ноль или больше полей и эти поля будут в WHERE (либо WHERE вообще не будет, если ноль полей заполнено)

     
     
  • 6.32, Crazy Alex (ok), 21:33, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    такое, как вы написали - можно. Нельзя скормить сет из нескольких заначений из приложения одним параметром. Что решается простейшей обёрткой, разумеется.
     
     
  • 7.34, userd (ok), 22:50, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    простейшей обёрткой похвастаетесь?
     
  • 5.38, Bx (ok), 00:06, 13/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Те, кто не использует prepared statements, страдать обязаны Это только на первы... большой текст свёрнут, показать
     
     
  • 6.39, userd (ok), 13:00, 13/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Это только на первый взгляд. Вред таких запросов не очевиден, но есть. До сих пор бегают пара-тройка перловых скриптов, которым на вход IN может иногда попасть несколько сот параметров. Или даже тысяч, редко. Вместо ожидаемых единиц. :(

    А можно поподробнее о вреде?
    вот в документации на старинную версию MySQL ( https://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#function_in ) и неизвестную версию MariaDB ( https://mariadb.com/kb/en/mariadb/in/ ) пишут:

    «The search for the item then is done using a binary search.»

    т.е. если вынести за скобки
    1) необходимость компиляции большого списка,
    2) возможность выхода за некий предельный размер данных (max_allowed_packet) и
    3) затрат на сортировку этого списка,
    то сама по себе проверка на вхождение в список из 10000 элементов всего в 4 раза сложнее чем проверка для списка из 10 элементов.

    Пункты 1 и 3 значимы при некоторых неудачных сценариях использования БД, и вполне приемлемы для многих разумных случаев. Если Вы говорите о вреде в именно в контексте неудачных сценариев, то вред скорее в этих сценариях.

     
     
  • 7.40, Bx (ok), 17:46, 13/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я не против оператора IN, я против prepared statement с неопределенным, заранее неизвестным кол-ом входных параметров. Мне фантазия позволяет представить число праметров числом с 6 нулями. Или с 8.

    > 1) необходимость компиляции большого списка,

    Вот уж меньшая из проблем :)

    > 3) затрат на сортировку этого списка,

    Зачем?

    > то сама по себе проверка на вхождение в список из 10000 элементов всего в 4 раза сложнее чем проверка для списка из 10 элементов.

    Нет, она будет в тысячу раз сложнее. А уж если к таблице обратиться, да cache miss...

     
     
  • 8.41, userd (ok), 20:55, 13/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    для binary search https en wikipedia org wiki Binary_search_algorithm , вес... текст свёрнут, показать
     

  • 1.26, Verbum (ok), 16:01, 10/04/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    На уровне базы не должно работать никаких встроенных фильтров,
    т.к. логика приложения у всех оооочень разная.
    Кому пришла мысль встроить фильтры - либо стукнулся, либо наелся грибков.
     
     
  • 2.35, anonymous (??), 22:53, 10/04/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну что за категоричность, такая!
    Представь ситуацию - есть с десяток баз данныи и полсотни работющих с ними приложений.
    Что проще и дешевле?
    1. Сделать "enable filter_bad_sql" в конфиге баз.
    2. Проаудировать полсотни приложений, понять что и как исправить, внедрить исправления.

    Так что те, кому пришла эта мысль, не такие уж глупцы.

    А, и да, я просто уверен что у тебя есть пример как ты что-то сделал и правильно, и приемлимо для большинства, пользующегося этим чем-то.
    Так поделись! Глядишь и остальные начнут на тебя равняться.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру