https://www.opennet.ru/openforum/vsluhforumID3/99431.html В выпуске (https://www.drupal.org/drupal-7.32) системе управления web-контентом Drupal 7.32 устранена критическая уязвимость (https://www.drupal.org/SA-CORE-2014-005) (CVE-2014-3704), позволяющая осуществить подстановку SQL-кода. Уязвимости присвоен наивысший уровень опасности (Highly critical (https://drupal.org/security-team/risk-levels)), сигнализирующий на возможность осуществления удалённой атаки, способной привести к получению доступа к системе.<br><br><br>Уязвимость вызвана ошибкой в реализации метода "prepared statement" в интерфейсе абстрактного доступа к БД и может быть эксплуатирована анонимным посетителем. Отправив специально оформленный запрос к сайту, реализованному на базе Drupal, атакующий может выполнить произвольный SQL-запрос на сервере, манипулируя которым можно добиться выполнения PHP-кода или получения доступа к серверу. Прототип эксплоита не публикуется, но в тестовом сценарии фигурирует передача значения "1 ;INSERT INTO {test} SET name = 'test12345678'; -- ".<br><br><br>URL: https://www.drupal.org https://www.opennet.ru/openforum/vsluhforumID3/99431.html#45 Fri, 17 Oct 2014 16:00:44 GMT Вот дурачье! На кой вообще было изобретать 7-ю версию, которое ничего общего не имеет с 6-й?<br>6-я - лучшая из Друпалов!<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#44 Fri, 17 Oct 2014 10:23:42 GMT &gt; А имеется ли разница между 100 потенциальными уязвимостями Жумлы или одной (найденной) <br>&gt; в CMSВАШЕЙМЕЧТЫ если результат практически один (потеря данных или что-то подобное) <br><br>Видите ли, практика показывает, что на условную сотню найденных уязвимостей жумлы приходится условно одна найденная дырка в "CMSНАШЕЙМЕЧТЫ". И с таким "авторским коллективом" оной жумлы это как было предсказуемо годы тому, так и останется. Увы.<br><br>Про "потенциальные уязвимости" можете рассказывать "потенциальным заказчикам", кинетические уже на этом молоке обожглись и мальчикам-руководам не верят.<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#43 Fri, 17 Oct 2014 07:05:06 GMT тут от мозга админа больше зависит, чем от скриптов.<br>как рассчитал безопасность системы.<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#40 Thu, 16 Oct 2014 16:13:00 GMT &gt; Cамо по себе числовые индексы или символьные не большое зло - частный случай индексов.<br><br>ни что ни у чего тут не частный случай.<br><br>&gt; Но это плата за универсальность.<br><br>это не универсальность, а головная боль от дебиловатых разработчиков пыха.<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#38 Thu, 16 Oct 2014 14:16:10 GMT Да есть такое. Типизированные массивы и списки тогда уж. Само по себе числовые индексы или символьные не большое зло - частный случай индексов. Но это плата за универсальность. Решили сэкономить на списках и кортэжах. Но ошибка не совсем с этим связана, "палёный код", впрочем от друпала не удивительно может быть.<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#37 Thu, 16 Oct 2014 13:40:05 GMT Perl-Pg и нормальная логика SQL с хранимыми процедурами, триггерами и т.д. Неубиваемая штука. Только все больше обрастает функционалом и обрастает.<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#36 Thu, 16 Oct 2014 13:20:21 GMT Можно еще сказать, что данная ошибка есть следствие дизайна PHP, в котором нет различия между обычными и ассоциативными массивами aka хешами. <br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#34 Thu, 16 Oct 2014 11:25:58 GMT Если она одна и закрыта, потенциальные злоумышленники переключатся на ПО, в котором их находят пачками.<br> https://www.opennet.ru/openforum/vsluhforumID3/99431.html#33 Thu, 16 Oct 2014 11:05:32 GMT &gt;по уму в том же drupal должно бы быть <br>&gt; 2 варианта <br>&gt; In ( :param ) <br>&gt; и <br>&gt; in ( #суперидентификатонедопустимыйдляsqlзапроса#paramscollection ) <br><br>хм почему то думал что in ( :param ) это из mysql -кого синтаксиса, по сути в друпале и есть второй вариант, просто с ошибкой в реализации.<br>