0

I have been searching for quite some time and finally decided to posts this question on how Mod Security locks out a user from a domain.

I have a large site with a lot of legacy URL's with '$' and "%" in them, this was removed but there are legacy links all over that will trip some mod security rules.

The main issue is once a rule is triggered, a 403 error is returned as expected on that page, but going to any other page on the domain now will throw a 403 error as well utill the cookies are cleared on the browser. This of course is not user friendly as many people will not know about the clear cookies fix and If they are locked out I cant obviously let them know easily while not wanting to remove all the rules that cause this.

example of a url

[code] Request: GET /phpBB2/promotions/9927-1st-deposit-bonus-125%25move-up-sun-palace-casin.html Action Description: Access denied with code 403 (phase 2). Justification: Invalid URL Encoding: Non-hexadecimal digits used at REQUEST_URI. [/code]

this is a
950107: URL Encoding Abuse Attack Attempt

Also many errors in the Mod Security Log I see simply GET / as the trigger and that obviously is not the root cause.

Chris Trenka
  • 1
  • 2

1 Answers1

0

My first thought is if this rule is firing incorrectly because such a use case is (or was) valid then you should probably disable this rule with:

SecRuleRemoveById 950107

If your page no longer exists then this will presumably return a standard 404 message without this rule. Which is probably more correct to the user than 403 and better UX. Will also mean you don't get ModSecurity alerts in your logs for these false positives. OK it could mean you miss a genuine attack this rule is designed to block, so you need to weigh up the risk of that versus the downside of upsetting some of your users. Personally I don't think this rule is protecting you from a major security problem so would disable it.

Also need to understand exactly what the problem is here. Rule 950107 checks the URL, not the cookies so, while I understand it firing for the initial request, it must be a different rule which is firing for the subsequent blocking errors? Not sure how cookies are being set incorrectly and to such a value that causes problems in future so need more details.

It is possible to remove cookies using a combination of ModSecurity and Apache using a method documented by Ivan Ristic in his ModSecurity Handbook, but it's a bit convoluted and involves a couple of steps:

1) Create a rule which detects when you want to remove the cookies and sets an environmental variables. For example to check for a URL containing the word "value_to_check" use a rule like this:

SecRule REQUEST_URI "value_to_check" "id:12345,phase:1,setenv:DISABLE_OUTBOUND_SESSION"

2) Get Apache to request the browser unsets the SESSIONID Cookie where that env variable is set, using mod_header:

Header always set Set-Cookie "SESSIONID=; expires 31-Dec-1999 00:00:00 GMT" env=DISABLE_OUTBOUND_SESSION

Note that this doesn't fix any bad incoming cookies. There's similar fixes for that depending on the exact problem.

I would suggest however you understand the full problem first as there may be better solutions.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • OK, so it appears I misunderstood what was happening. For some reason I believed that once you hit a page with the old structure containing a bad character mos Security was setting a cookie to not allow you back. As if to say your trying to hack us so this cookie will at least screw with you, but it appears they are separate issues. So to be clear if you trigger a rule such as the URL encoding sql attack type Mod Security is not setting a cookie to restrict you. – Chris Trenka Mar 12 '15 at 12:23
  • That's correct. ModSecurity doesn't do that by default and neither do the OWASP core rules. So something else must be blocking your later attempts. Could be cause the bad URL is in the referrer field now and it's causing it to block? Or could be because of a DoS or brute force rule triggering (as those rules do block future attempts until a time runs out). Either way the logs should tell you. – Barry Pollard Mar 12 '15 at 19:04
  • Or it could be a completely unrelated Cookie. The OWASP rules will most likely create a lot of false positives. Recommended practice is to deploy on DetectionOnly mode initially and then keep an eye on AuditLog entries (set this to RelevantOnly) and fine tuned the rules to your environment. Only when happy turn on full blocking. – Barry Pollard Mar 12 '15 at 19:26
  • After having this trigger again on me twice, and only removing one cookie at a time from my browser it appears to be a facebook cookie causing the trigger. An example (this one does not cause the error) fbm_121818371243477 – Chris Trenka Apr 16 '15 at 00:23
  • The default OWASP CRS rule set can cause a lot of false positives. As I already said you need to turn on audit logging (to RelevantOnly) and see which rule is firing incorrectly and tweak the rule or disable it. And, as also mentioned above, you should be running the rules in DetectionOnly mode for a period until you are comfortable that the rules are not flagging real requests. – Barry Pollard Apr 16 '15 at 06:21