The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"В MariaDB будет встроен механизм борьбы с атаками, манипулир..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от opennews (??) on 10-Апр-15, 00:23 
Разработчики MariaDB планируют (http://www.zdnet.com/article/mariadb-corp-picks-off-speed-bo.../) включить в состав следующего значительного выпуска средства для защиты от атак, основанных на подстановке SQL-кода, а также поддержку шифрования хранимых данных. Противодействие подстановке SQL-кода осуществляется через применение специальных фильтров, отсеивающих потенциально опасные запросы. Реализация указанных возможностей передана (http://www.theregister.co.uk/2015/04/09/mariadb_google_secur.../) проекту компанией Google, которая использует (http://www.opennet.ru/opennews/art.shtml?num=37905) MariaDB для обеспечения работы сервиса Cloud SQL.


URL: http://www.zdnet.com/article/mariadb-corp-picks-off-speed-bo.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=42014

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +1 +/
Сообщение от Аноним (??) on 10-Апр-15, 00:23 
naxsi на уровне базы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +6 +/
Сообщение от bav (ok) on 10-Апр-15, 00:28 
Лавры magiс_quotes не дают кому то покоя. В одной кривоте выпиливают, значит в другую необходимо запилить — баланс, епт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +1 +/
Сообщение от Капитан (??) on 10-Апр-15, 20:46 
Разрабы MariaDB ответили, что фильтры будет в MaxScale
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +5 +/
Сообщение от Капитан (??) on 10-Апр-15, 00:36 
Надеюсь это увидеть только в энтерпрайз-версии, подальше от галз нормальных людей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  –7 +/
Сообщение от cmp (ok) on 10-Апр-15, 00:38 
А кто определяет степень потенциальной опасности.

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +6 +/
Сообщение от омномномнонимус on 10-Апр-15, 11:17 
ты знаешь что такое sql-injection? при чем здесь iptables?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

22. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от cmp (ok) on 10-Апр-15, 14:07 
при том, что и ip пакет и post-запрос из html-ки в sql это пакет, который можно сравнить c шаблоном и принять или отклонить до того как он будет передан программе.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

25. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +3 +/
Сообщение от омномномнонимус on 10-Апр-15, 15:41 
это как гвозди забивать микроскопом.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

33. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +2 +/
Сообщение от anonimous on 10-Апр-15, 22:23 
всего-то надо всякое шифрование отключить, и запросы голым текстом гнать (чтоб iptables мог их распарсить)
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

37. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +1 +/
Сообщение от cmp (ok) on 11-Апр-15, 07:41 
а кто говорит о использовании именно iptables?

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

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

7. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +1 +/
Сообщение от Xasd (ok) on 10-Апр-15, 02:51 
> Противодействие подстановке SQL-кода осуществляется через применение специальных фильтров, отсеивающих потенциально опасные запросы

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

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  –1 +/
Сообщение от Отражение луны (ok) on 10-Апр-15, 03:29 
И давно ты долбишь втихаря?) SQL тем и полезен, что можно удобно цеплять любые данные, которые тебе нужны, причем уже в готовом виде. А большинство проблем SQL инъекций решается нормальным использованием ролей.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +2 +/
Сообщение от Sergey722 (ok) on 10-Апр-15, 09:51 
Вы это, того, сами-то поосторожнее с веществами. Товарищ абсолютно справедливо указывает, что в MySQL (в Марии, полагаю, тоже) уже давно поддерживаются подготовленные запросы, которые и являются защитой от SQL-инекций и, на мой непрофессиональный взгляд, не особо ограничивают полет фантазии "художника". А набор костылей, который анализирует содержание запроса... ну Вы поняли.

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от anono on 10-Апр-15, 10:52 
Не по теме, но всегда хотелось узнать почему SQL - "сиквел". Он с 86-го года уже "эскуэль".
Или Вы аксакал в мире БД и уже в 86 имели устоявшийся опыт работы с SEQUEL? =)
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  –1 +/
Сообщение от клоун on 10-Апр-15, 11:13 
Чтобы произносить на одном дыхании:

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от anono on 10-Апр-15, 11:51 
> Не по теме, но всегда хотелось узнать почему SQL - "сиквел". Он
> с 86-го года уже "эскуэль".
> Или Вы аксакал в мире БД и уже в 86 имели устоявшийся
> опыт работы с SEQUEL? =)

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

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

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

20. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +2 +/
Сообщение от Sergey722 (ok) on 10-Апр-15, 12:43 
Опыт семейной жизни учит меня не быть слишком придирчивым в восприятии слов и, соответственно, я теперь не особо заморациваюсь, когда сам употребляю слова (иногда это выходит боком, но в целом выгоднее), забочусь в основном о том, чтобы меня правильно поняли. Что касается Вашего вопроса, уже очень давно я начинал читать книгу по MySQL, где автор настаивал, что в случае ЯП правильно говорить "сиквел", а в случае MySQL - "МайЭсКьюЭль" (при этом он говорил, что это не строго и сколько людей - столько мнений). Т.ч. в этом смысле я не совсем корректно выразился, но как я уже говорил не придаю значения таким вещам. Линукс / Линэкс / Гню Линэкс, какая разница? Кто в теме тот поймёт, что имеется ввиду под словом Линукс (в зависимости от контекста).
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +1 +/
Сообщение от Moomintroll (ok) on 10-Апр-15, 17:24 
> не особо заморациваюсь
> чтобы меня правильно поняли

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

16. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от йцу on 10-Апр-15, 11:03 
Подготовленные запросы не предотвратят подобного:

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

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


Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

21. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от userd (ok) on 10-Апр-15, 13:02 
> ...не особо ограничивают полет фантазии "художника".

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

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

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

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

23. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +3 +/
Сообщение от тоже Аноним email(ok) on 10-Апр-15, 14:40 
Собственно, инъекции отбиваются даже простейшими обертками типа safemysql.
А от сервера как-то ожидаешь, что он будет оптимизирован по скорости, а не по защите от дурака. Если в Марии воцарится мода "мы во избежание инъекций будем проверять ваши запросы регулярками, а вы, если что, просто докупите еще серверов" - подозреваю, народ начнет менять Марию на Мускуль обратно.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

31. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от Crazy Alex (ok) on 10-Апр-15, 21:31 
Ну вот и вкрутили бы именованные вместо вот этого... не знаю даже, как назвать. И какая там потеря? Просто одна фаза подготовки к исполнению запроса (парсинг SQL во внутренние структуры) выполняется заранее.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

24. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от userd (ok) on 10-Апр-15, 15:28 
> З.Ы.: Грешно так говорить, но меня не покидает мысль, что те, кто не использует подготовленные запросы, должны страдать, потому что это настолько эффективное и простое решение...

Кстати, припомнилось ещё одно затруднение при использование 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 (?,?);';

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

27. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от Sergey722 (ok) on 10-Апр-15, 16:18 
Я готов признать, что есть неудобные моменты.
Более того, возможно я не прав, ибо не профессионал в этой области.
Но те проблемы, которые Вы привели, решаются написанием относительно простого и относительно компактного кода.
Если я попробую представить как я пытаюсь регэкспами парсить запросы с целью отсечь вредные вставки, у меня волосы встанут дыбом и нет никакой уверенности, что я учту все варианты.
Ок, как я уже писал, я не профи и возможно есть либы, которые решают эту задачу, но как правильно было замечено выше - это дополнительная нагрузка на сервер и, все равно, мне эта задача кажется достаточно сложной, чтобы быть уверенным, что учтены все варианты или, что в следующей версии либы не сломают какую-то проверку. Костыль остается костылем, даже если он отполирован тысячами рук...
Что может быть проще и логичнее идеи сказать серверу: вот запрос, а вот параметры и не важно насколько эти параметры похожи на другие запросы сервер будет знать, что это параметры???
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

29. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от anonymous (??) on 10-Апр-15, 18:32 
> Нетрудно представить себе ситуацию, когда появляется запрос типа
> SELECT * FROM T WHERE code IN ('1','2','4');

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

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

32. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от Crazy Alex (ok) on 10-Апр-15, 21:33 
такое, как вы написали - можно. Нельзя скормить сет из нескольких заначений из приложения одним параметром. Что решается простейшей обёрткой, разумеется.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

34. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от userd (ok) on 10-Апр-15, 22:50 
простейшей обёрткой похвастаетесь?
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

38. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от Bx (ok) on 13-Апр-15, 00:06 
>> З.Ы.: Грешно так говорить, но меня не покидает мысль, что те, кто не использует подготовленные запросы, должны страдать, потому что это настолько эффективное и простое решение...

Те, кто не использует prepared statements, страдать обязаны.

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

Это только на первый взгляд. Вред таких запросов не очевиден, но есть. До сих пор бегают пара-тройка перловых скриптов, которым на вход IN может иногда попасть несколько сот параметров. Или даже тысяч, редко. Вместо ожидаемых единиц. :(

> использовать вариант типа
> 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»).

MySQL не умеет массивы. Функций, подобных UNNEST, в MySQL нет и, пока, не предвидется. А если я не ошибаюсь - и не будет. После того, как мускуль был выкуплен Ораклом, надежд на мускуль совсем мало. Добавление нового объекта хранения(гео-данные) в INNODB-стор - это вообще отдельная песня. SQLite - отличное решение для небольших баз там, где невозможно/затруднительно разворчивание постгреса.
IMHO. Опыта работы с SQLite совсем мало. Про FTS ихний читал, интересно, рекомендую всем, кто хочет FTS использовать.

> можно
> PREPARE stmt1 FROM 'SELECT * FROM T where code IN (?);';
> PREPARE stmt2 FROM 'SELECT * FROM T where code IN (?,?);';

И не будет никогда, КМК. Парсер применяется при подготовке выражения, гонять его для каждого параметра - не самый оптимальный вариант.

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

MySQL - прибежище адептов ORM, ибо просто, относительно предскауемо и достаточно стабильно. Любители ORM ОБЯЗАНЫ страдать. Хотя, конечно, допускаю исключения.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

39. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от userd (ok) on 13-Апр-15, 13:00 
> Это только на первый взгляд. Вред таких запросов не очевиден, но есть. До сих пор бегают пара-тройка перловых скриптов, которым на вход IN может иногда попасть несколько сот параметров. Или даже тысяч, редко. Вместо ожидаемых единиц. :(

А можно поподробнее о вреде?
вот в документации на старинную версию MySQL ( https://dev.mysql.com/doc/refman/5.0/en/comparison-operators... ) и неизвестную версию 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 значимы при некоторых неудачных сценариях использования БД, и вполне приемлемы для многих разумных случаев. Если Вы говорите о вреде в именно в контексте неудачных сценариев, то вред скорее в этих сценариях.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

40. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от Bx (ok) on 13-Апр-15, 17:46 
Я не против оператора IN, я против prepared statement с неопределенным, заранее неизвестным кол-ом входных параметров. Мне фантазия позволяет представить число праметров числом с 6 нулями. Или с 8.

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

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

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

Зачем?

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

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

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

41. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от userd (ok) on 13-Апр-15, 20:55 
> Зачем?

для binary search ( https://en.wikipedia.org/wiki/Binary_search_algorithm ), вестимо.

и ещё - в MySQL IN(values_list) и IN(subquery) имеют разные, никак не связанные реализации.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

26. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +5 +/
Сообщение от Verbum (ok) on 10-Апр-15, 16:01 
На уровне базы не должно работать никаких встроенных фильтров,
т.к. логика приложения у всех оооочень разная.
Кому пришла мысль встроить фильтры - либо стукнулся, либо наелся грибков.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."  +/
Сообщение от anonymous (??) on 10-Апр-15, 22:53 
Ну что за категоричность, такая!
Представь ситуацию - есть с десяток баз данныи и полсотни работющих с ними приложений.
Что проще и дешевле?
1. Сделать "enable filter_bad_sql" в конфиге баз.
2. Проаудировать полсотни приложений, понять что и как исправить, внедрить исправления.

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

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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