предотвращение xss в .net OWASP

Question

Я прочитал рекомендации OWASP относительно предотвращения XSS.Руководящие принципы, похоже, относятся только к наличию белого списка и выходных данных кодирования.Тем не менее, это оставляет открытой проблему с так называемыми свободными текстовыми полями, например, текстовым полем, в которое я пишу текст для этого сообщения.

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

Из рекомендаций OWASP у меня складывается впечатление, что xss нужно просто сохранить в базе данных и просто санировать его, когда он будет отображаться во внешнем интерфейсе.Мне, однако, немного неудобно с этим.Или я ошибаюсь, есть ли лучший способ?

Answer 1

XSS - это проблема с выходом.Вы не можете иметь одну функцию перехвата кодирования или проверки ввода, которая работает для всех xss.Даже преобразовав входную строку в их htmlentities, ваше приложение все равно может быть уязвимо к xss в событиях dom , а также к другим векторам.Трудно соблюдать все эти правила.Обязательно протестируйте свой код, есть бесплатные XSS-сканеры, такие как Sitewatch и Skipfish .

Хранение HTML в базе данных не является уязвимостью, но ее отображениебудет постоянным XSS.Что является худшей формой XSS.Обычно некодированную версию хранят в базе данных, поскольку это делает данные согласованными и более удобными для сравнения и сопоставления текста.В SQL-инъекции для MS-SQL вы можете составлять запросы, чтобы можно было ввести полезную нагрузку xss в базу данных.Например select...; insert into comments (post)values('<script>alert(xss)</script>'). Не доверяйте своей базе данных .

Answer 2

Я возглавляю Руководство OWASP, и мое мнение об этом изменилось с тех пор, как Руководство 2.0 было написано еще в 2004/2005 годах.

На мой взгляд, есть две фазы, с которыми вам нужно иметь дело:

Проверка ввода - вы всегда должны избегать вторжения векторов XSS в ваши данные, если вообщевозможный.У меня есть Views ™, но, честно говоря, лучшая ставка - строго печатать и ограничивать длину, насколько это возможно.Нет смысла разрешать сохранение логических или целочисленных переменных в виде текстового столбца.Остаточным риском будут текстовые области, хранящиеся в текстовых двоичных объектах, что должно быть очевидно при кодировании уровня представления, каким бы оно ни было.

Выходная кодировка - когда было написано оригинальное руководство (2002), мы делали «большую пятерку», что больше не соответствует действительности.Вам необходимо правильно выводить кодирование для контекста, поэтому, если вы выводите в Ajax, вам нужно сделать его безопасным как для JSON, так и для JavaScript, а также для HTML.

В работе находится новая версия Руководства, OWASP Guide 2013. Я буду следить за тем, чтобы оно было правильно обновлено.

Пожалуйста, зарегистрируйте проблему на трекере проблем нашего проекта, поскольку у вас есть очень серьезная проблема:

Зарегистрируйте проблему в трекере проблем OWASP Guide 2013

Дни простого кодирования для большой пятерки хорошо и действительно прошли.В частности, поскольку HTML вряд ли будет основным уровнем представления информации в будущем.

Эндрю ван дер Сток, Руководство OWASP 2.0 / 2013 Руководство.

Answer 3

У меня сложилось впечатление, что xss нужно просто сохранить в базе данных и просто санировать его, когда он будет отображаться во внешнем интерфейсе

Это правильно. Какую бы библиотеку / функцию анти-XSS-кодирования вы использовали для кодирования, вы не сможете работать с попыткой XSS, не допуская, чтобы хитрый код отображался как HTML при его добавлении в вывод страницы.

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

Answer 4

Итак, здесь нужно отметить две вещи.

Проверка ввода на входе выполняется, чтобы убедиться, что данные действительны в соответствии с доменом, и это останавливает некоторые атаки, но определенно не все.

Выходная кодировка выполняется, чтобы убедиться, что данные не каким-то образом анализируются как HTML или javascript. Итак, как описано в Rook, это проблема вывода. Вы должны увидеть Шпаргалку по профилактике OWASP XSS , в которой объясняется, как избежать XSS непосредственно на HTML-странице, и шпаргалку по профилактике XSS OWASP DOM , чтобы понять, как избежать XSS, вызванного чтение и запись javascript неанимированных или некодированных данных.

Как уже упоминал Rook, не поддавайтесь искушению кодировать или очищать данные при входе, если, конечно, они недопустимы для вашего домена. На самом деле нет способа правильно кодировать перед выводом, потому что тогда вы знаете, какой контекст вы кодируете. Является ли это атрибутом HTML, строкой javascript, строкой javascript в атрибуте HTML и т. Д.

И, как упоминалось в правиле № 6 в шпаргалке по предупреждению OWASP XSS, если вы хотите разрешить некоторым пользователям HTML механизм на основе белого списка, такой как OWASP AntiSamy или HTMLPurifier.