Snuck - это инструмент с открытым исходным кодом, написанный на Java, цель которого - значительно протестировать данный фильтр XSS, специализируя инъекции на основе контекста отражения.
Подход, который он использует, основан на проверке контекста отражения внедрения и полагается на набор специализированных и запутанных векторов атаки для обхода фильтров. Кроме того, XSS-тестирование выполняется в браузере, реальный веб-браузер воспроизводит поведение злоумышленника и, возможно, жертвы.
Snuck сильно отличается от типичных сканеров веб-безопасности, он в основном пытается сломать данный фильтр XSS, специализируя инъекции, чтобы увеличить вероятность успеха. Векторы атаки выбираются на основе контекста отражения, то есть точной точки, в которую внедрение попадает в DOM веб-страницы отражения. Доступ к DOM страниц возможен через Selenium Web Driver, который представляет собой платформу автоматизации, которая позволяет реплицировать операции в веб-браузерах.
Поскольку до «активации» фильтра XSS может потребоваться много шагов, необходимо заполнить файл конфигурации XML, чтобы Snuck знал о шагах, которые он должен выполнить в отношении тестируемого веб-приложения. Практически подход аналогичен подходу iSTAR, но фокусируется на одном конкретном фильтре XSS.
КАК ЭТО УСТРОЕНО
Сценарий I: сохраненный XSS
Предположим, у вас есть веб-сайт электронной коммерции, который позволяет продавцам изменять описание своих товаров. Описания элементов являются общедоступными, что приводит к сохранению XSS в случае ошибок фильтра XSS. Для тестирования фильтра XSS необходимо выполнить три шага перед переходом на страницу отражения. Поскольку внедрение отражается в элементе P HTML, инструмент изменит фильтр и сообщит о разрешенных тегах и атрибутах в окончательном отчете. Очевидно, что обнаруженные XSS также сообщаются. См. Следующее изображение, чтобы лучше понять контекст.
В вышеупомянутом случае Snuck нужно было знать, какие операции требуются для подключения страницы инъекции, то есть веб-страницы, на которой предоставляется вредоносная полезная нагрузка, к отражающей странице, то есть веб-странице, на которой отражается полезная нагрузка. . Эту задачу можно выполнить, передав файл конфигурации XML.
Кроме того, поскольку очевидно, что для управления нашими элементами требуется операция входа в систему, необходим другой файл конфигурации XML.
По сути, инструмент сначала перепроектирует фильтр HTML, используемый в соответствии с описанием, предоставленным пользователем, затем он начнет вводить несколько векторов атаки и проверять, запускается ли XSS - важным моментом здесь является то, что диалоговые окна предупреждений захватываются, чтобы решить успешна ли инъекция; это означает, что частота ложных срабатываний равна 0, поскольку об уязвимости сообщается только в том случае, если диалоговое окно с предупреждением захватывается используемым веб-браузером.
Сценарий II: сохраненный XSS
Допустим, у вас есть блог, в котором посетители могут оставлять комментарии. Как и в предыдущем случае, наша цель - обойти фильтр, который веб-приложение использует для пользовательского контента. Поскольку инструмент должен был заполнить какое-то поле и выполнить атаку, это фактически сопоставимо с нечетким подходом.
Сценарий III: отражение XSS
Здесь мы представляем базовый сценарий, в котором значение параметра HTTP GET отражается на веб-странице, в частности, в значении атрибута входного элемента, тип которого установлен скрытым. Как обычно, мы хотим проверить, может ли внедрение этого параметра привести к отраженной уязвимости XSS.
Если вы хотите остановить тестирование, просто нажмите Ctrl + C. Если вы это сделаете, инструмент будет печатать в стандартном формате успешные инъекции, которые он нашел до сих пор.
Просмотр скрытого контента доступен для зарегистрированных пользователей!
