На моем веб-сайте появляются большие пакеты сообщений о неработающей ссылке. Я предполагаю, что меня исследуют на предмет конкретной уязвимости.
Я хочу знать, что ищет преступник, как они надеются, что это сработает, исходит ли это напрямую или от невольной жертвы ... и тому подобное. Вы могли бы рассказать мне что угодно об этом.
Одна проблема заключается в том, что на сайте есть место, где пользователи могут вводить свой собственный HTML-код, который затем предоставляется нашим веб-сервером; может это быть связано с этим?
Таких вариаций около двух десятков:
Referrer: http://210.11.22.33/<script>cross_site_scripting.nasl</script>.jspa
Requested URL: /<script>cross_site_scripting.nasl</script>.jspa
Referrer: http://210.11.22.33/<IMG%20SRC="javascript:alert(cross_site_scripting.nasl);">.jspa
Requested URL: /<IMG SRC="javascript:alert(cross_site_scripting.nasl);">.jspa
Referrer: http://210.11.22.33/<meta%20http-equiv=Set-Cookie%20content=%22testbvny=9424%22>
Requested URL: /<meta http-equiv=Set-Cookie content="testbvny=9424">
Referrer: http://210.11.22.33/<IMG%20SRC="javascript:alert(cross_site_scripting.nasl);">.idc
Requested URL: /<IMG SRC="javascript:alert(cross_site_scripting.nasl);">.idc
Одна проблема заключается в том, что на сайте есть место, где пользователи могут вводить свой собственный HTML-код, который затем предоставляется нашим веб-сервером; может это быть связано с этим?
На основании запрошенного URI это не связано с этим.
Похоже, что злоумышленник исследует ваш документ 404, чтобы узнать, может ли он выполнить XSS-атаку - если вы видели это действие в своем URI «вернуть HTML посетителю», вы хотели бы начать с него, но в этом случае оно не отображается как будто действительный URI является целью.
Убедитесь, что ваша страница 404 экранирует любой предоставленный URI и не пропускает неэкранированный HTML, затем взгляните на защиту вашей функции HTML, если вы этого еще не сделали (например, требуя, чтобы одноразовый токен публиковался всякий раз, когда функция используется).