• Post Reply Bookmark Topic Watch Topic
  • New Topic

URL Encoding & Decoding

 
Balaji Krishnan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I need to encode the URL in order to prevent XSS security threat. I don't have to encode the complete URL, I just have to encode the values for query string. Can you someone help on how to encode only the values of query string parameters and change it in the URL itself using java. I am planning to do this in a filter. Please help.
 
Stefan Evans
Bartender
Posts: 1822
10
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well first things first, the helper class you will probably need is java.net.URLEncoder.

Now, the easiest time and place to encode URL Parameter is when you are building a URL.

I would not recommend using a Filter to accomplish this task, unless you know for certain that every single URL that is going to come past you is going to need encoding, and hasn't been already.
The problem with using a filter is that you have to search the entire html, find things that look like URLs, parse out the parameters and encode them.
But you can't tell if they have been encoded already, so you might be encoding them twice which would result in breaking your application also.

While a filter seems like a quick and easy solution, it will create more problems in the long run.

I would recommend you bite the bullet and investigate the areas where you are building URL strings.
 
Balaji Krishnan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stefan,

Yes, every single URL need to be encoded in the application. So I want to have this task to be implemented in a filter. As I don't want to encode parameter separator character '&' nor the parameter name-value separator character '='. Do you know if there is an way to accomplish this?

Thanks!
 
Paul Clapham
Sheriff
Posts: 21867
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to clarify -- you're not talking about the standard URL encoding required to make a URL parameter conform to the HTTP rule, namely that it can (roughly speaking) only contain letters and numbers? You're talking about some other encoding which is specific to your application, right?

And this filter you're proposing, it's supposed to be a servlet filter which will parse the HTML output by all servlets, identify all URLs in that HTML, and modify those URLs by applying some kind of encoding to the parameter values? (And maybe the parameter names, too?)

That sounds like a lot of work to me, but perhaps you're given an application and told to bolt on this encoding idea, and it's too much trouble to go through all the existing servlets and fix the places where URLs are written? In which case, sure, it could be possible.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65519
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that the filter approach is a poor one. Just fix the code.
 
Balaji Krishnan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All,

I had misunderstood the security requirements in order to fix this issue. I need to encode the response body which is sent in the output of any incoming http(s) request coming into the application server. By this approach if any java script is injected into the request URL, it will not be executed in the client (JSP or HTML) as the special characters will be encoded (HTML entity encoding technique).

The problem is the implementation of this encoding across all the JSPs and HTML the application has. Since it was a legacy application which has more than 1000 JSPs, doing this change is getting complex and impacting the whole application. Unfortunately I do not find a common place (java or JSP component) this encoding can be executed. If anyone has any suggestion or approach, please do let me know. Thanks.

OWASP site has the details of this technique,
1) https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
2) https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
 
Paul Clapham
Sheriff
Posts: 21867
36
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay... so you are considering writing a servlet filter which will process the output of everything in your system, or at least everything which is text/html.

And this filter is going to have to parse HTML, identify specific things (I'm not quite clear on what but then I only spent 30 seconds looking at the OWASP documents), and escape them. This sounds like a dubious project to me because first of all you have to write a parser for HTML. And that HTML might be not well-formed HTML. In particular it might not be well-formed because one of those XSS attacks makes it so. This could be difficult to test because you might not have a good idea of all the variety of XSS attacks which might happen.

If it were me, then at this point I would be going to management and saying something like "Look, you have a legacy system here. I can't guarantee that bolting on this XSS-escaping system will be reliable, nor can I give you an estimate of how long it will take to implement. Now is the time to look at rewriting the legacy system, since we're going to have to look at everything in it which produces HTML in any case." Only with better sales skills than what I have.
 
Balaji Krishnan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not thinking of making any changes in the filter, because I don't know how it can be implemented in a filter or any server side component. You're correct on moving away from the legacy system, but it is impossible right now because of complex custom business functions written on top of it. Though the management is aware as it need to be replaced sooner or later.

My headache right now is to implement the encoding in one of the JSP and make sure the XSS attack is prevented/resolved. And estimate the time effort for make this change in all JSPs.
 
Stefan Evans
Bartender
Posts: 1822
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Just how legacy IS this JSP?
Can you show us an example of a page which is vulnerable, with a few suggestions of how you would make it safer?

I can think of multiple ways that dynamic data gets injected into a JSP:

- <%= scriptlet expression tags %>
- ${EL expressions}
- <% out.println("Scriptlet code") %>
- <custom:tags>
not to mention any javascript you have running on the page :-)


 
Balaji Krishnan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unfortunately I cannot share a sample JSP, as it is against my organization's policy. Sorry for that.

However the JSPs in this application are very basic in nature, here are the few elements/tags which are contained in the JSPs to render dynamic data

1) JSP expressions.
2) JSP scriptlets.

And it doesn't have EL tags, custom JSP tags etc. Below is the two steps which will be implemented in this application to prevent XSS attacks,

a) Stripping of vulnerable characters present in request parameter & request parameter values in each request URLs. This will be implemented in a common request filter before the request reaches the corresponding servlet of an URI mapped.

b) Encoding of request parameter values in each servlet using ESAPI encoder API provided by OWASP. (This change impacts all the servlets in the application which is painful)

By doing the above two steps XSS attacks will be prevented in an application. I am planning to do a quick POC to prove this concept and kick start a project to get this done across the application. Is there free XSS checker tool anyone aware of? Please let me know.
 
Stefan Evans
Bartender
Posts: 1822
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stripping of vulnerable characters in requests? Like what sort of characters?
Be sure that Patrick O'Grady can still type his name into a text field without being caught by an overzealous policy against using single quotes.

I don't know of any automatic way to do it, but basically you have to look at the points in your JSP that you are outputting dynamic text to the screen and take appropriate action if that data is user entered.
Say for example you had captured a users name and stored it to a database.
If you are using scriptlet tags like <%= user.getUserName() %> into HTML, you could then wrap in one of those escape utilities <%= Encode.forHtml(user.getUserName()) %>
You could possibly do a global search and replace to help you fix such instances - but as the OWASP page says, depending on the context you are using it, different escaping rules apply, so running it blindly is not necessarily a good option.

Basically it comes down to what is being output by the page and where, and is it dangerous.
 
Balaji Krishnan
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I strip the vulnerable characters based on a regular expression list. Below are few sample regex, I will be configuring

<script>(.*?)</script>,\
src[\r\n]*=[\r\n]*\'(.*?)\',\

I should have mentioned it clearly in my earlier post. You're correct about the encoding utilities, I cannot blindly do a replace all with one encoding technique. Each file needs to be modified as per the security guidelines provided in OWASP.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!