Securing Your JSF Pages Against XSS
Join the DZone community and get the full member experience.Join For Free
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
|Browser||Version||No Reads||No Writes||Read in XMLHttpResponse|
|IE||8 beta 2||yes||yes||partially|
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>|
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.