Уважаемые коллеги, возник вопрос по xss- уязвимости модуля ядрa Друпал 7 Search РЕшил изучить XSS-атаки на сайте Hackware.ru, там в статье приведен простой способ проверки на эту уязвимость. Вставил в поле поиска на своем друпаловском сайте простейший код из этой статьи "/><script>alert(1)</script>
, и убедился, что что вставленный код работает Получается, этот модуль уязвим против простейшей атаки xss! Что делать, есть ли альтернатива защищенная от этой напасти? Или, может быть патч какой посоветуете? Да, стоит стоит последня версия друпалд 7,64, ввсе модули обновлены.
Заранее спасибо.
Модуль Search уязвим к XSS атаке?
Главные вкладки
Лучший ответ
Всем - большое спасибо, с учетом высказанных замечаний стал смотреть - в одном из блоков у меня юзалась переменная $GET['q']... Из-за нее все и было. Как только удалил ее - все в норму пришло. ВСе логично, в эту переменную попадает все из из адресной строки, что после адреса сайта идет. При xss атаке то , что вводится в форму поиска, попадает в адресную строку. А у меня в блоке было так: print rawurldecode(l('', $_GET['q'].'?theme=mukcbs_blind_thm', array('html'=>TRUE)));
ЭТО было удобно для слабовидящих, они могли на любой странице сайта сразу перейити в свою тему именно на этой странице, а не с главной начинать, но... БЕЗОПАСНОСТЬ ЕСС-НО ВАЖНЕЕ. КАк убрал эту $GET['q'] - уязвимость исчезла.
Впрочем, можно не удалять $GET['q'], а проверять ее preg_match на наличие тега "script"... Или не стоит с огнем играть?
Комментарии
Скорее уязвима ваша тема оформления или была криво сделана темизация результатов поиска, что такой простой вектор и фурычит.
В теме вообще не менялись настройки для поиска, я же дал свой сайт, гляньте.
Темизацию результатов поиска не делал вовсе. С радостью узнал бы, как это делается, не подскажете, где читать
Хм.. уязвимость была подтверждена на сайте без самоделок в теме и модулях?
А где можно попробовать?
ну, вот мой сайт mukcbs.org, никаких самоделок в модулях. Тема своя, но к поиску даже не прикасался.
У друпала целая команда специалистов по безопасности. Не думаю, что они бы пропустили такое.
О спасибо проверим коробки.
Проверять не надо, извините, это я намудрил, уже исправил.
Занятно, что хром такую страницу блочит, а мозилла нет.
А об этом было в той статье на хакваре... В хроме есть встроенный блокировщик xss-атак. А идей, как можно поправить - нету?
Несколько сайтов проверил на 7ке - не работает алерт, везде сообщение-ошибка "Необходимо указать не менее одного ключевого слова, состоящего из 3 или более букв."
А ссылочки не пришлете? на эти "несколько сайтов на 7-ке"?
Это рабочие сайты, светить тут не хочу по этичным причинам.
protoftor пробовали эту XSS повторить на чистом развернутом друпале?
Я сейчас попробовал - алерта нет.
Чтобы понять как исправить - в любом случае надо сайт смотреть изнутри.
Всем - большое спасибо, с учетом высказанных замечаний стал смотреть - в одном из блоков у меня юзалась переменная $GET['q']... Из-за нее все и было. Как только удалил ее - все в норму пришло. ВСе логично, в эту переменную попадает все из из адресной строки, что после адреса сайта идет. При xss атаке то , что вводится в форму поиска, попадает в адресную строку. А у меня в блоке было так: print rawurldecode(l('', $_GET['q'].'?theme=mukcbs_blind_thm', array('html'=>TRUE)));
ЭТО было удобно для слабовидящих, они могли на любой странице сайта сразу перейити в свою тему именно на этой странице, а не с главной начинать, но... БЕЗОПАСНОСТЬ ЕСС-НО ВАЖНЕЕ. КАк убрал эту $GET['q'] - уязвимость исчезла.
Впрочем, можно не удалять $GET['q'], а проверять ее preg_match на наличие тега "script"... Или не стоит с огнем играть?
Посмотрите апи, мануалы, код, где-то должна быть специальная функция, которая это дело чистит.
В друпале есть функции очистки - https://api.drupal.org/api/drupal/includes%21common.inc/group/sanitizati... , в "чистом" php можно посмотреть в сторону https://secure.php.net/manual/en/filter.filters.sanitize.php .
Большое спасибо, , коллега, очень выручили! filter_xss() - самое то!