Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

В MariaDB будет встроен механизм борьбы с атаками, манипулир..., opennews (??), 10-Апр-15, (0) [смотреть все] naxsi на уровне базы , Аноним (-), 00:23 , 10-Апр-15, (1) +1 Лавры magiс_quotes не дают кому то покоя В одной кривоте выпиливают, значит в д, bav (ok), 00:28 , 10-Апр-15, (2) +6 // Разрабы MariaDB ответили, что фильтры будет в MaxScale, Капитан (??), 20:46 , 10-Апр-15, (30) +1 Надеюсь это увидеть только в энтерпрайз-версии, подальше от галз нормальных люде, Капитан (??), 00:36 , 10-Апр-15, (4) +5 А кто определяет степень потенциальной опасности Сколько лет уже существует ipta, cmp (ok), 00:38 , 10-Апр-15, (5) –7 // ты знаешь что такое sql-injection при чем здесь iptables , омномномнонимус (?), 11:17 , 10-Апр-15, (18) +6 // при том, что и ip пакет и post-запрос из html-ки в sql это пакет, который можно , cmp (ok), 14:07 , 10-Апр-15, (22) // это как гвозди забивать микроскопом , омномномнонимус (?), 15:41 , 10-Апр-15, (25) +3 всего-то надо всякое шифрование отключить, и запросы голым текстом гнать чтоб i, anonimous (?), 22:23 , 10-Апр-15, (33) +2 а кто говорит о использовании именно iptables Неужто так сложно понять, что ipta, cmp (ok), 07:41 , 11-Апр-15, (37) +1 пусть они просто отсеют все НЕскомпилированные заранее SQL-запросы этого будет д, Xasd (ok), 02:51 , 10-Апр-15, (7) +2 // И давно ты долбишь втихаря SQL тем и полезен, что можно удобно цеплять любые д, Отражение луны (ok), 03:29 , 10-Апр-15, (8) –1   // Вы это, того, сами-то поосторожнее с веществами Товарищ абсолютно справедливо у, Sergey722 (ok), 09:51 , 10-Апр-15, (14) +2   // Не по теме, но всегда хотелось узнать почему SQL - сиквел Он с 86-го года уже, anono (?), 10:52 , 10-Апр-15, (15)   Чтобы произносить на одном дыхании си-квэл SQLэс-ка 1Cась-ка ICQ, клоун (?), 11:13 , 10-Апр-15, (17) –1   Неожиданно И неубедительно Тянет только на индивидуальный случай Ведь есть с, anono (?), 11:51 , 10-Апр-15, (19)   Опыт семейной жизни учит меня не быть слишком придирчивым в восприятии слов и, с, Sergey722 (ok), 12:43 , 10-Апр-15, (20) +2   Ну в общем понятно - , Moomintroll (ok), 17:24 , 10-Апр-15, (28) +1   Подготовленные запросы не предотвратят подобного Формально здесь имеется prepare, йцу (?), 11:03 , 10-Апр-15, (16)   В MySQL только безымянные плейсхолдеры - типа так PREPARE stmt1 FROM SELECT SQR, userd (ok), 13:02 , 10-Апр-15, (21)   Собственно, инъекции отбиваются даже простейшими обертками типа safemysql А от с, тоже Аноним (ok), 14:40 , 10-Апр-15, (23) +3   Ну вот и вкрутили бы именованные вместо вот этого не знаю даже, как назвать , Crazy Alex (ok), 21:31 , 10-Апр-15, (31)   Кстати, припомнилось ещё одно затруднение при использование prepared statement в, userd (ok), 15:28 , 10-Апр-15, (24)   Я готов признать, что есть неудобные моменты Более того, возможно я не прав, ибо, Sergey722 (ok), 16:18 , 10-Апр-15, (27)   SELECT FROM T WHERE code IN select column_value from table Синтаксис орак, anonymous (??), 18:32 , 10-Апр-15, (29)   такое, как вы написали - можно Нельзя скормить сет из нескольких заначений из п, Crazy Alex (ok), 21:33 , 10-Апр-15, (32)   простейшей обёрткой похвастаетесь , userd (ok), 22:50 , 10-Апр-15, (34)   Те, кто не использует prepared statements, страдать обязаны Это только на первый, Bx (ok), 00:06 , 13-Апр-15, (38)   А можно поподробнее о вреде вот в документации на старинную версию MySQL https, userd (ok), 13:00 , 13-Апр-15, (39)   Я не против оператора IN, я против prepared statement с неопределенным, заранее , Bx (ok), 17:46 , 13-Апр-15, (40)   для binary search https en wikipedia org wiki Binary_search_algorithm , вес, userd (ok), 20:55 , 13-Апр-15, (41)   На уровне базы не должно работать никаких встроенных фильтров,т к логика прилож, Verbum (ok), 16:01 , 10-Апр-15, (26) +4 // Ну что за категоричность, такая Представь ситуацию - есть с десяток баз данныи и, anonymous (??), 22:53 , 10-Апр-15, (35) 1,2,4,5,7,26

Сообщения

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

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

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

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

	17. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	–1 +/–
	Сообщение от клоун (?), 10-Апр-15, 11:13
	Чтобы произносить на одном дыхании: си-квэл SQL эс-ка 1C ась-ка ICQ
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	16. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	+/–
	Сообщение от йцу (?), 10-Апр-15, 11:03
	Подготовленные запросы не предотвратят подобного: > $pdo->prepare("SELECT * FROM table WHERE id = {$_GET{'id'}"); Формально здесь имеется prepared-запрос. Фактически - "имеют" разработчика этого кода.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	21. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	+/–
	Сообщение от userd (ok), 10-Апр-15, 13:02
	> ...не особо ограничивают полет фантазии "художника". В MySQL только безымянные плейсхолдеры - типа так: PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse'; Для простых случаев годно, для динамически создающихся запросов и для достаточно объёмных статических это неудобно. Да, конечно, можно создать препроцессор, который преобразует именованные плейсхолдеры в безымянные и создаст отображение для преобразования словаря фактических параметров запроса в вектор. Но если все эти хлопоты только ради исключения инъекции SQL, то мне такого не нужно - у меня библиотека и без того качественно предотвращает инъекцию. > ...потому что это настолько эффективное и простое решение... Это зависит от задачи. Если нужно выполнить 100500 однотипных запросов, то хлопоты на создание запроса скомпенсируются. а если у вас 100500 разных запросов, то это будет чистая потеря - в прикладном коде, в нагрузке на сервер, в сетевом трафике.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

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

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

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

	29. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	+/–
	Сообщение от anonymous (??), 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), 10-Апр-15, 21:33
	такое, как вы написали - можно. Нельзя скормить сет из нескольких заначений из приложения одним параметром. Что решается простейшей обёрткой, разумеется.
	Ответить | Правка | Наверх | Cообщить модератору

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

	38. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	+/–
	Сообщение от Bx (ok), 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), 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 значимы при некоторых неудачных сценариях использования БД, и вполне приемлемы для многих разумных случаев. Если Вы говорите о вреде в именно в контексте неудачных сценариев, то вред скорее в этих сценариях.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	+/–
	Сообщение от Bx (ok), 13-Апр-15, 17:46
	Я не против оператора IN, я против prepared statement с неопределенным, заранее неизвестным кол-ом входных параметров. Мне фантазия позволяет представить число праметров числом с 6 нулями. Или с 8. > 1) необходимость компиляции большого списка, Вот уж меньшая из проблем :) > 3) затрат на сортировку этого списка, Зачем? > то сама по себе проверка на вхождение в список из 10000 элементов всего в 4 раза сложнее чем проверка для списка из 10 элементов. Нет, она будет в тысячу раз сложнее. А уж если к таблице обратиться, да cache miss...
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В MariaDB будет встроен механизм борьбы с атаками, манипулир..."	+/–
	Сообщение от userd (ok), 13-Апр-15, 20:55
	> Зачем? для binary search ( https://en.wikipedia.org/wiki/Binary_search_algorithm ), вестимо. и ещё - в MySQL IN(values_list) и IN(subquery) имеют разные, никак не связанные реализации.
	Ответить | Правка | Наверх | Cообщить модератору

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

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