Что такое хороший способ предотвратить атаки сайтов на xss

Question

Я использую веб-формы C # с asp.net 4.0. Этот веб-сайт должен быть защищен и сейчас проходит проверку безопасности. Мне просто интересно, что нужно сделать, чтобы лучше предотвратить атаки XSS на мой сайт.

Я знаю, что для вывода сайта доступна кодировка. Я также посмотрел в antixsslibrary.dll от Microsoft, но это кажется мне устаревшим. Есть ли в asp.net какие-либо встроенные средства предотвращения xss-атак? Я склонен думать, что это происходит, так как я пытаюсь создать xss-атаку на свой собственный веб-сайт и получаю сообщение об ошибке:

Ошибка сервера в приложении '/GNB.DPS.MVAD.Presentation.Web'.

Потенциально опасное значение Request.Form было обнаружено из клиент (ctl00 $ cphListBody $ tbXSS = "alert ('XSS V ..."). Описание: проверка запроса обнаружила потенциально опасный входное значение клиента, и обработка запроса была прервана. Это значение может указывать на попытку поставить под угрозу безопасность вашего приложения, такие как атака межсайтовых скриптов. Разрешить страницам переопределить параметры проверки запроса приложения, установить Атрибут requestValidationMode в конфигурации httpRuntime раздел to requestValidationMode = "2.0". Пример: . После установки этого значения вы можете отключить проверку запроса, установив validateRequest = "false" в Страница директивы или в разделе конфигурации. Тем не менее, это Настоятельно рекомендуется, чтобы ваше приложение явно проверило все входные данные в этом случае. Для получения дополнительной информации см. http://go.microsoft.com/fwlink/?LinkId=153133.

Сведения об исключении: System.Web.HttpRequestValidationException: A потенциально опасное значение Request.Form было обнаружено от клиента (ctl00 $ cphListBody $ tbXSS = "alert ('XSS V ...").

Answer 1

ASP.NET предоставляет инструменты, которые позволяют защищаться от XSS-атак, но не автоматически.Вам нужно знать, что такое атаки и как использовать инструменты для защиты от них.

Появившаяся ошибка - это настройка по умолчанию, которая пытается блокировать неверный ввод данных пользователем при входе в веб-приложение.,Это хороший шаг, но не позволяйте, если у вас будет ложное чувство безопасности .Существуют и другие способы неправильного ввода данных в ваши данные, что делает ваш сайт уязвимым.

Например, скажем, ваш сайт управляется пользовательскими данными.Написанные вами экраны ввода данных могут блокировать «потенциально опасный контент», но ничто не мешает кому-то использовать другой интерфейс для ввода данных - свой собственный интерфейс, SQL Server Management Studio и т. Д. Если они получат там плохие сценарии, ваш сайт будетс радостью представляем эти опасные сценарии пользователям.

Единственный способ защиты от XSS - это очистка данных, когда они выводятся в браузер, а НЕ когда они поступают.

НаиболееОсновной метод заключается в использовании встроенной функции Server.HtmlEncode () для очистки всех строк, поступающих из ненадежных источников.(Под ненадежным понимается что-либо, кроме строк, которые вы сами жестко запрограммировали. Базы данных, файлы и веб-службы НЕ являются доверенными источниками.)

Существуют ограничения на то, что может делать Server.HtmnlEncode.Мне лично нравится использовать библиотеку Microsoft Anti-Xss , так как она лучше работает (фильтрация белого и черного списков) и предлагает больше функций (например, GetSafehtmlFragment ()).

Естьтонны ресурсов в Интернете для этого.Я бы начал здесь:

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

, а затем специально для .NET:

http://msdn.microsoft.com/en-us/library/aa973813.aspx

Изменить - добавлено

Основной проблемой здесь, по-видимому, является недопонимание различий между входной фильтрацией и выходной фильтрацией.Эта статья хорошо объясняет разницу и использует лучше, чем я мог бы здесь:

http://jeremiahgrossman.blogspot.com/2007/01/input-validation-or-output-filtering.html

Окончательное редактирование, а затем я остановлюсь.

Даже Microsoft признает, что я говорю выше.См. Эту статью: http://msdn.microsoft.com/en-us/library/ms998274.aspx

из статьи:

Не полагайтесь на санацию ввода

Обычной практикой является попытка кода санировать ввод с помощьюфильтрация известных небезопасных символов.Не полагайтесь на этот подход, потому что злоумышленники обычно могут найти альтернативные способы обхода вашей проверки.Вместо этого ваш код должен проверять известные безопасные и безопасные данные.В таблице 1 показаны различные безопасные способы представления некоторых общих символов.

Проверка ввода является одним из инструментов в вашем арсенале защиты, но одного этого недостаточно.

Answer 2

Вы можете взглянуть на Microsoft Web Protection Library на CodePlex.Вы также можете взглянуть на страницу XSS на OWASP , а также на шпаргалку .

Answer 3

В дополнение к предыдущим ответам: Полученное сообщение было создано с помощью функции RequestValidation в ASP.NET. Он пытается фильтровать вредоносный контент, например, в QueryString.

Хотя это хорошее начало, оно недостаточно защищено, чтобы вы больше не беспокоились о скриптовых атаках.

Также обратите внимание, что RequestValidation по умолчанию отключено в ASP.NET 4.0: http://geekswithblogs.net/bbastiaensen/archive/2010/12/13/request-validation-in-asp.net-4.0.aspx

Answer 4

Лично мне не нравится функция RequestValidation. По сути, угадывает , может ли строка текста, введенная пользователем, быть вредной. Вы не можете рассчитывать на то, что он поймает каждую возможную строку атаки. Это также может привести к ошибкам, когда пользователь вводит допустимые значения в вашей форме.

Вот проблема. Предположим, что на вашем веб-сайте отображаются строки текста, введенные посетителями.

Я, как злонамеренный пользователь, ввожу <script>window.location='http://www.grossout.com'></script>.

Если этот текст выводится непосредственно в браузер при следующем посещении вашего веб-сайта, он будет перенаправлен на сайт www.grossout.com.

С другой стороны, дружественный посетитель может набрать This is a cool web site <:-).

В следующий раз, когда кто-то посетит ваш веб-сайт, он получит неверный HTML из-за символа <.

В этом примере лучшим решением, вероятно, является использование метода Server.HtmlEncode(), который будет экранировать символ <, чтобы он отображался правильно, не прерывая вашу страницу.

Если вы используете JavaScript, вы можете использовать метод jQuery .text для экранирования символа <.

Я считаю, что оба решения превосходят использование RequestValidation, потому что они позволяют отображать любой текст, не вызывая у пользователя сообщения об ошибке.