4

I have been developing a Webobjects application, and I found that my application is vulnerable to XSS through URL, but not when malicious input like <script>alert("hi")</script> is input to form fields.

So, i have currently employed technique of URL rewriting in apache web server to solve this issue.

I have handled following javascript keywords : src onload onmouseover onkeypress onfocus alert

I dont know enough about XSS.

I want to know from experts here, is this is the right approach to solve XSS when the input to form fields is not showing vulnerability ?

Please suggest.

2
  • 2
    A blacklisting approach is not the correct way to approach this. You need to determine why your URLs are vulnerable and why your form field input is not. I suspect you might want to check a little more in-depth that your form field input is not vulnerable. Are you actually actively sanitizing those fields on your server side or simply allowing the browser to "enforce" sanitizing for you? If the latter, then you have vulnerabilities on your form fields as well. Commented Apr 20, 2012 at 16:11
  • @logicalscope : Its somehow the webobjects application, that makes the form fields to prevent from XSS. I will take your point into consideration, to investigate further. Thanks. Commented Apr 21, 2012 at 4:27

2 Answers 2

7

Nope. You should not try to fix XSS by doing URL rewriting in your Apache web server. That's not a good way to go about it, as the result will be fragile at best. In particular, if you stick with your current approach, there will most likely still be sneaky ways to exploit the XSS.

Instead, if the web application has XSS holes in it, fix the darn web application. This is an application security problem; you have to fix it by fixing the application. Trying to patch things up externally is probably going to be leaky like a sieve.

P.S. Your list of keywords is insufficient. You've built a blacklist, and like any other blacklist, your blacklist is inevitably incomplete. You're missing some stuff (* cough * onerror * cough *). I'm not going to try to provide you with a more complete list, because the approach is fundamentally broken and rather than sticking with the approach and trying to extend your list of attributes to filter -- you need to ditch the current approach entirely and fix the problem at its source.

7

There is a good resource from OWASP: XSS (Cross Site Scripting) Prevention Cheat Sheet

Basically you should validate all input data using white list approach (define valid patterns not invalid patterns as you are trying to do at this moment) AND you should encode all data on output using encoding scheme correct for given context (HTML, JavaScript, HTML attribute).

Correct encoding is quite difficult and you shouldn't be doing it by yourself. Instead you should use library like Microsoft AntiXSS Library or OWASP ESAPI.

You can also use ModSecurity (or other WAF) with correct detection rules (i.e. ModSecurity Core Rule Set), but be aware that this should not be the only solution you use.

1
  • AntiXss is for DotNet applications whereas Esapi is for Java. Here is a Javascript library for the same purpose : js-xss Commented Jul 5, 2019 at 11:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .