О том, как Chrome мешает мне искать XSS-уязвимости.
Почему я ищу уязвимости?
Как и многие из вас, я делаю Code Review и первое, что ищу это конечно уязвимости. Когда уязвимость найдена в коде, хорошо бы проверить есть ли она на самом деле через браузер, потому что бывают «ложные тревоги». Это те случаи, когда данные уже приходят фильтрованными и XSS невозможен. Всегда полезно иметь возможность показать разработчику атаку в действии, потому что это хороший аргумент и помогает быстрее перейти к конструктивному решению проблемы, если есть сомнения, что уязвимость таки существует. Но проверку в браузере я делаю не часто — либо проблема очевидна прямо из кода, либо верят на слово. В общем искать уязвимости — это интересно.
Начало этой истории
Друг скинул ссылки на сайт, который ещё год назад имел XSS-уязвимость, о чем я писал владельцам ресурса. Стало интересно проверить снова. Проверил — XSS есть, но вот простейшего подтверждения выполнения JS я получить не смог!..
Я не ломаю сайты и не занимаюсь аудитом безопасности, поэтому возможно то, что я выяснил давно известно для специалистов, но для меня это было открытием.
Первые подозрения
Итак, стал проверять всевозможные варианты внедрения кода — но без результата. По ходу дела выяснил что и как фильтруется, какие есть проверки и прочее, но alert(1); упорно не выполнялся. По ходу дела нашелся ещё и XSRF — приятный бонус!
Возникло подозрение, что браузер меняет код, который он получил от сервера. Попробовал wget'ом получить HTML-код страницы — таки да, меняет, но странным образом. Сначала я подозревал, что он пытается закрывать теги, чтобы починить поломанную разметку, но оказалось, что дело в другом. Все это время я пользовался Google Chrome и мысль попробовать другой браузер как-то не приходила в голову (а зря!).
В конце концов простейшая проверка на XSS в FireFox дала положительный результат — супер! Я таки доказал, что уязвимость есть, но не понятно почему ничего не получилось в хроме?!.. Я понимаю, что браузеры могут один и тот же код рендерить по разному, но хром таки выкусывал мой внедренный код, как бы изощренно я это ни делал! Скриншот из хрома, где ссылка на внешний JS-файл заменена на about:blank:
Таким образом, можно атаковать пользователей ФФ, Оперы, ИЕ, но не Хрома. Это какое-то ущемление пользователей. Проблема не давала мне покоя и причина таки была найдена! Оказалось, что Google Chrome с 7й версии имеет фильтр XSS (Cross Site Scripting Auditor! Именно этот XSS Auditor и не давал мне возможность провести проверку наличия XSS.
Причина ясна, но проблема не решена. Неужто Chrome стал непреступной крепость?! Разве нет возможности этот фильтр обойти?! Если это так, что стоит всем рекомендовать использовать Chrome и забыть про XSS. Жизнь становится все проще и лучше!
Как обойти XSS Auditor в Google Chrome?
Но ведь не может так быть — верно? Вот и я не поверил.
Нужно же как-то обойти XSS Auditor в Chrome, чтобы восстановить вселенское равновесие. Я нашел такие способы:
- Нужно запустить браузер с ключом
--disable-xss-auditor. Отлично подходит для тестирования. - Если вы контролируете 2 параметра, то они вставляются в 2х местах на странице. Разбиваем код на 2 части и используем многострочные комментарии, чтобы закомментировать HTML между этими 2мя точками — подробности в Issue 96616: Security: Google Chrome Anti-XSS filter circumvention
- Если есть возможность оставить один тег незакрытым, то бразуер сам попытается его закрыть. Причем сначала отработает XSS Auditor, а затем браузер попытается закрыть теги.
- Отправить специальный HTTP-заголовок, который отключает XSS Auditor (Пруф):
header("X-XSS-Protection: 0");
Выводы
Использовать Google Chrome для тестирования XSS без доп. движений не получится — проще взять любой другой браузер.
А вот защищать себя от XSS вполне получится, но стоит помнить, что гугл использует свой браузер для сбора инфы — так что тут палка о двух концах.
Что ещё можно почитать?
- XSS ChEF: Chrome Extension Exploitation Framework
- Regular Expressions Considered Harmful in Client-Side XSS Filters
- Using Google Chrome for Security Testing
- Disabling default XSS filtering in IE8 – For Security Testers
Автор: VladSavitsky
