Issue regarding the XSS (Cross Site Scripting) attack

Question

In the email of the page we have following contents.

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

When user clicks on the "Click here" the page will be redirected to the html page. where the URL parameter will be retrieved and displayed. Here I'm facing the problems of XSS attack. Can anybody have idea regarding this issue. How we can prevent this from the JavaScript?

Answer 1

From your comment:

Once it is redirected, it will be parsed and displayed in HTML. URL passing parameter are edited and appended with script tags ( <IMG SRC="javascript:alert('XSS');"> ). How we can prevent appending parameter externally ??

As long as the content the user supplies is only ever shown to that same user , there's no XSS issue. They can hack themselves, but no one else.

If you're accepting end-user content for display to other users, then of course you need to be paranoid about XSS.

I'm seeing two possible uses of the content from the user:

• Not allowing them to use any HTML

• Allowing them to provide (some) HTML

Not allowing them to use any HTML

If you want the end user to supply information that is not allowed to be HTML, simply make sure all of the < and & characters are replaced with entities:

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

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

Now if you include that content on the page, it looks like this (HTML source, not rendered):

blah blah blah, user says: <img src='javascript:malicious();'>

...which when rendered is

blah blah blah, user says:

...eg, the tag is not a tag, it's just text on the page.

Allowing them to provide (some) HTML

If you want the user to be able to supply HTML that will be added to pages, you have to use a full HTML parser (server-side) with a whitelist of tags, attributes, and attribute values, stripping out anything that isn't on the whitelist. Presumably your whitelist would not include script elements or JavaScript in any attribute.

There are many to choose from. One of the best known is JSoup (a Java library) which has a .Net port (JSoup.Net); Microsoft has their Anti-Samy library. And so on. But this requires full-on, proper HTML parsing, and you'll want a well-documented, well-supported library to handle that for you, and you'll need to do it server-side.

---

Original answer :

I'm not seeing an XSS there, but I am seeing a potential security issue. By making information available in plaintext in the URL, you make it open to tampering. If I get one of those and see

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

I immediately think: Hey, I wonder what happens if I try other people's information? And fill in other names and email addresses. (Okay, I don't really, but if I were of that mindset...)

Instead, make it harder to guess what valid information looks like:

emaildisclaimer-Test.html?r=NzZiNjFlZDAtZmRlMi0xMWUzLWEzYWMtMDgwMDIwMGM5YTY2

Now I have very little information to work with. emaildisclaimer-Test.html would need access to understanding what that r query param is.

That particular example is a Base64-encoded UUID; un-encode it and look it up in server-side storage (for instance).

Alternately, you could encrypt the information with a public key (and Base64-encode the result), and emaildisclaimer-Test.html could decrypt it (server-side) with the private key so that you don't have to have a DB of them. It depends how secure you need it to be.

Note I've said "server side" a couple of times there. Your extension, .html , suggests that the content is static and that emaildisclaimer-Test.html uses the query string client-side. But you'll need server-side processing if you want to improve the security.

How we can prevent this from the JavaScript?

I assume you mean client-side JavaScript. If you really want to do this purely client-side, it will never be secure. All you can do is make it harder to figure out, raising the bar slightly (really only slightly) on anyone trying to game your system. (Obfuscated code decoding an obfuscated query string). You'll need server-side processing to do anything worthwhile to protect it.

Answer 2

由于您不处理任何用户提交的内容，因此我看不到您怎么可能遭受XSS攻击。