0

I have put either of the following in my rules:

SecRule REQUEST_URI "@beginsWith /directory" "phase:1,id:12345,allow"
SecRule REQUEST_URI "@beginsWith /directory" "phase:1,id:12345,ctl:ruleEngine=off"

When I browse /directory/javascript.php?sqlinjection it will allow the HTML within /directory to be displayed, but the CSS and images which reside in the root directory /css/ and /images/, respectively are not displayed. It seems like they are being blocked because there's SQL injection on the page but no exclusions for those directories.

How can I configure it to fully shut off mod_security within /directory and display all images and CSS?

user3080539
  • 23
  • 5

1 Answers1

1

In ModSecurity each request is treated as an independent request and it has no idea that you are loading the CSS and images for a previous request.

The only way it might know this is what's in the Referer HTTP Header. In fact I suspect this is what is causing you the problem, since the URL of the referring page contains what looks like a SQL Injection so each resource it loads, also gets blocked.

So you've a number of options:

  1. You could write similar rules for /css and /images. Please note that your two rules both do the same thing and both are not necessary - choose one or the other. Also each rule needs to have an independent id but you have repeated 12345 in both rules.

  2. You could shut off ModSecurity for ALL requests. It seems to be causing you more problems and it's solving. Obviously this means you lose the security protections it gives but if you are just going to end up allowing nearly every request to shut it off, then that is one option.

  3. You could write a new rule to bypass ModSecurity based on that referer:

    #Allow any requests for resources loaded by pages in /directory SecRule REQUEST_HEADERS:Referer "@beginsWith https://www.example.com/directory" "phase:1,id:12347,allow"

  4. You could override the rule affected for this field (I'm assuming that rule 942100 is the one that's firing in this example):

    #Exclude Referer HTTP Header from being checked by rule id 949110 SecRuleUpdateTargetById 942100 !REQUEST_HEADERS:Referer

Option 4) would be the recommended way so you are only disabling the rule which is giving a false positive, for that particular field. Note that multiple rules may be firing so you may need multiple exceptions. You also stated on a previous question that rule 949110 was firing, but this is the final checking rule, so you need to know the rules that fired before this, and caused 949110 to step into action, and filter them out as per above.

This is also how you should really prevent your original PHP script from being blocked btw, rather than blanket turning off ModSecurity for the whole /directory location.

To be honest these are all fairly standard things you need to do to configure ModSecurity so suggest you read up on it more. The ModSecurity Handbook is the best way of learning this IMHO.

Barry Pollard
  • 4,461
  • 14
  • 26
  • I really don't see what I am doing wrong, I have been reading documentation for weeks and NOTHING I have done makes any difference. The referer code you gave me does not work no matter where I put it, CSS and images are still blocked. I already tried disabling modsecurity within /directory with SecRuleEngine Off and that does nothing. Additionally, the nolog entries in my rules do absolutely nothing as everything is still logged. The only time mod security recognizes any change I make is when I make a typo and apache does not start. This is incredibly frustrating! – user3080539 Nov 22 '17 at 17:40
  • Add ALL the error logs for the blocks and might be able to help rather than guess. Which is what I’m having to do now. – Barry Pollard Nov 22 '17 at 17:46
  • https://pastebin.com/Tixsz6zja The code you gave me is in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf but I have tried it in multiple places with same results. – user3080539 Nov 22 '17 at 18:16
  • Page has been removed. – Barry Pollard Nov 22 '17 at 18:18
  • Was it the exact code I gave you? 942100 was an example rule id. You need to change that to whatever rule is blocking. – Barry Pollard Nov 22 '17 at 18:19
  • I opted for the allow by refferal rule so any request which has a referal beginning with /directory is also allowed. I pasted it exactly as you mentioned: SecRule REQUEST_HEADERS:Referer "@beginsWith /directory" "phase:1,id:12347,allow" – user3080539 Nov 22 '17 at 18:42
  • And can you show the logs of why it is blocked? – Barry Pollard Nov 22 '17 at 19:07
  • The log I uploaded to pastebin (new url below, current expired) is what I get after I add your referer based exclusion, reload apache, and visit the javascript.php file. I'm not sure what other log you are looking for in that regard, the pastebin is the only one I have. https://pastebin.com/TDV24gFz – user3080539 Nov 22 '17 at 19:32
  • Ok that’s better. The referer does not start with /directory but with https://www.example.com/directory/ so the rule I gave was wrong. I edited my answer to correct this. Try that now (note I had to use example.com for the domain as wouldn’t allow me to post otherwise). – Barry Pollard Nov 22 '17 at 19:42
  • Wow thank you very much, that did the trick! Could you elaborate why beginsWith works with "SecRule REQUEST_URI "@beginsWith /egxpress"" but does not work with the referer? I was under the impression a full URI would also include https://example.com Thanks again! – user3080539 Nov 22 '17 at 20:36
  • No the REQUEST_URI only contains the bit after the domain. Have a look at your pastbin in the GET request (line 4) compared to the Referer (line 6). This is a legacy from original HTTP implementations where one server was assumed so no need to send the domain. The domain was later added in the Hosts HTTP Header (line 10) but the request is always domainless because it was felt it would break things too much to change this to add the domain when multiple virtual domains on the same server became common and the domain was needed. – Barry Pollard Nov 22 '17 at 21:36
  • Thanks for all your help. One last question - when my log file says "Message: Warning. ", that would not actually block anything if I turn off detection mode right? Am I correct to assume that it would only block something if it said "Message: Rule " and then the rule ID, such as Message: Rule 7f7c42c58588. The warnings are essentially just letting you know it hit rules but did not meet the anomaly score to block anything? – user3080539 Nov 22 '17 at 22:04
  • Yes I can see you are running in DETECTION_ONLY mode which does not block. Though in anomaly scoring mode all the real rules should not block, and one or two rules at the end sum up all the scores and then blocks if they are greater than a certain limit. – Barry Pollard Nov 22 '17 at 22:47