Securing Your JSF Pages Against XSS
Join the DZone community and get the full member experience.
Join For FreeCross 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
Opinions expressed by DZone contributors are their own.
Comments