Logging XSS Indicators

Yes, unfortunately you should

The Web 2.0 Threat

During the last years XSS attacks have become increasingly popular. This happens because

• browsers do not and can not enforce a strict same origin policy and because
• they are very hard to prevent (unless you are using an XML server page language like KID).

The only means to stop this is enforcing a strict same origin policy by a means like CSP. Until then the best you can do is at least detect XSS.

The Event Logger

The event logger logs client side javascript activities that could possibly indicate an XSS attack. It will also log things like google analytics that are legitimate. So filtering of the generated logs for unusual activities is necessary. The following activities are detected:

1. DOM mutation events, that occur when HTML is modified from Javascript,
2. document.write calls that insert into the page while it loads,
3. javascript errors and
4. loading images into Image objects.
5. In addition it scans the DOM for URLs from other domains.

Other domains are determined by comparing the end of the hostname with document.domain.

The event logger is targeted to work with Firefox 3.5+ browsers. It should have reduced to no functionality on other browsers and it should always fail gracefully. In most cases it will be sufficient if one major browser reports an attack.

How to use it

This is beta software and should in its current state not be used on a production site without checking for side effects.

To use the event logger you need to include its script in each page including all frames. To log the events you need the following apache configuration:

LogFormat "%h %l %u %t \
 \"%{User-Agent}i\" \"%{Referer}i\" \
 %{X-JSLog-sequence}i %{X-JSLog-type}i \
 \"%{X-JSLog-positionCode}i\" \"%{X-JSLog-positionDom}i\" \
 %{X-JSLog-message}i" jslog
SetEnvIf    Request_URI "^/not_found/jslog" JSLOG
CustomLog   /var/log/apache2/test.vostro-jsEvents.log   jslog  env=JSLOG
# Avoid 404s
RedirectMatch 204 "^/not_found/jslog"
  

Note that the RedirectMatch is not required for logging. It does avoid cluttering the error log with "Not Found" messages.

Unexpected Intruders

Running the event logger on a life site revealed a surprising amount of activity. Three types of activity where found.

1. Browsers are patching invalid HTML using DOM manipulation,
2. browser extensions are doing DOM manipulations and
3. spy- and adware is doing DOM manipulation.

Browser extensions can be recognized by internal URIs with chrome:// or chrome-extension:// schemas. There is no obvious way of identifying spyware. Loading javascript libraries from external sites is however suspicious unless it comes from one of the well known library sites such as ajax.googleapis.com. Delivering a library to browsers generates costs through traffic and CPU usage that are most likely justified by some benefit.

Unfortunately this produces a level of noise that makes it hard to detect actual XSS attacks. The usability of the event logger for its intended purpose is questionable, but the logs are really interesting.

The Log

Reload

Basic Tests

DOM Mutation Tests

Remove Attribute Data Insert

Load an external image

Image Load

Provoke a JS Error

Error

Look into an IFrame

Write Document (on Load)

Application Tests

Include Google Analytics

Unfortunately this must be done at page load time and can not easily be done on click.

Do a JQuery JSON request

Load JSON

Do a JQuery ajax request

JQuery AJAX request from an IFrame
Direkt JQuery AJAX request