ModSecurity Blog: July 2008
29 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.
24 July 2008
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:
- 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.
- Behaviours can now specify character encodings, which is very important in order to properly parse parameters.
- We've allowed for a per-model data dictionary, which would allow parameter types to be defined once and reused throughout the model.
- 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.
24 July 2008
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:
- 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=+1In 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.
SecRule T2 K2
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.
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,denyIn the above example, the first rule blocks, but the second one just uses the ModSecurity defaults and only warns and lets requests through.
SecRule T1 K1
SecRule T2 K2
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.
- 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.
15 July 2008
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:
- 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.
- 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.
- 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:
- 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).
- Creation of partial application models for use in virtual patching.
- 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.
10 July 2008
Web Application Firewall Use Cases Update
My list of web application firewall use cases continues to involve. I've decided to shuffle things somewhat:
- 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.
- 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.
08 July 2008
XSS Defense HOWTO
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:
- Identify all system components other than the application itself. In a typical web application you will have at least the following:
- Browser output, which further consists of:
- Response headers (e.g. redirection, cookies, etc)
- 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:
- Databases typically need to be created with a character encoding in mind
- In the HTML pages you create, set the character encoding explicitly
- Then, for every component:
- Identify safe characters
- Identify how to make unsafe characters safe by converting them into something else
- 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!)
- Every such function must be aware of the character encoding used in the application
- 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
- 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.
https://www.example.com, which you use to create a link
<a href="https://www.example.com">Example</a>, you get
- 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.
- The OWASP Encoding project should be your starting point if you don't want to write all the encoding function yourself.
03 July 2008
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
Shame on us for not reporting this earlier, when it happened.