- PVSM.RU - https://www.pvsm.ru -
О том, как Chrome мешает мне искать XSS-уязвимости.
Как и многие из вас, я делаю Code Review и первое, что ищу это конечно уязвимости. Когда уязвимость найдена в коде, хорошо бы проверить есть ли она на самом деле через браузер, потому что бывают «ложные тревоги». Это те случаи, когда данные уже приходят фильтрованными и XSS невозможен. Всегда полезно иметь возможность показать разработчику атаку в действии, потому что это хороший аргумент и помогает быстрее перейти к конструктивному решению проблемы, если есть сомнения, что уязвимость таки существует. Но проверку в браузере я делаю не часто — либо проблема очевидна прямо из кода, либо верят на слово. В общем искать уязвимости — это интересно.
Друг скинул ссылки на сайт, который ещё год назад имел XSS-уязвимость, о чем я писал владельцам ресурса. Стало интересно проверить снова. Проверил — XSS есть, но вот простейшего подтверждения выполнения JS я получить не смог!..
Я не ломаю сайты и не занимаюсь аудитом безопасности, поэтому возможно то, что я выяснил давно известно для специалистов, но для меня это было открытием.
Итак, стал проверять всевозможные варианты внедрения кода [1] — но без результата. По ходу дела выяснил что и как фильтруется, какие есть проверки и прочее, но alert(1); упорно не выполнялся. По ходу дела нашелся ещё и XSRF — приятный бонус!
Возникло подозрение, что браузер меняет код, который он получил от сервера. Попробовал wget'ом получить HTML-код страницы — таки да, меняет, но странным образом. Сначала я подозревал, что он пытается закрывать теги, чтобы починить поломанную разметку, но оказалось, что дело в другом. Все это время я пользовался Google Chrome и мысль попробовать другой браузер как-то не приходила в голову (а зря!).
В конце концов простейшая проверка на XSS в FireFox дала положительный результат — супер! Я таки доказал, что уязвимость есть, но не понятно почему ничего не получилось в хроме?!.. Я понимаю, что браузеры могут один и тот же код рендерить по разному, но хром таки выкусывал мой внедренный код, как бы изощренно я это ни делал! Скриншот из хрома, где ссылка на внешний JS-файл заменена на about:blank
:
Таким образом, можно атаковать пользователей ФФ, Оперы, ИЕ, но не Хрома. Это какое-то ущемление пользователей. Проблема не давала мне покоя и причина таки была найдена! Оказалось, что Google Chrome с 7й версии имеет фильтр XSS (Cross Site Scripting Auditor [2]! Именно этот XSS Auditor и не давал мне возможность провести проверку наличия XSS.
Причина ясна, но проблема не решена. Неужто Chrome стал непреступной крепость?! Разве нет возможности этот фильтр обойти?! Если это так, что стоит всем рекомендовать использовать Chrome и забыть про XSS. Жизнь становится все проще и лучше!
Но ведь не может так быть — верно? Вот и я не поверил.
Нужно же как-то обойти XSS Auditor в Chrome, чтобы восстановить вселенское равновесие. Я нашел такие способы:
--disable-xss-auditor
. Отлично подходит для тестирования.header("X-XSS-Protection: 0");
Использовать Google Chrome для тестирования XSS без доп. движений не получится — проще взять любой другой браузер.
А вот защищать себя от XSS вполне получится, но стоит помнить, что гугл использует свой браузер для сбора инфы [5] — так что тут палка о двух концах.
Автор: VladSavitsky
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/google/6667
Ссылки в тексте:
[1] всевозможные варианты внедрения кода: http://ha.ckers.org/xss.html
[2] Google Chrome с 7й версии имеет фильтр XSS (Cross Site Scripting Auditor: http://news.softpedia.com/news/Chrome-Gets-XSS-Filter-and-Starts-Disabling-Outdated-Plug-Ins-159498.shtml
[3] Issue 96616: Security: Google Chrome Anti-XSS filter circumvention: http://code.google.com/p/chromium/issues/detail?id=96616
[4] Пруф: http://code.google.com/p/chromium/issues/detail?id=98787#c27
[5] гугл использует свой браузер для сбора инфы: http://habrahabr.ru/post/138867/
[6] XSS ChEF: Chrome Extension Exploitation Framework: http://www.hackingtricks.in/2012/03/xss-chef-chrome-extension-exploitation.htm
[7] Regular Expressions Considered Harmful in Client-Side XSS Filters: http://www.collinjackson.com/research/xssauditor.pdf
[8] Using Google Chrome for Security Testing: http://www.frameloss.org/2011/11/01/using-google-chrome-for-security-testing/
[9] Disabling default XSS filtering in IE8 – For Security Testers: http://a4apphack.com/security/disabling-default-xss-filtering-in-ie8-for-security-testers
Нажмите здесь для печати.