Hi Ryan, thank you very much for your answer.
Indeed, that line checks for an existing session cookie for all rules
until the END_SESSION_STARTUP marker, and it performs as expected.
I was referring to the last two rules (981063 and 981064, lines 47 and 49),
which will try to setvar even when the SESSION collection hasn't yet been
initialized (e.g. for session-less users, like bots or anonymous users).
This results in two "collection does not exist" errors per transaction.
Not very serious, but quite a bit of log noise :p
Another small issue:
I also noticed that because I run Modsecurity in embedded mode,
a lot of response headers aren't yet "released" by Apache on phase 3.
That includes the Set-Cookie header, which is vital for rule 981062.
But I managed to solve these issues by making the following
3 important modifications for my use case:
- Modify the regex to fit my Session Cookie name
(that's to be expected, of course)
- Move execution of rules 981062 (Session creation),
981063 and 981064 (IP and UA Hash creation) to phase 5:
Since they are all non-disruptive, and because the Set-Cookie
response headers are only available at the logging phase
for embedded installs, this enables successful session
initialization for all install modes!
- Execute rules 981063 and 981064 with a session existence test:
. That way, IP and UA hashes are only created for an existing session,
or one that was just created by the previous 981062 rule.
No more errors for session-less navigation.
. I came up with the following session existence test:
SecRule &SESSION:SESSIONID "@eq 1" "chain..."
. Apparently, it's important that this test be the first in chain,
so as to prevent the errors showing up (maybe the rule is parsed
without being executed when further down the chain? I'm not sure...)
Anyways, this is how I re-wrote the 981062, 981063 and 981064 rules:
http://pastebin.com/raw.php?i=4X5eh2nJ
Is it a smart and sound resolution of my problem?
Am I in the wrong regarding best practices?
So far (well, since yesterday), it has been working very well for me!
Thank you again for taking the time, much appreciated =)
-------------------------------------------------------------------------------------------------
On 04/03/2014 16:53, Ryan Barnett wrote:
What CRS version are you running? In the current verion (2.2.9) in GitHub
repo, there is this line -
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/optional_ru
les/modsecurity_crs_16_session_hijacking.conf#L27
This checks the inbound request for the existence of popular SessionID
cookie names. If they are NOT found, then it will skip the inbound
session hijacking checks.
Ryan Barnett
Lead Security Researcher, SpiderLabs
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>
On 3/3/14 1:18 PM, "Ramy Darwish" <jackbro.pluc...@gmail.com> wrote:
Reposting as plain text for formatting...
------------------------------------------------------------
Hi everyone!
I'm trying to fit the Session Highjacking rules
(modsecurity_crs_16_session_hijacking.conf) to my web app.
My problem was described by someone else (but apparently never solved)
on that older post on the modsecurity-users list:
http://sourceforge.net/p/mod-security/mailman/message/30069414/
The Session Highjacking rules look at request and response cookies to
find or create a new sessions.
That works perfectly.
However, the two rules after it will run in ANY case, even when no
sessions has been initialized:
-----------------------------------------
SecRule REMOTE_ADDR
"^(\d{1,3}\.\d{1,3}\.\d{1,3}\.)""chain,phase:3,id:'981063',capture,t:none,
nolog,pass"
SecRule TX:1
".*""t:sha1,t:hexEncode,setvar:session.ip_hash=%{matched_var}"
SecRule REQUEST_HEADERS:User-Agent
".*""phase:3,id:'981064',t:none,t:sha1,t:hexEncode,nolog,pass,setvar:sessi
on.ua_hash=%{matched_var}"
-----------------------------------------
Because the session collection wasn't initialized (e.g. for anonymous
users or bots),
the setvars fail and the log is filled with errors like:
-----------------------------------------
[example.com/sid#7fc5067fe380][rid#7fc4f43380a0][/path/to/file][3] Could
not set variable "session.ip_hash" as the collection does not exist.
[example.com/sid#7fc5067fe380][rid#7fc4f43380a0][/path/to/file][3] Could
not set variable "session.ua_hash" as the collection does not exist.
-----------------------------------------
To avoid this problem, I would like to chain these rules with a
Collection existence check, to avoid non-existence errors.
My two questions:
1/ I don't know how to test for the existence of the session
collection.
I don't know if it makes a difference that the rule is parsed on
phase 3 (response headers).
2/ More importantly, it seems like even chaining it to an impossible
rule
(e.g. SecRule &ARGS:x58t4z5 "@gt 128") will not stop it from
logging these errors!
Maybe I misunderstood chaining or variable collections, but I
can't seem to comprehend this issue!
If anyone can enlighten me on either or both, I'd be delighted to hear
your advice. Thanks!
Ramy
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
