10 WAYS TO IMPROVE YOUR PROTECTION WITH MODSECURITY.pdf

Web application defenders are often the first, last and only line of defence protecting your web based assets. When

your latest new Web 2.0 HTML5 and AJAX based application makes it through production, past QA and a cursory pen

test, the web defender may be the only thing standing in between malicious attackers and your company's crown

jewels.

Once web applications hit the production stage, making updates or applying security fixes are often difficult due to

infrequent change windows. One of the best tools a web defender can use to gain visibility into how attackers are

most popular ModSecurity recipes that defenders can use to dramatically improve their security posture with minimal

language.

When web site performance is critical for business continuity, every additional millesecond counts. The current

trunk code fixes a long-standing limitation where ModSecurity needed to create a new VM for each request, which

added latency every time a Lua script was executed. By combining the new Lua VM implementation along with

replacing the Lua interperter with LuaJIT we can enjoy a significant speed increase in script execution.

To measure the speed difference we will test with a simple script used to generate a random token as part of a

predictable session token patch. The code is below:

If we run this script 1000 times via the ModSecurity 2.6.2 engine, the script takes an average of 616 microseconds to

run, as shown below:

Lua 5.1 "LuaJIT is also fully ABI-compatible to Lua 5.1 at the linker/dynamic loader level. This means you can compile

a C module against the standard Lua headers and load the same shared library from either Lua or LuaJIT." In other

words, all we need to do to use LuaJIT with ModSecurity is to load the LuaJIT shared library in the Apache

ModSecurity module configuration. On a Debian Sid based system this looks like:

With these changes we will run the same script again and compare the results.

As you can see the script execution went from 616 microseconds down to 112 microseconds. While the example

script we used here was simplistic and added little overhead to begin with, with the changes described above more

complex Lua scripts can be run with greater efficiency.

On a recent engagement we gained unrestricted administrative access to a certain proprietary web application by

exploiting a Session Fixation flaw. According to the WASC Threat Classification v2, Session Fixation is an attack

technique that forces a user's session ID to an explicit value. In other words, by feeding the victim a session token

will discuss two methods to virtually patch this flaw using ModSecurity. The first approach removes the session

token submitted within the authentication request. On some frameworks, the application will automatically assign a

new session token if none is submitted when succesfully logging in to the application. This approach uses inter-

module communication between ModSecurity and ModHeaders, as shown below.

While the above approach is pretty straightforward, it does not work in all situations. The next approach can be

used if the application does not set a new session token when an authentication request is submitted without a

session token. This method uses the session collection to tie a new token to the existing application-generated

session token. There are two parts to this solution, the ModSecurity rules and the Lua script. First, let's look at the

ModSec rules.