Я использую библиотеку Microsoft AntiXss 3.1.У нас есть несколько международных сайтов, которые используют нелатинские шрифты.Мы используем оптимизированные для SEO URL-адреса, поэтому у нас есть не-ASCII-символы, которые заканчиваются в URL-адресе.
AntiXss.UrlEncode (как минимум в 3.1) рассматривает «международные символы» как безопасные, поэтому мы в итогес IRI вместо URI:
http://somesite.com/ja-JP/applications/search/セキュリティ-b200009
HttpUtility.UrlEncode генерирует правильную кодировку для URI (RFC3986):
http://somesite.com/ja-JP/applications/search/%e3%82%bb%e3%82%ad%e3%83%a5%e3%83%aa%e3%83%86%e3%82%a3-b200009
, но я бы лучше следовал нашему стандарту использованиябиблиотека AntiXss.
Я знаю, что AntiXss / WPL 4.0 был выпущен (и больше не кажется, что международные символы считаются безопасными по умолчанию), но он изменил имена API, поэтому мне придетсявнесите значительные изменения в наше приложение для обновления.
Итак, я был бы рад ответить на любой из следующих вопросов:
- Как заставить AntiXss создать UrlEncode, которыйсовместим со стандартом Uri.
- Некоторые заверения в том, что, если мы пойдем с выводом, совместимым с IRI, библиотеки AntiXss (что является предпочтительным), мы не будем настраиваться на проблемы совместимости со старымиТо есть прокси-серверы в Таиланде (или где-либо еще - мы можем протестировать нашу матрицу браузера, но не все промежуточное сетевое оборудование, которое может существовать между нами и нашими клиентами).
- HttpUtility.UrlEncode - это то, что мы должны использовать ине заметно менее безопасен, чем AntiXss.UrlEncode.
- Есть и другое лучшее решение, которое я не рассматривал.
Спасибо