Yay, my first PULL request ever! Would be delighted to do that. In fact doing so right now.
Thank you! Ramy On 05/03/2014 15:17, Ryan Barnett wrote:
On 3/4/14 12:33 PM, "Ramy Darwish" <jackbro.pluc...@gmail.com> wrote: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 =)Your approach looks good! Can you issue a PULL request in GitHub so we can incorporate your updates? https://github.com/SpiderLabs/owasp-modsecurity-crs Thanks, Ryan ________________________________ 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.
_______________________________________________ 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
