Блог

В электронном письме страницы мы имеем следующее содержимое.

 please <a href="emaildisclaimer-Test.html?name=testamp;email=test@test.com" target="_blank">click here</a> regarding this event.  
 

Когда пользователь нажимает на кнопку «Нажмите здесь», страница будет перенаправлена на
страницу html. где параметр URL будет извлечен и
отображен. Здесь я сталкиваюсь с проблемами атаки XSS. Может ли кто-нибудь
иметь представление об этой проблеме. Как мы можем предотвратить это с помощью JavaScript?

Из вашего комментария:

Как только он перенаправлен, он будет проанализирован и отображен в HTML. Параметры передачи URL редактируются и добавляются тегами скрипта ( <IMG SRC="javascript:alert('XSS');"> ). Как мы можем предотвратить добавление параметра извне??

Пока содержимое, предоставляемое пользователем, отображается только тому же пользователю, проблемы с XSS нет. Они могут взломать себя, но никто другой.

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

Я вижу два возможных использования контента от пользователя:

• Не позволяя им использовать какой-либо HTML
• Позволяя им предоставлять (некоторые) HTML

Не позволяя им использовать какой-либо HTML

Если вы хотите, чтобы конечный пользователь предоставлял информацию, которая не может быть HTML, просто убедитесь, что все символы < и amp; заменены сущностями:

 // From user
str = "<img src='javascript:malicious();'>";

// Disable
str = str.replace(/amp;/g, "amp;amp;").replace(/</g, "amp;<");
 

Теперь, если вы включите это содержимое на страницу, оно будет выглядеть следующим образом (исходный код HTML, не отображается):

бла-бла-бла, пользователь говорит: <img src=’javascript:вредоносный();’>

… который при отображении

бла-бла-бла, пользователь говорит:

… например, тег не является тегом, это просто текст на странице.

Позволяя им предоставлять (некоторые) HTML

Если вы хотите, чтобы пользователь мог предоставлять HTML-код, который будет добавлен на страницы, вы должны использовать полный анализатор HTML (на стороне сервера) с белым списком тегов, атрибутов и значений атрибутов, удаляя все, чего нет в белом списке. Предположительно, ваш белый список не будет включать script элементы или JavaScript в какой-либо атрибут.

Есть из чего выбирать. Одним из наиболее известных является JSoup (библиотека Java), которая имеет порт .Net (JSoup.Net ); У Microsoft есть своя библиотека против Samy. И так далее. Но для этого требуется полноценный, правильный синтаксический анализ HTML, и вам понадобится хорошо документированная, хорошо поддерживаемая библиотека, чтобы справиться с этим за вас, и вам нужно будет сделать это на стороне сервера.

Оригинальный ответ:

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

emaildisclaimer-Test.html?name=testamp;email=test@test.com

Я сразу думаю: эй, интересно, что произойдет, если я попробую использовать информацию других людей? И введите другие имена и адреса электронной почты. (Хорошо, на самом деле я этого не делаю, но если бы я придерживался такого мышления …)

Вместо этого усложните угадывание того, как выглядит достоверная информация:

emaildisclaimer-Test.html?r =NzZiNjFlZDAtZmRlMi0xMWUzLWEzYWMtMDgwMDIwMGM5YTY2

Теперь у меня очень мало информации для работы. emaildisclaimer-Test.html потребуется доступ к пониманию того, что r такое параметр запроса.

Этот конкретный пример представляет собой UUID в кодировке Base64; откодируйте его и найдите в хранилище на стороне сервера (например).

С другой стороны, вы можете зашифровать информацию с помощью открытого ключа (и Base64-закодировать результат) и emaildisclaimer-Test.html расшифровать ее (на стороне сервера) с помощью закрытого ключа, чтобы вам не нужно было иметь их базу данных. Это зависит от того, насколько безопасно вам это нужно.

Обратите внимание, что я пару раз говорил «на стороне сервера». Ваше расширение, .html , предполагает, что содержимое является статическим и emaildisclaimer-Test.html использует строку запроса на стороне клиента. Но вам потребуется обработка на стороне сервера, если вы хотите повысить безопасность.

Как мы можем предотвратить это с помощью JavaScript?

Я полагаю, вы имеете в виду JavaScript на стороне клиента. Если вы действительно хотите сделать это чисто на стороне клиента, это никогда не будет безопасно. Все, что вы можете сделать, это усложнить понимание, слегка подняв планку (на самом деле совсем немного) для любого, кто пытается играть в вашу систему. (Запутанный код, декодирующий запутанную строку запроса). Вам понадобится обработка на стороне сервера, чтобы сделать что-нибудь стоящее для его защиты.

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