Межсайтовый скриптинг в asp.net и как его предотвратить
Недавно я использовал сканер уязвимостей для одного из моих веб-сайтов на основе веб-форм asp.net, который использует фреймворк 4.5.
Веб-сайт был отмечен несколькими уязвимостями, большая часть которых связана с межсайтовым скриптингом XSS. один такой пример ниже
Пример 1:
Группа оповещения: Межсайтовый скриптинг
Подробности: URI был установлен на 'onmouseover='8HLr(9179)'bad='.
отражается внутри параметра тега в одинарных кавычках.
- ПОЛУЧИТЬ //? 'Onmouseover =' 8HLr (9179) 'bad =' HTTP / 1.1
- Referer: https://example.com/ Соединение: keep-alive
- Принять: /
- Accept-Encoding: gzip, deflate Host: example.com
- Пользовательский агент: Mozilla / 5.0 (Windows NT 6.1; WOW64) AppleWebKit / 537.21 (KHTML, например, Gecko) Chrome / 41.0.2228.0 Safari / 537.21
Пример 2:
Группа оповещения: Межсайтовый скриптинг
Подробности: ввод POST с кодировкой URL ctl00 $ txtSearch был установлен на'onmouseover = 8qGf (9096) ' Ввод отражается внутри параметра тега в одинарных кавычках.
- GET / search / the'onmouseover = 8qGf (9096) 'HTTP / 1.1
- Referer: https://example.com/ Соединение: keep-alive
- Принять: /
- Accept-Encoding: gzip, deflate Host: domain.com
- Пользовательский агент: Mozilla / 5.0 (Windows NT 6.1; WOW64) AppleWebKit / 537.21 (KHTML, например, Gecko) Chrome / 41.0.2228.0 Safari / 537.21
Пример 3:
Группа оповещения: Межсайтовый скриптинг
Подробности: URI был установлен на 'onmouseover =' gPIH (9411) 'bad ='
Ввод отражается внутри параметра тега в одинарных кавычках.
- / blog / 1234 / title-of-the-blog? 'onmouseover =' gPIH (9411) 'bad =' HTTP / 1.1
- Referer: https://example.com/ Соединение: keep-alive
- Авторизация: Базовая YW5vbnltb3VzOmFub255bW91cw ==
- Принять: /
- Accept-Encoding: gzip, deflate Host: domain.com
- Пользовательский агент: Mozilla / 5.0 (Windows NT 6.1; WOW64) AppleWebKit / 537.21 (KHTML, например, Gecko) Chrome / 41.0.2228.0 Safari / 537.21
Белое тестирование на локальном хосте, я ввел XXS в свой локальный URL-адрес http://localhost:54923/%3Cscript%3Ealert('hello!');%3C/script%3E
и это вызвало ошибку на странице
A potentially dangerous Request.Path value was detected from the client (<).
Означает ли это, что моя страница не уязвима для XSS, и после дальнейшего исследования XSS в веб-форме asp.net я нашел несколько статей, в которых говорится о сенитизации вводимых данных.
один пример, который показывает, что xss можно легко сделать, установив следующее в файле web.config
<httpRuntime requestValidationMode = "2.0" />
<httpRuntime requestValidationMode = "4.5" />
Источник /: https://code.tutsplus.com/tutorials/preventing-xss-in-aspnet--cms-21801
Достаточно ли настройки requestValidationMode для предотвращения XSS-атак, как упоминалось выше, или нам нужно сделать больше.
@ user2864740, не могли бы вы объяснить немного подробнее
просто используйте escape
@Learning - «Контекстное кодирование вывода / экранирование [является] первичный защитный механизм для остановки атак XSS ...» Это также подразумевает, что нет разрешает вводимые пользователем данные в контекстах / способах безопасного использования не могу. Свойства LiteralControl, Response.Write и Control вызывают общее беспокойство.
Что делать, если просто дезинфицировать вход с помощью следующего кода string filterInput = search.ToLower(); if (filterInput.Contains("onmouseover") || filterInput.Contains("script") || filterInput.Contains("</style>") || filterInput.Contains("</script>")) { search = System.Web.HttpUtility.HtmlEncode(filterInput); }
tldr; Это по-прежнему не будет "дезинфицировать" все безопасно. Используйте безопасно закодированные выходные данные (и ограничивайте ввод данных пользователем, если их нельзя безопасно использовать), и тогда никакой «очистки» не потребуется. Если пользователь передает <script>alert("fail")</script>, но он записан в HTML как <div id=mycontrol><script>alert("fail")<script></div> (с использованием безопасного экранирования или контекста, который гарантирует правильное экранирование), тогда «что угодно».
Посредством последовательного использования экранирования повсюду и соответствующим образом атаки второго порядка также смягчаются. Тривиальный встречный пример того, как "дезинфекция" выше не удается: onmouseout=stillnotsecure или <script src=youlose>. Не пытайтесь провести дезинфекцию в целях безопасности - и особенно без помощи соответствующей библиотеки! - провести дезинфекцию и проверить допустимые значения по причинам бизнес.
Возвращаясь к вышесказанному: важно именно использование HtmlEncode (или, лучше, использование элементов управления, принимающих / записывающих необработанный текст), а не «дезинфекция». Однако HtmlEncode не будет помогает, если применяется к содержимому JavaScript или атрибутам события. Это потому, что это не кодирование для правильного контекста, то есть: это неправильно: fromUser = "alert('stilloops')"; ..; control.OnClientClick = HtmlEncode(fromUser). Посмотрите на получившийся HTML-код, чтобы понять, почему.
tldr; при необходимости используйте правильная кодировка.