ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to

ModSecurity Blog: July 2008

ModSecurity In Solaris

Although Solaris has been supported as a platform for ModSecurity since the very beginning, it has now become part of Sun's Cool Stack:

Cool Stack is a collection of some of the most commonly used open source applications optimized for the Sun Solaris OS platform. By using these binaries you will enjoy the best levels of performance from your system, while also reducing your time-to-service.

Enough With Default Allow Revision 2

A revised version (but still a draft) of the Enough With Default Allow in Web Applications! paper is now available for download. (My previous post on this topic is here.) The major changes in this version include:

  1. Decided to use a flat model of resources, rather than a hierarchical one, after realising the nested approach would make models very difficult to read for any non-trivial application. Also, we wanted to support the virtual patching case, which doesn't work with nesting very well.
  2. Behaviours can now specify character encodings, which is very important in order to properly parse parameters.
  3. We've allowed for a per-model data dictionary, which would allow parameter types to be defined once and reused throughout the model.
  4. Many clarifications and small fixes throughout.

Update (4 Aug 2008): Updated links to point to the final version (spell-checked, reviewed and branded) of the paper.

Three ModSecurity Rule Language Annoyances

There are three aspects of the ModSecurity Rule Language we are not very happy with. One comes from a wrong design decision (my own), with further two from constraints of working within the framework of Apache. All three break the principle of the intuitive action being the expected one. I am going to document them here and explain how we are planning to mitigate them in future versions:

  1. In a chain starter rule, disruptive actions are processed when the chain matches, but non-disruptive actions are processed when the rule matches. In other words, it is only the disruptive actions that are treated differently in chains, all other action types behave as they would in standalone rules. Have a look at the following:

    SecRule T1 K1 chain,log,block,setvar:tx.counter=+1
    SecRule T2 K2
    In the example above the counter will be incremented if the first rule matches even if the chain doesn't. The blocking action, although defined with the same rule, would only be processed if both the first rule and the second rule match.

    In retrospective, disruptive actions for chains should have been placed with the last rule in a chain, not with the first one. If it is possible to move to that mechanism in the next major version while preserving compatibility with existing configurations we will do that.

  2. SecDefaultAction is valid only for the configuration context in which it is used and is not inherited in child contexts. Configuration contexts are an Apache feature and they come with limitations, one of which is causing this problem.
    SecDefaultAction log,deny
    SecRule T1 K1
    <Location /some/other/path>
    SecRule T2 K2
    In the above example, the first rule blocks, but the second one just uses the ModSecurity defaults and only warns and lets requests through.

    In the next major version of ModSecurity (v3) we will handle our configuration ourselves and this problem will probably go away. In fact, the SecDefaultAction directive might be made obsolete in the next major version because we don't like it much. In retrospective, it was a wrong choice too. It is good practice to write rules to be self-contained. That way they will be easier to understand and maintain, and you don't risk configuration errors due to something being changed in the configuration elsewhere.

  3. Configuration contexts other than <VirtualHost> cannot hold phase 1 rules. Again, this is a limitation of the current implementation that relies on Apache for configuration functionality.

    Short term (e.g. 2.6), we are planning to see if we can detect phase 1 rules in places where they cannot be run and respond with an configuration error. The problem will go away once we start handling our own configuration.

Enough with Default Allow in Web Applications!

The title of this blog post is also the title of a research paper we are currently working on. Although the paper is still in draft form, we've decided to circulate it widely (download here) because we believe a public exposure in this early stage would benefit it significantly. Also, as you will see from the paper, for the proposed concept to succeed it must have support from many diverse groups of users. What do we want to achieve? Let's look at the summary:

The default allow deployment model, which is commonly used to implement
and deploy web applications, is the cause of numerous security problems. We propose
a method of modelling web applications in a platform-agnostic way to adopt
a default deny model instead, removing several classes of vulnerability altogether
and significantly reducing the attack surface of many others. Our approach is best
adopted during development, but can be nearly as efficient as an afterthought, or
when used at deployment time.

Our main problem is with these three things:

  1. HTTP (in a wider sense, taken to mean all specifications needed to develop and deploy web applications) has grown to be quite complex, but although applications generally use a very small subset they are still expected to support every single feature.
  2. Many applications are treated as simple collections of files (if it's on the filesystem it's part of application), and this is creating all sorts of issues.
  3. Applications do not specify their external interfaces. This is really a consequence of the above two problems. Applications cannot specify external interfaces because they are all implicit.

The bottom line is that we have a chance to create a beautifully positioned protection layer (between web servers and applications), which would not only increase security overall, but turn applications into verifiable components with external contracts that can be enforced.

We propose a use of a platform-independent format to document what applications are willing to accept from the outside world, with the following use cases envisioned:

  1. Creation of full application models, which reduce application attack surface. Such models can be created by application developers (which is preferred) or by application users (which, we expect, could happen with very popular and/or open source applications).
  2. Creation of partial application models for use in virtual patching.
  3. Automated creation of application models through traffic analysis.

In addition to the paper itself, we are planning to release an open source profiling tool (which I will announce next week) to help with the third use case and automate the creation of positive security models (also known as the learning feature of web application firewalls).

Download Enough With Default Allow in Web Applications!

Update (4 Aug 2008): Changed links to point to the final version (reviewed, spell-checked and branded) of the paper. The follow up post is here.

Web Application Firewall Use Cases Update

My list of web application firewall use cases continues to involve. I've decided to shuffle things somewhat:

  1. I am going to remove the "Network building blocks" use case because that is really a feature of reverse proxies. If a WAF happens to be implemented on top of a reverse proxy that it will also inherit all of its benefits (and downsides, I should mention). In retrospective, I thought the two (reverse proxies and WAFs) should really stay separate.
  2. I am going to add "Learning" as a new use case. As I was looking at the previous list of use cases it stroke me that I was failing to convey the ability of web application firewalls to understand what is going on, and this is what learning does.

Note: This post is part of the Web Application Firewall Concepts series.


We all agree that cross-site scripting is a serious problem, but what continues to amaze me is the lack of good documentation on the subject. It is easy to find instructions how to execute attacks against applications vulnerable to XSS, but finding something adequate to cover defence is a real challenge. No wonder programmers keep making the same errors over and over again. I am sure that one page that describes the problems and the solutions is somewhere out there, but I have been unable to find it. All I am getting is a page after page after page of half-truths and partial information, and even people saying that XSS is impossible to defend against.

Without any planning (so please forgive any omissions), I am now going to write how to produce web applications that are safe against XSS and other injection attacks.

This is what you need to do:

  1. Identify all system components other than the application itself. In a typical web application you will have at least the following:
    1. Database
    2. Browser output, which further consists of:
      1. HTML
      2. JavaScript
      3. CSS
      4. Response headers (e.g. redirection, cookies, etc)
  2. Adopt one character encoding (use UTF-8 unless you have a good reason not to) and make sure all components are configured to use it:
    1. Databases typically need to be created with a character encoding in mind
    2. In the HTML pages you create, set the character encoding explicitly
  3. Then, for every component:
    1. Identify safe characters
    2. Identify how to make unsafe characters safe by converting them into something else
    3. Write a function that looks at characters one by one to determine if they are safe, and converts those that are not (whitelisting, not blacklisting!)
    4. Every such function must be aware of the character encoding used in the application
  4. Then, for every piece of code that sends data from one component into another, make sure you use the correct function to encode data to make it safe
  5. Check that every piece of data you receive is in the correct character encoding and that the format matches that of the type you are expecting (input validation). You must use whitelisting (as blacklisting does not work). This is especially important for user-supplied Internet addresses—see below for details. Before you do anything with the input data make sure to canonicalise it (as suggested by Jim Manico in one of the comments), which will reduce the possibility of evasion through the use of multiple representations of the same character.

The first 4 steps from the list are the actual XSS defence. The fifth item is a matter of good practice and does not directly protect against XSS in most cases. In fact, there is only one case where it does protect, and that is in preventing attackers from executing JavaScript code in data pretending to be an Internet address (e.g. instead of, which you use to create a link <a href="">Example</a>, you get javascript:alert('xss').


  1. Google Doctype, which is a reference library for web developers, is by far the best resource on XSS, but it too fails when it comes to defence, advising people to use blacklisting instead of whitelisting.
  2. The OWASP Encoding project should be your starting point if you don't want to write all the encoding function yourself.
  3. For the cases when you want to accept some HTML/JavaScript/CSS you will need to adopt a different approach: meet AntiSamy.

ModSecurity In HP-UX Internet Express

We receive questions about ModSecurity running on HP-UX from time to time, but since we don't have access to the platform there is very little we can do to help. Fortunately, most questions fall into the "Does it run?" category. The answer is that it does (or so our users tell us). Actually, HP made ModSecurity part of their Internet Express package a while ago:

HP-UX 11i Internet Express is a collection of the most popular up-to-date Internet and security services and tools, combined with an Open Source graphical administration utility for ease of installation, configuration and management. Internet Express ships as optional open source software as part of the OE/AR media kit. The Open Source components in the Internet Express suite are certified for HP-UX 11i supported HP 9000 and Integrity systems and supported by the open source community.

Shame on us for not reporting this earlier, when it happened.


November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Atom Feed



Recent Entries