This is basically an all-in-one repository for techie developer-related things I've experienced / come-across and from where I can easily look-up later.
From small useful tidbits, code / key shortcuts, tips, to articles /guides on how to do certain complicated tasks, all the way to full mini-programs for daily use.
If it helps anyone else out too great!

Tuesday, October 28, 2008

Most of us hardly give security vulnerabilities any consideration when creating a web-application. It's something that takes care of itself right? Mostly we get away with it because our applications may not be affected the moment it goes live. So it becomes a habit to ignore taking care of it.

But its a ticking time-bomb. Its strange because the cost associated with additional security considerations are negligible compared to the losses that can arise when the application is actually comprised!

One such vulnerability is XSS or Cross-site scripting. It comes out at number 1 for the second time running in the OWASP Top 10 2007 .

First, let's learn about our adversary. XSS vulnerabilities can be categorized into three distinct types. Each of these can be exposed in a variety of ways - this is only limited by the imagination of the attacker.

DOM-based XSS vulnerability is when the problem exists in the page's client script itself. This shouldn't happen unless your web-application itself is hijacked by a malicious attacker who then adds script that attack "safe" standard local HTML pages (that are usually installed with most applications, including IE). What can be done about it falls more into the scope of a system administrator. The other 2 are our responsibility...

Non-Persistent or Reflected vulnerability is the most common type of XSS. This is seen easily when there are inputs by the client into a web-page and this is displayed on a page returned by the server. Basically, this would mean that only the user who makes the inputs are affected.

Then there's Persistent or Second-order or Stored XSS. This is when the impacted data is stored on the server (file/database/LDAP/etc) - it is the most dangerous kind as it can affect any user to whom the compromised data gets displayed to.

How does all that sound to those of us who copy/paste a few snippets to address XSS (add code to ensure that no < or > make it through our inout fields, etc.) - although the solution seems to be a matter of restricting user input (or our output), we are all not exactly security experts to know about the dangers (never mind that the experts themselves are having a tought time).

This is where we can use library/frameworks developed by those who know the range of attacks out there.

One such tool is Antisamy, an open-source free library from OWASP.Antisamy can be used to verify that provided input (submitted by the user for example) does not contain any XSS vulnerability. It's highly configurable using XML files so that you can decide the amount of security you need for your inputs.And the best part is that it generates user-friendly responses pointing out the vulnerability which can be shown to the user.

// Display cleaned input using getCleanHTML() of CleanResults.System.out.println("\nCorrected output:");System.out.println(cr.getCleanHTML());//Display the errors encountered in the input using getErrorMessages()System.out.println("\nError Messages:");System.out.println(cr.getErrorMessages().toString().replaceAll(".,",",.\n"));}

So it's just a matter of taking the input and validating it based on the rules specified in the xml file through the CleanResults class. There are so many useful methods in this class - get all the details by downloading javadocs (get the source too) alongwith the library (make sure you have not just the main Antisamy library but also the supporting libraries) and sample application configuration files from the Antisamy page.

Practically speaking though, Antisamy is best suited for you when you already have a server-side trip - so its easily used for type 3 XSS. For type 2, if you have a client-side only thing going on, then you have to consider the consequence of having a server round trip just for the validation...