Re: jsessionid cookie length

Hi Ives,

you raised up an interesting point which inspired me to have a more detailed look
at this instead of just saying "go left" or "go right".
I did setup the following two rules on my local machine:

     SecRule ARGS:variable " <at> gt 4"  "t:length,pass,id:1000"
     SecRule ARGS:variable ^.{5,}$  "pass,id:1001"

The rules should semantically express the same condition. I've set the
debug log-level to 9 and here is the output, when accessing the server
as

      http://localhost/?variable=ABC

Extracting Rule-Execution Times
-------------------------------

I've updated my jwall-tools to a new version:

	 http://download.jwall.org/jwall-tools/0.5.4/

This version adds a "rule-times" command which allows for reading the ModSecurity
debug-log and extracting statistics about the rules, that have been invoked. This
usually requires a debug-log level of 4 or higher.

After installing the new jwall-tools, I sent 100 requests with a random value
for the "variable" parameter and ran the following command:

    # jwall rule-times /var/log/apache2/modsecurity-debug.log

The result is as follows:

------OUTPUT------
root <at> modsecurity:~# jwall rule-times /var/log/apache2/modsecurity-debug.log 

  The following table contains the rule-times extracted from the ModSecurity
  debug-log. For the rule-times command to work, you need to have at least
  a debug log-level of 4 enabled.

  The column "Invocations" contains the number of rule invocations found in
  the log, "total time" is the average time required for the rule in total
  (transformation + operator).
  The last two columns contain the average times for the transformations,
  executed by that rule and the application of the rule operator.

   +-------------+-------------+--------------+----------------+------------+
   |     Rule Id | Invocations |  total time  | transformation |  operator  |
   +-------------+-------------+--------------+----------------+------------+
   |        1000 |        100  |       4.440  |        2.040   |      2.400 |
   |        1001 |        100  |       4.090  |        1.060   |      3.030 |
   +-------------+-------------+--------------+----------------+------------+

------OUTPUT------

As you can see, the version using regular expressions takes slightly more time
compared to the one using "t:length". So, in a sense, this should answer your
question.

Note: The numbers are the nano-seconds required in average (averaged over the
number of invocations). These are the numbers recorded by ModSecurity in the
debug-log.

Feel free to download the jwall-tools and check the performance yourself 

Feedback is of course welcome.

Regards,
    Chris

Am 07.07.2012 um 22:01 schrieb Ives Stoddard:

> Chris,
> 
> One more quick question. I noticed that there is a length function in the reference guide for modsecurity.
> 
> Under heavy load, would there be a performance gain in using length vs. regex? I haven't seen too many
examples of the use of that function however.
> 
> 
> 
> 
> On Sat, Jul 7, 2012 at 12:20 PM, Ives Stoddard <ives.newsfeed <at> gmail.com> wrote:
> Chris,
> 
> Exactly what I was looking for.
> 
> Many thanks.
> 
> -ives
> 
> 
> 
> On Sat, Jul 7, 2012 at 2:56 AM, Christian Bockermann <chris <at> jwall.org> wrote:
> Hi Ives,
> 
> I'm not sure what exactly you're looking for. You can add restrictions on the
> cookie value with regular expressions, e.g.:
> 
>     SecRule REQUEST_COOKIES:jsessionid ^.{10,32}$   \
>             "deny,msg:'Cookie value for session id of invalid size!',phase:2"
> 
> Usually you'd expect a fixed-length cookie value, so you can change the regular
> expression to match that by using:
> 
>     SecRule REQUEST_COOKIES:jsessionid ^.{32,32}$ ...
> 
> 
> To check the cookie as well as any possible corresponding cookie-parameter, you
> can use multiple targets:
> 
>     SecRule REQUEST_COOKIES:jsessionid|ARGS:jsessionid  ^.{32,32}$   ...
> 
> This should raise an alert if either the cookie value or any parameter with name
> 'jsessionid' does not match your required length anymore.
> 
> 
> If you know the set of chars that your application server is using to create
> the jsessionid value, then you might want to limit that as well:
> 
>     SecRule REQUEST_COOKIES:jsessionid|ARGS:jsessionid  ^[a-z0-9]{32,32}$  \
>       "t:lowercase,deny,msg:'Unexpected value for jsessionid!',phase:2"
> 
> 
> Regards,
>     Chris
> 
> 
> 
> Am 07.07.2012 um 05:35 schrieb Ives Stoddard:
> 
> > hi,
> >
> > anyone know of a good way to restrict the length of a jsessionid cookie?
> >
> > i noticed modsecurity has a length function, but i haven't found examples of how this might be used in
conjunction with a specific cookie. the only examples I found that deal with cookies have more to do with
number of cookies.
> >
> > i've looked at doing something similar with rewrite rules (matching anything where cookie length is
over N, but that's for the entire cookie list, not just jsessionid). ModSecurity would be a cleaner
approach since i could tie it into exception logging / alerting.
> >
> > many thanks.
> >
> > -ives
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> > mod-security-users mailing list
> > mod-security-users <at> lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
> > Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> > http://www.modsecurity.org/projects/commercial/rules/
> > http://www.modsecurity.org/projects/commercial/support/
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/