Yesterday I visited a dissertation arranged by the Java User Group Karlsruhe in the building of the University of Karlsruhe. Software Architect Patrick Schemitz from Netpioneer GmbH talked about Web Application Security Auditing.

Here are my notes:

• In case of non-targeted attacks, your server or application does not have to be absolute secure, just more secure than others. ;-)
• The German Federal Ministry has defined an interesting security layer model (PDF, german).
• Parallel to this layer is the layer of responsibility: from IT services over software developers to the end user.
• Techniques
  1. Server
     • SQL injection
     • Code injection (buffer overflow)
     • SMTP injection
  2. Client
     • Cross side scripting
     • Session hijacking
     • Session riding
• Demos
  1. Server
     • PHP: register_globals, eval()
     • Perl: system()
     • SQL: two queries are build on one, skipping code by using a SQL comment
  2. Client
     • Reflected XSS: Manipulate input through URL to poison HTML sent from server
     • Persistent XSS: Manipulate input which is stored on server and can be delivered every time
     • Session hijacking if session data is stored in URL
• Counteractions
  1. Do not trust the user input.
  2. Filter input in different ways for database and frontend.
  3. Avoid eval() and system().
  4. Search for dangerous files (backups with different file extension, test files etc.) in the webserver's document root.
  5. Security analytic tools do not find many holes.

Step 1: Preloading data

For nearly every application you need to login with your username and password. While the user tries to remember his password, we get a few extra seconds to load data. Be sure to do this unobtrusively, because some users wait until the loading bar disappears before they start working with a web application.

Step 2: Reduce requests

One of the biggest bottlenecks in modern browsers is the amount of active HTTP connections at the same time:

»A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.« RFC 2616

So much for the RFC, but how does it look like in real life?

Maximal amount of simultaneous connections to the same server	Firefox 2	Opera 9	Safari 3	IE 7
HTTP 1.1 connections	8	8	2	2
Persistent HTTP 1.1 connections	2	8	2	2
Values changeable?	yes prefs.js	yes Opera6.ini	no	yes Registry

To keep the amount of connections low, combine all CSS/JS files to one. While it is easy to put together all CSS and JavaScript files, we still have plenty of images which have to be loaded separately.

Instead of loading many small image files and applying them by using the src attribute, we will use a large single image file containing all images which are used on the web application. Each image will use this file as a background image with own background-position values. This technique is called CSS sprites. There is a CSS sprites generator which will not even generate an image containing all uploaded images, but also generate the CSS settings for it.

An optimal page would look like this:

• one HTML file
• one JS file
• one CSS file
• one or two CSS sprites images

The last point depends on whether you have transparent images in your application or not. If you have, you can use one transparent PNG8 file or GIF file with a transparent background and one JPEG file for all images with more than 256 colors.

Step 3: Build HTML on the server side

Experiments have shown that a web page loads faster if its content is build from static HTML than from dynamically generated HTML objects which are applied to the document object. This is especially useful if you have complex structures or a many HTML elements.

Step 4: Compress your data

Compression is an old but powerful way to reduce the load time. If your user's browser is supporting HTTP 1.1, you can enable HTTP compression. Besides, all ASCII documents such as HTML, JavaScript and style sheet files can be compressed by removing all whitespace characters.