Межсайтовый скриптинг в asp.net и как это предотвратить - PullRequest
Новая
       26

Межсайтовый скриптинг в asp.net и как это предотвратить

0 голосов
/ 28 августа 2018

Недавно я использовал сканер уязвимостей для одного из моих веб-сайтов, основанных на веб-формах asp.net, который использует Framework 4.5.

Веб-сайт был помечен для нескольких уязвимостей, и большинство из них связано с межсайтовым скриптингом XSS. один такой пример ниже

Пример 1:

Группа предупреждений: Межсайтовый скриптинг

Подробности : URI был установлен на 'onmouseover='8HLr(9179)'bad=' Ввод отражается внутри параметра тега между одинарными кавычками.

  • GET //? 'Onmouseover =' 8HLr (9179) 'bad =' HTTP / 1.1
  • Реферер: https://example.com/ Подключение: keep-alive
  • Принимаем: /
  • Accept-Encoding: gzip, deflate Хост: example.com
  • User-Agent: 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
  • Реферер: https://example.com/ Подключение: keep-alive
  • Примите: /
  • Accept-Encoding: gzip, deflate Хост: 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 Хост: 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

и это сгенерировало ошибку на странице

Потенциально опасное значение Request.Path было обнаружено из клиент (<). </p>

Означает ли это, что моя страница не уязвима для 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-атак, как упомянуто выше, или нам нужно сделать больше.

1 Ответ

0 голосов
/ 28 августа 2018

Не полагайтесь на проверку запросов для защиты XSS: - Проверка запроса желательна, но ее НЕ следует использовать в качестве единственного метода защиты XSS, и она не гарантирует отлов всех типов неверных входных данных. Я вижу, что вы защищаете страницу только для методов GET, но если ваша страница должна быть опубликована с использованием «форм» (с помощью методов POST), вы должны использовать атрибут ValidateAntiForgeryToken, чтобы фактически защитить ваши методы и формы от вызова из других приложений. атрибут украшен атрибутом [ValidateAntiForgeryToken], он гарантирует, что ваша форма содержит соответствующий код с действительным токеном. Вот пример кода 

@using (Html.BeginForm())
{
  @Html.AntiForgeryToken();
  @Html.EditorForModel();
  <input type="submit" value="Submit" />
}

[HttpPost]
[ValidateAntiForgeryToken()]
public ActionResult Index(User user)
{
  ...
}

Также используйте кодировку, где это уместно. Если вы используете механизм представления Razor, все выходные данные уже закодированы в формате HTML.

...