XSS attacks for anchor tag

[Rithanya Laxmi]

Hi ,

I want to a prevent XSS attacks for the below anchor link which is having the parameter value which accepts special characters.

<p><a id="customerDataPage" class="btn-link" href="/xxx/customer/customerData.jsp?isSOCKCustomer=${customerRequest}">XXXX</a></p>

This above URL can be used to inject special characters like below, which is vulnerable to XSS attack.

https://www.xxx.com/xxx/customer/customerData.jsp?isSOCKCustomer=%22whscheck=%22whscheck%22onmouseover=%22alert()%22&userId=259898594698285&login=success&_requestid=5625

How we can ensure we can pass <c:out value= "${customerRequest}"> in a href tag or ${fn:escapeXml(customerRequest)} in Anchor tag to prevent the XSS attacks.

If there is any other alternative please do let me know as well.

Thanks

[Bear Bibeault]

Why do you feel that you need an alternative to the solutions you already know about?

[Rithanya Laxmi]

Hi Bear,

Passing <c:out value= "${customerRequest}"> in a href tag is not working and it is not passing the excepted value through the query string. Hence the reason i am asking is there any other way to do it?

[Tim Moores]

I think the better approach is to debug why it doesn't work. So: How isn't it working? Show us the JSP, the HTML it generates, and describe what exactly is happening when it runs.

[Bear Bibeault]

Tim Moores wrote:I think the better approach is to debug why it doesn't work.

Quoted for truth. When the conventional approach isn't working, you find out why it's not working, not look for a different approach.

[Junilu Lacar]

Tim Moores wrote:I think the better approach is to debug why it doesn't work. So: How isn't it working? Show us the JSP, the HTML it generates, and describe what exactly is happening when it runs.

Make sure whatever you post here or in any public forum adheres to your company's security and confidentiality policies. Make sure you don't divulge anything that can later be used against you. Anything that might violate a non-disclosure agreement you signed, for example, should not be posted here or anywhere accessible to unauthorized people.

[Junilu Lacar]

For example, this

Rithanya Laxmi wrote:<p><a id="customerDataPage" class="btn-link" href="/xxx/customer/customerData.jsp?isSOCKCustomer=${customerRequest}">XXXX</a></p>

With this post, you have given a malicious attacker something to work with to probe your defenses. An attacker will already know that your implementation uses the name "customerRequest" and can probe that URL to see if they can craft some kind of injection attack using that particular field name. You've already given away another piece of information in your other post as well: that you're using a field named userId.

[Stephan van Hulst]

Egh, that's security by obscurity. I agree it's naive to treat that information so carelessly, but it's inconsequential if you use proper security standards.

[Junilu Lacar]

Not really obscurity. I think of it as more about confidentiality. Loose lips sink ships. And you said it, being careless about that kind of information is inconsequential but only if you use proper security standards. Otherwise, it gives an attacker an attack vector that has a higher probability of success. More often that not, security standards are not typically adhered to by development teams. We wouldn't have this thread to talk about it if they did.

[Tim Moores]

Junilu Lacar wrote: An attacker will already know that your implementation uses the name "customerRequest

That is actually a variable name and will be replaced by a value.

[Junilu Lacar]

Sure. It's still another piece of information that I, as an attacker, can use when I'm probing around for a vulnerability. Variable names like that often reflect the actual field names and it could very well be the name of the database field, too. This could be used to try a SQL injection attack. My point is not whether or not the information is actually useful in mounting a successful attack, it's that developers need to be careful about what kind of information they share about their work in public forums like this. OP is obviously conscious about this a little since he or she chose to sanitize the URL for public consumption a little bit with the "xxx/" in the front. I'm just trying to remind him/her to apply the same due diligence with other bits of information. You never know who's watching. It may sound paranoid but it's only that until it's not.

[Tim Moores]

Junilu Lacar wrote:It's still another piece of information that I, as an attacker, can use when I'm probing around for a vulnerability.

I'm in agreement with your point about minimizing the attack surface. But I think you missed my point that "customerRequest" (which you said could be exploited) is a JSP variable which is NOT visible to the client. What IS visible is the name "isSOCKCustomer" (which does give away more than necessary). Maybe that was just a typo on your part.

Generally, valuable and sensitive valuable data items should not be round-tripped to the client, they should be kept in the server session, if possible, or encrypted if not. Less valuable data might as well have their proper names, as nothing bad should be able to be made happen when they're altered.

[Junilu Lacar]

Not a typo on my part. I'm not talking about what's in the JSP or in the response that is rendered. I'm talking about what an attacker does to reconnoiter possible attack vectors. I'm talking about social engineering and watching what kind of sensitive information engineers might carelessly if unintentionally divulge in their social media or community forum accounts. The name "userId" may not appear in the rendered page coming from the application but it sure as heck renders clearly here in the post on CodeRanch, doesn't it?

Like I said, it might be stretch and maybe just a bit paranoid but if you're going to be security conscious, don't be giving away information like that.

[Junilu Lacar]

Tim Moores wrote:I think the better approach is to debug why it doesn't work. So: How isn't it working? Show us the JSP, the HTML it generates, and describe what exactly is happening when it runs.

Now, imagine that request came not from an honest moderator at CodeRanch who just wants to help but a malicious attacker who knows where OP works and maybe has access to the application in question. By posting real details about the code he/she is working on, OP might not only be violating an NDA, he/she could also be giving that online stalker/attacker useful clues that will help them find and exploit vulnerabilities that the app currently has. Most serious security breaches are done from the inside so one can never be too careful, especially in social media.

I've seen other posters post too much real code here before. Mine was just fair warning to OP to carefully consider how he/she would reply to your request.

BTW, Jeanne does a really good job at being tight-lipped about what she posts around here that's work related. She puts a lot of deliberate effort into making sure she's not divulging anything that shouldn't be known to unauthorized people, especially when it comes to actual code.

[Tim Moores]

Got it, you're talking about leaking source code; I hadn't picked that up from your post.

[Rithanya Laxmi]

Hi Team

How i can do the sanitizing the input data in JSP , already i am using the <c:out> as mentioned in the below link to prevent XSS attacks. I want to handle this from client side/JSP. I was going through the below URL , there it is mentioned to use the <c:out> for sanitization.

https://hdivsecurity.com/owasp-xss

Why <c:out> is not working here as mentioned in the above link, not getting how we can sanitise the input data (userId) here to prevent XSS attacks?

Other option is using =${fn:escapeXml(userId)}

<a id="customerData" class="btn-link" href="/xxx/test/customerData.jsp?userId==${fn:escapeXml(userId)}/>">Customer Data</a>

any other option we have to ensure the input is encoded and not susceptible to XSS attacks fro JSP. Please provide your expert opinion and let me know where i am going wrong.

[Bear Bibeault]

Rithanya Laxmi wrote:I want to handle this from client side/JSP.

JSP is not client-side. JSP is a server-side technology. Please read this article to understand how JSP works.

<c:out> should work fine.

[Paul Clapham]

Rithanya Laxmi wrote:I want to handle this from client side/JSP. I was going through the below URL , there it is mentioned to use the <c:out> for sanitization.

https://hdivsecurity.com/owasp-xss

Also from that page you linked to:

Cross-site Scripting (XSS) wrote:It is important to note that both preventions are necessary, HTML Escape and Input Validation.

[Dave Tolls]

cout has an escapeXml attribute that (I believe) would need to be set to true to actually escape the HTML.

However, as I said in the other thread (and Paul has reiterated here), you should be able to sanitize this data beforehand.
I can't believe that string of HTML characters is a valid userId, so it should never have got anywhere near this JSP page.

[Bear Bibeault]

Dave Tolls wrote:cout has an escapeXml attribute that (I believe) would need to be set to true to actually escape the HTML.

It is set to true by default.