Hi Rian,

 

Thanks for your fast response.

 

I ‘ve read your advisory below but I’d like to stick to the “recommended” approach with the CentOS 6 modsecurity 2.7 and it’s rulesets as available in the distribution; I can’t afford to tryouts in production environments.

 

My question is rather simple IMHO.

 

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.

 

Do you have any idea?

 

Tnx,

John

 

 

From: Ryan Barnett [mailto:RBarnett@trustwave.com]
Sent: zondag 22 juni 2014 23:28
To: <mod-security-users@lists.sourceforge.net>
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-week-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-week-hmac-token-protection.html.  This works for CSRF protection as each URL becomes unique for each user. 

 

Let me know if these work. 

 

Ryan Barnett

Senior Lead Security Researcher, SpiderLabs

 

Trustwave | SMART SECURITY ON DEMAND

www.trustwave.com


On Jun 22, 2014, at 4:49 PM, "John Donath" <John.Donath@detron.nl> 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.reindl@thelounge.net]
Sent: Sunday, June 22, 2014 9:22 PM
To: mod-security-users@lists.sourceforge.net
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_hijacking.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_hijacking.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_hijacking.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




------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
mod-security-users mailing list
mod-security-users@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/

 



This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.