Re: [mod-security-users] modsecurity_crs_16_session_hijacking results into many false positives

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

The CSRF token need only to be inserted/verified for specific forms and some sensitive URL's but that's been taken care of by using an Apache Location directive.

But let's return to the real issue: false(?) (Sticky SessionID Data Changed - IP Address / User-Agent Mismatch) positives. That's what I don't understand!
It seems that only the first valid request leads to the " Sticky SessionID Data Changed " warning; the subsequent requests from the same clientIP/UA don't result in these kind of warning.

-----Original Message-----
From: Reindl Harald [mailto:h.r...@th...] 
Sent: maandag 23 juni 2014 12:29
To: mod...@li...
Subject: Re: [mod-security-users] modsecurity_crs_16_session_hijacking results into many false positives

Am 23.06.2014 12:12, schrieb John Donath:
> I'd like to implement the CSRF defense using 
> modsecurity_crs_43_csrf_protection ruleset which requires the 
> activation of modsecurity_crs_16_session_hijacking ruleset primarily for ModSecurity session persistent collection initiation.
> 
> I don't understand the many false positives (Sticky SessionID Data 
> Changed - IP Address / User-Agent Mismatch) as I am testing from a fixed IP address and UA.
> 
> It seems that only a http clients first request results in these 
> warnings; subsequent requests don't generate no longer any warnings

at the first request the client is completly unknown

i don't get how CSRF oustide the application will work in a sensible way without doing damage by request CSRF token all the time and throw false positives as well as make bookmarks possible or only for POST requests which leaves the door wide open

only the application knows that if param xyz is given it's a command which needs to be protected while for a search engine the field for the term don't need to be protected so you can bookmark a search

as i often said place ratecontrols in tze network layer CSRF belongs in the application itself

> *From:*Ryan Barnett [mailto:RBa...@tr...]
> *Sent:* zondag 22 juni 2014 23:28
> *To:* <mod...@li...>
> *Subject:* Re: [mod-security-users] 
> modsecurity_crs_16_session_hijacking results into many false positives
> 
> For session hijacking - the idea of those two checks are to see if the 
> IP network block changes (first 3 octets vs full octet) and/or if the 
> user-agent changes during a session. Each of these individually is not enough to block on their own but together can mean there is a problem.
>  
> That being said - we have a newer method of identifying a change in 
> user based on browser fingerprinting -
> 
> http://blog.spiderlabs.com/2014/02/modsecurity-advanced-topic-of-the-w
> eek-detecting-browser-fingerprint-changes-during-sessions.html
> 
> For CSRF protection (and others), you might want to try the new HMAC 
> token protection -
> 
> http://blog.spiderlabs.com/2014/01/modsecurity-advanced-topic-of-the-w
> eek-hmac-token-protection.html.  This works for CSRF protection as each URL becomes unique for each user.
> 
> On Jun 22, 2014, at 4:49 PM, "John Donath" <Joh...@de... <mailto:Joh...@de...>> wrote:
> 
>     Hi Reindl,
> 
>     I agree with you about variable IP's in the mobile world but I for testing I am using a client with a fixed IP
>     address!
> 
>     Also - in order to migitate CSRF attacks - the use the modsecurity_crs_43_csrf_protection.conf ruleset
>     modsecurity requires the modsecurity_crs_16_session_hijacking.conf:
> 
>     ********
>     # ---------------------------------------------------------------
>     # Core ModSecurity Rule Set ver.2.2.6
>     # Copyright (C) 2006-2012 Trustwave All rights reserved.
>     #
>     # The OWASP ModSecurity Core Rule Set is distributed under
>     # Apache Software License (ASL) version 2
>     # Please see the enclosed LICENCE file for full details.
>     # ---------------------------------------------------------------
> 
> 
>     #
>     # You must have also activated the 16 session hijacking conf file as
>     # it initiates the Session Collection and creates the CSRF token
>     #
> 
>     ********
> 
>     Do you have a clue howto to proceed given this requirement?
> 
>     Thanks,
>     John
>     ________________________________________
>     From: Reindl Harald [h.r...@th... <mailto:h.r...@th...>]
>     Sent: Sunday, June 22, 2014 9:22 PM
>     To: mod...@li... <mailto:mod...@li...>
>     Subject: Re: [mod-security-users] 
> modsecurity_crs_16_session_hijacking results into many false positives
> 
>     Am 22.06.2014 21:02, schrieb John Donath:
> 
>     I try to do find a way to migitate CSRF attacks and so I activated 
> the prerequisite
> 
>         modsecurity_crs_16_session_hijacking ruleset first.
> 
>          
> 
>         Activating the ruleset leads to many false positives (see details below) which I just don't understand:
> 
>         ****
> 
>         [Sun Jun 22 20:50:21 2014] [error] [client REMOTE_ADDR] ModSecurity: Warning. Match of "streq
>         %{SESSION.IP_HASH}"
> 
>         against "TX:ip_hash" required. [file
> 
>         
> "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_16_session_h
> ijacking.conf"] [line "35"] [id "981059"]
> 
>         [msg "Warning - Sticky SessionID Data Changed - IP Address 
> Mismatch."] [hostname "FQDN"] [uri
> 
>         "/presentation/screen.css"] [unique_id 
> "U6clbQoAkBUAACDpqawAAAAC"]
> 
>          
> 
>         [Sun Jun 22 20:50:21 2014] [error] [client REMOTE_ADDR] ModSecurity: Warning. Match of "streq
>         %{SESSION.UA_HASH}"
> 
>         against "TX:ua_hash" required. [file
> 
>         
> "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_16_session_h
> ijacking.conf"] [line "36"] [id "981060"]
> 
>         [msg "Warning - Sticky SessionID Data Changed - User-Agent 
> Mismatch."] [hostname "FQDN"] [uri
> 
>         "/presentation/screen.css"] [unique_id 
> "U6clbQoAkBUAACDpqawAAAAC"]
> 
>          
> 
>         [Sun Jun 22 20:50:21 2014] [error] [client REMOTE_ADDR] 
> ModSecurity: Warning. Operator EQ matched 2 at
> 
>         TX:sticky_session_anomaly. [file
> 
>         
> "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_16_session_h
> ijacking.conf"] [line "37"] [id "981061"]
> 
>         [msg "Possible Session Hijacking - IP Address and User-Agent 
> Mismatch."] [hostname "FQDN"] [uri
> 
>         "/presentation/screen.css"] [unique_id 
> "U6clbQoAkBUAACDpqawAAAAC"]
> 
>         ***
> 
>          
> 
>         I am testing the site from home with a fixed IP adress so why do I end up with a "IP Address Mismatch"?
> 
>         Any help would be much appreciated
> 
> 
>     it don't matter at all
> 
>     you can't seriously restrict a session against a IP address
>     that worked 15 years ago, but not in the decade of mobile
>     clients where it is common that your IP changes
> 
>     and the check of a changing user-agent can be easily done
>     inside the application or better said: that should be part
>     of any recent session handling