Кодирование гиперссылок - когда и как?

Question

У меня есть вопрос, связанный с безопасностью. Мое веб-приложение позволяет пользователям вводить URL-адреса. URL-адрес сразу же сохраняется в базе данных (на этом этапе не выполняется обработка. Это неправильно?). Я использую Linq для SQL, поэтому он уже параметризован. При отображении гиперссылки на пользователя я использую повторитель. Нужно ли кодировать текст гиперссылки, а также всплывающую подсказку и свойство href? Или мне нужно только кодировать текст (который отображается). Кроме того, я предполагаю, что здесь мне нужно URL-кодирование, но нужно ли мне также использовать HTML-кодирование?

Я попытался Server.UrlEncode на всех трех свойствах, где текст был <script> alert("hello") </script>, и он, казалось, испортил href и текст. Я предполагаю, что это означает, что это не полностью защищено?

Редактировать - я должен добавить, если я кодирую на выходе, как я могу сделать так, чтобы вместо "% 2" отображалось "/"? Спасибо

Answer 1

Вы разрешаете произвольные ссылки / текст http (s)?

Текст (innerHtml тега привязки) должен быть закодирован htmlentity. Насколько href:

Сначала при вводе, при минимальной проверке, что URL-адрес ввода действительно является ссылкой http или https с допустимыми символами в имени хоста и пути (используйте RFC, но не стесняйтесь ограничивать; обратите внимание, что punycode используется для доменных имен не ascii) так что белый список символов короткий). Это предотвратит использование javascript: urls, username: password @ hostname url для фишинга, ftp: //, kindle: // и других схем, использование \ in url (преобразуется в / из IE, но может сбить вас с толку при чтении домена) , использование чрезмерного пробела www.good% 20 {N times} URL-адресов evil.com и т. д.

Если вы разрешите params, urlencode отдельных имен и значений, хотя они влияют на цель (также не кодируйте html-сущности). Снимите # и все, что после, так как это все равно не отправляется на цель. Заключите href в двойные кавычки.

Может быть хорошей идеей будет предупреждать пользователей, когда они уходят с вашего сайта, если это применимо. Обратите внимание, что целевой сайт получит URL страницы в качестве реферера. Другой вариант - разрешить только ссылки на домены, занесенные в белый список, которые, как вы знаете, не являются вредоносными (если вы не будете вести себя ответственно, это предотвратит определение вашего сайта как ссылки на вредоносные сайты со стороны netcraft, google и т. Д.).

Answer 2

Вы должны санировать на входе (это отличается от побега) сразу. Это означает выполнение некоторой проверки, что данные являются URL-адресом или, по крайней мере, содержат только символы, разрешенные для URL-адреса. Для этого используйте Regex или библиотеку парсинга URL (извините, я не слишком знаком с API .NET).

Вы должны кодировать при выводе, если только вы не хотите использовать его в качестве URL-адреса в элементе HTML (что вы делаете!), В этом случае вам не следует делать какую-либо кодировку. Вам определенно нужно будет закодировать всплывающую подсказку и текст в теле тега ссылки. Я бы очень серьезно подумал о том, как вы дезинфицируете ввод, прежде чем он будет введен в базу данных. Я предлагаю просмотреть этот фантастический ресурс примеров атак XSS .

Причина, по которой вы кодируете при выводе, а не при сохранении в базе данных, заключается в том, что каждый выходной носитель может иметь разные правила кодирования / экранирования. например HTML отличается от JavaScript, который отличается от, скажем, PDF, или Flash, или CSS, и т. Д ...

Также я предполагаю, что вы используете подготовленные операторы при сохранении в базу данных, чтобы избежать SQL-инъекций?

Answer 3

Это неправильно? ДА Санировать при вводе, а не при выводе.

Если вы выполняете дезинфекцию перед сохранением в дБ, нет необходимости кодировать при выводе. Основное правило: доверяйте своим данным на всех уровнях или в своем приложении, поэтому проводите санитарную обработку на ранней стадии.