Over 10 years experiences across various industries, with focus on the finance industry. I have led the development team delivering multi-million dollar projects for online trading solution, relaunching of the retail banking website, portfolio management website, trading platform. He recently started his own blog at http://www.kole-consulting.com.au Ed has posted 3 posts at DZone. View Full User Profile

Securing Your JSF Pages Against XSS

03.22.2010
| 14455 views |
  • submit to reddit

Cross site scripting (XSS) is a security vulnerability found in websites where malicious attackers inject malicious javascripts to steal information from users accessing the websites. This type of attack usually take advantage of defects in websites that have minimum checking on user inputs hence allow attackers to put malicious code onto the websites. There are a few types of attacks

1. Non-persistent, where attackers put malicious code in the request, resulting in the destination page executing the code. Even though this seems harmless (because it seems like the attackers can only attack the page he is viewing himself), however, attackers can put the malicious code inside a hidden frame on his/her own websites and once the user visits the website, the malicious code is executed without user knowing, and therefore steal visitors information. For example, I could have hide the code of this link inside a hidden frame and submit the cookie back into my server.

2. Persistent Very similiar technique are applied here, but this impact is much more wide spread and serious. This is because attackers are able to embed malicious code into the content of a prominent website. Websites that allows people to post HTML contents usually suffer from this vulnerability.

Protect your site against XSS

Obviously the best defense to XSS is to make sure that you always validate inputs from browser. Here I will share a few tips with JSF/Java developers on some of the defense techniques available.

Escape output text

<h:outputText/> and <h:outputLabel/> by default has the escape attribute set to True. By using this tag to display outputs, you are able to mitigate majority of the XSS vulnerability.

SeamTextParser and <s:formattedText/>

If you would like to allow users to utilise some of the basic html tags to customise their inputs, JBoss Seam provides a <s:formattedText/> tag that allows some basic html tags and styles specified by users. Please refer to the Seam Reference Manual for details on the syntax. You can also customise SeamTextParse to add additional supported syntax. The <s:formattedText/> tag uses this class to validate and escape user's inputs by default.

Protect your site's cookies

Java web application doesn't make heavy uses of cookies, however, jsessionid is the cookie that mostjava web application must have in order for the application server to keep track of user sessions. To protect cookies against malicious javascript, most modern browsers support the feature to allow application to specify whether a specific cookie can be accessed by javascript or should be for http only. Below is a list of browsers and the support for http-only setting:

Browser Version No Reads No Writes Read in XMLHttpResponse
IE 6 sp1 yes no no
IE 7 yes yes partially
IE 8 beta 2 yes yes partially
Firefox 3 yes yes yes
Safari 3 no no no
Chrome Beta yes no no

 (Source: OWASP)

Some application servers also allow http-only jsessionid cookie configuration as well, here is a list of supported servers and their versions.

Application Server Version HttpOnly jsessionid
Tomcat 6 No, but can use apache with mod_header Header edit Set-Cookie ^(.*)$ $1;Secure;HttpOnly
Tomcat 5 No, but can use apache with mod_header
JBoss EAP 5 <Context cookies="true" crossContext="true" useHttpOnly="true">
JBoss EAP 4.3 No, but can use apache with mod_header
Weblogic 10.3 No, but can use apache with mod_header
Weblogic 9 <wls:session-descriptor> <wls:cookie-http-only>true</wls:cookie-http-only> </wls:session-descriptor>
Jetty   No

Defending against malicious attackers is not an easy tasks. However, most of the attacks can be mitigated by employing simple principles during application development, such as escaping user inputs. Raising the awareness of security, provide training, and setting common practices are the most effective way to protect your websites.

From KoLe Enterprise Consulting blog

Published at DZone with permission of its author, Ed Lee.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)