Web-based applications have become more complex in the recent years as a result of this fact the variety and level of vulnerabilities have also increased significantly.
This is the first article out of a series of articles on security of Java web applications particularly powered by JSF, RichFaces and Seam. This article focuses on the XSS attacks and provides recommendations on securing applications against this type of attacks.
The second article is focused on the XSRF attacks.
Useful information about security audit tools such as Ratproxy will be gathered in the third article.
XSS
Overview
XSS abbreviation stands for Cross-site Scripting. It is often also abbreviated as CSS, but then it could be mistakenly read as Cascading Style Sheets. The point of the XSS is to inject some piece of unfiltered data (often JavaScript) to the web page to bypass the browsers same-domain security policy. The success of this type of attack hinges upon the potentially vulnerable web applications such as chats, guest books, forums where data inserted by a user contains not only text, but also HTML tags, such as links to other documents. XSS vulnerability is caused by the failure of a web application to validate user supplied input before inserting it to the data store (file, DB) and returning to the client system. It is fair to say that more than 75% of the currently known web exploits are based on principles of such attacks, which makes them really critical.
Vectors
XSS attacks could be categorized into two vectors: stored and reflected.
The stored attack means that malicious code is permanently stored in a database, a message forum, comments, etc. A victim retrieves this code when he/she requests the stored information.
The reflected attack is delivered to victims via web page, e-mail message. When a victim clicks on a special crafter link or submits a form, the malicious code is injected as a part of the request to the vulnerable server and then the server reflects the attack back to the victim's browser, which executes the code.
Here is an example taken from YOUmozBlog:
Actually we can define one more vector that formally could be labeled as the reflected attack. We could call this vector as "self-sufficient attack". This attack doesn't require XSS vulnerability in web applications. The point of this vector is the data: protocol (specification could be found in RFC2397). Data protocol is a very purposeful protocol comparing to http:, https:, ftp:. Ajax applications could generate executable files (DOC, PDF, MP3) without any support of server-side scenarios. With the help of JavaScript a hacker could generate DOC or PDF files that contain a malicious code (for buffer overflow, for example).
XSS aims
The XSS vulnerabilities could be used for the following purposes:
- a website defacement - an attack on a website that changes the visual appearance of the site
- cookie stealing in order to hijack a user's session and take off the account
- statistics gathering
- administrator action emulation
Simple example
Let's create a simple JSP page "Greeter" and try to launch a simple XSS reflected attack:
<?xml version="1.0" encoding="UTF-8" ?>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Greeter</title>
</head>
<body>
<h1>Greeter</h1>
<form id="myForm" method="get">
Your name:<input id="in" name="in" />
<input type="submit" value="Get greeting" />
</form>
<% String in;
if(request.getParameter("in")!=null && request.getParameter("in")!=""){
in = "Hello, "+request.getParameter("in")+"!";
}else{
in = "";
}%>
<%= in %>
</body>
</html>
In the example above if you enter your name and submit the form, a greeting message appears. What will happen if you submit a piece of JavaScript code, for example <script>alert(document.cookie)</script>? No doubt an alert box appears with all of your cookies inside.
So possible attack scenario could look like this one:
Possible protection
In order to protect your applications you should take the following steps:
- validate user input to make sure it's what you are expecting. In this case you could use standard JSF validators. As for JSF applications with RichFaces on-board there are 3 validators you could easily use: <rich:ajaxValidator>, <rich:graphValidator>, and <rich:beanValidator>. For the further information, please, see RichFaces LiveDemo site and read about validators in the RichFaces Developer Guide
- encode user input before inserting it to an HTML page. Note that getParameter(), getHeader(), and getCookie() methods are the primary sources of malicious code. Thus while you are getting data from the HTTP request you need to call an encoding method appropriate for the place you’re inserting that data into the HTML page. Actually JSF and RichFaces components have a possibility to encode all text data out-of-box. However Seam Framework also provides measures to prevent XSS attacks. For more information, please, go to Web vulnerabilities and countermeasures page.
References
Here is a list of web sites where you can also get helpful information about XSS attacks:
- a good article for beginners
- OWASP article with the good reference information
- XSSed project that provides information on all issues related to XSS vulnerabilities with the largest archive of XSS vulnerable websites
- XSS (Cross Site Scripting) Cheat Sheet - page for profound understanding of nuances regarding filter evasion
- XSS (Cross Site Scripting) Prevention Cheat Sheet
Comments