https://www.opennet.ru/openforum/vsluhforumID3/101999.html Разработчики MariaDB планируют (http://www.zdnet.com/article/mariadb-corp-picks-off-speed-bottlenecks-and-tightens-anti-sql-injection-measures/) включить в состав следующего значительного выпуска средства для защиты от атак, основанных на подстановке SQL-кода, а также поддержку шифрования хранимых данных. Противодействие подстановке SQL-кода осуществляется через применение специальных фильтров, отсеивающих потенциально опасные запросы. Реализация указанных возможностей передана (http://www.theregister.co.uk/2015/04/09/mariadb_google_security_injection/) проекту компанией Google, которая использует (http://www.opennet.ru/opennews/art.shtml?num=37905) MariaDB для обеспечения работы сервиса Cloud SQL. <br><br><br><br><br>URL: http://www.zdnet.com/article/mariadb-corp-picks-off-speed-bottlenecks-and-tightens-anti-sql-injection-measures/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=42014<br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#41 Mon, 13 Apr 2015 17:55:13 GMT &gt; Зачем?<br><br>для binary search ( https://en.wikipedia.org/wiki/Binary_search_algorithm ), вестимо.<br><br>и ещё - в MySQL IN(values_list) и IN(subquery) имеют разные, никак не связанные реализации. <br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#40 Mon, 13 Apr 2015 14:46:02 GMT Я не против оператора IN, я против prepared statement с неопределенным, заранее неизвестным кол-ом входных параметров. Мне фантазия позволяет представить число праметров числом с 6 нулями. Или с 8.<br><br>&gt; 1) необходимость компиляции большого списка, <br><br>Вот уж меньшая из проблем :)<br><br>&gt; 3) затрат на сортировку этого списка, <br><br>Зачем?<br><br>&gt; то сама по себе проверка на вхождение в список из 10000 элементов всего в 4 раза сложнее чем проверка для списка из 10 элементов.<br><br>Нет, она будет в тысячу раз сложнее. А уж если к таблице обратиться, да cache miss...<br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#39 Mon, 13 Apr 2015 10:00:16 GMT &gt; Это только на первый взгляд. Вред таких запросов не очевиден, но есть. До сих пор бегают пара-тройка перловых скриптов, которым на вход IN может иногда попасть несколько сот параметров. Или даже тысяч, редко. Вместо ожидаемых единиц. :(<br><br>А можно поподробнее о вреде?<br>вот в документации на старинную версию MySQL ( https://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#function_in ) и неизвестную версию MariaDB ( https://mariadb.com/kb/en/mariadb/in/ ) пишут:<br><br>&#171;The search for the item then is done using a binary search.&#187;<br><br>т.е. если вынести за скобки <br>1) необходимость компиляции большого списка, <br>2) возможность выхода за некий предельный размер данных (max_allowed_packet) и <br>3) затрат на сортировку этого списка, <br>то сама по себе проверка на вхождение в список из 10000 элементов всего в 4 раза сложнее чем проверка для списка из 10 элементов.<br><br>Пункты 1 и 3 значимы при некоторых неудачных сценариях использования БД, и вполне приемлемы для многих разумных случаев. Если Вы говорите о https://www.opennet.ru/openforum/vsluhforumID3/101999.html#38 Sun, 12 Apr 2015 21:06:32 GMT &gt;&gt; З.Ы.: Грешно так говорить, но меня не покидает мысль, что те, кто не использует подготовленные запросы, должны страдать, потому что это настолько эффективное и простое решение...<br><br>Те, кто не использует prepared statements, страдать обязаны.<br><br>&gt; Кстати, припомнилось ещё одно затруднение при использование prepared statement в mysql. <br>&gt; Нетрудно представить себе ситуацию, когда появляется запрос типа <br>&gt; SELECT * FROM T WHERE code IN ('1','2','4'); <br><br>Это только на первый взгляд. Вред таких запросов не очевиден, но есть. До сих пор бегают пара-тройка перловых скриптов, которым на вход IN может иногда попасть несколько сот параметров. Или даже тысяч, редко. Вместо ожидаемых единиц. :(<br><br>&gt; использовать вариант типа <br>&gt; PREPARE stmt FROM 'SELECT * FROM T where code IN ?;'; <br>&gt; в доступной мне версии нельзя (&#171;Parameter markers can be used only where <br>&gt; data values should appear, not for SQL keywords, identifiers, and so <br>&gt; forth&#187;).<br><br>MySQL не умеет массивы. Функций, подобных UNNEST, в MySQL нет и, https://www.opennet.ru/openforum/vsluhforumID3/101999.html#37 Sat, 11 Apr 2015 04:41:26 GMT а кто говорит о использовании именно iptables?<br><br>Неужто так сложно понять, что iptables это небольшая прослойка котороя в данном контексте помогает защитить тысячи программ хрен знает как написанных не переписывая их.<br><br>в чем проблема использовать другую прослойку, которя будет защищать бд и хрен знает как написанные cms.<br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#35 Fri, 10 Apr 2015 19:53:29 GMT Ну что за категоричность, такая!<br>Представь ситуацию - есть с десяток баз данныи и полсотни работющих с ними приложений.<br>Что проще и дешевле?<br>1. Сделать "enable filter_bad_sql" в конфиге баз.<br>2. Проаудировать полсотни приложений, понять что и как исправить, внедрить исправления.<br><br>Так что те, кому пришла эта мысль, не такие уж глупцы.<br><br>А, и да, я просто уверен что у тебя есть пример как ты что-то сделал и правильно, и приемлимо для большинства, пользующегося этим чем-то.<br>Так поделись! Глядишь и остальные начнут на тебя равняться.<br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#34 Fri, 10 Apr 2015 19:50:37 GMT простейшей обёрткой похвастаетесь?<br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#33 Fri, 10 Apr 2015 19:23:13 GMT всего-то надо всякое шифрование отключить, и запросы голым текстом гнать (чтоб iptables мог их распарсить)<br> https://www.opennet.ru/openforum/vsluhforumID3/101999.html#32 Fri, 10 Apr 2015 18:33:46 GMT такое, как вы написали - можно. Нельзя скормить сет из нескольких заначений из приложения одним параметром. Что решается простейшей обёрткой, разумеется.<br>