This is a VERY subjective topic, but my opinions are below. On 16 Apr 2017, at 20:26, Ervin Hegedus <
...and I could demonstrate the advantages of WAF to my collegues. But there were only two basic attack, what I could show them: XSS and SQL injection. My 2 cents question is: how can I demonstrate another features? I meant, it could be show the session fixating: I put a simple PHP script to a webroot, load the page in a browser. I found the PHPSESSID cookie, and then I tried to load the page in another browser (on another host) - but there didn't happened anything... the page had been loaded as well with the hijacked session. What did I miss, or how can I show this feature? The Session Fixation protection in the OWASP CRS won't protect against you coping and pasting the session id to another browser (I presume that's what you did btw?). To do that it would need to either 1) keep a collection of Session ids versus IP addresses or 2) Somehow inject the session id into the page and check it again as a XSRF-type protection. ModSecurity CAN do both of these things but is not very good at either to be honest. The OWASP Session-Fixation protection (https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf) has basically three protections: 1) It looks for attempts to manipulation HTTP data (e.g. "set-cookie" mentions in request arguments), which shouldn't be sent and may be examples of someone trying to use XSS or software bugs/flaws to reflect the setting of the cookie back. 2) It looks for requests where the arguments include common session variable names and the referrer domain is different from the host domain, which may be examples of a phishing attempt being used to provide these variables. 3) It looks for request where the arguments include common session variable names and the referrer domain is not supplied (similar to above). In general way, how can I show the all features of Modsecurity, and OWASP CRS? That's a VERY subjective question. In my opinion XSS, SQL injection are two of the most useful protections of ModSecurity (though SQLi in particular is prone to false alterting!). Other benefits, many of which are easily demonstrable, include: 1) Full logging of requests (including POST arguments). Very useful extra feature - even if running in DetectionOnly mode as you should when you first install this. The ability to Debug issues and/or retrospectively review logs after and incident is invaluable. Though make sure you set it up properly and sanitise passwords, credit cards and other personal data or you're just creating security issues! 2) Virtual Patching. If a particular attack is identified it's often a lot easier to write and deploy a ModSecurity rule, than to fix in the code. This gives you protection immediately and time to do the proper fix instead of rushing out a half-baked, half tested fix. Though this short be seen as a short term fix and the proper fix should be applied. Who knows when you'll move away from a webserver that supports ModSecurity and/or turn it or this additional rule off (either accidentally or on purpose for some reason)? 3) Path traversal or remote code execution attacks. E.g. it's easy to block requests looking for /etc/password or variants in arguments. Or any request looking for .exe or .bat files. 4) Identification and/or blocking of bots and other scripts that use malformed requests. On one side, often these are harmless, but on other most browsers behave and send valid request so why not block the noise and let you concentrate on real requests. 5) Data leakages - including stack traces and the like. Though scanning of outbound data is usually a bigger overhead than inbound due to the size of the requests involved so think carefully before you turn this on. But it's very easy to write a rule so a 500 response code, triggers checks for stack traces for example. A lot of the other protections that it COULD give, are not as robust - and used to be in a folder called "experimental for that reason in CRSv2. They involve using collections (which don't work well in ModSecurity once you get any volume) and/or content injection (which I personally don't think a WAF should do). Don't mean to sound negative and I'm a big fan of ModSecurity and all it can do, but just warning you to not get too excited by DoS protection (thankful removed from OWASP CRS page as used to be stated as a feature there) or the like. At least until you understand how it could implement that and the downsides of its implementation. To really get the most out of ModSecurity I recommend the ModSecurity handbook (https://www.feistyduck.com/books/modsecurity-handbook/) originally written by ModSecurity's created Ivan Ristić (who's since moved on to other things in the security industry) and recently updated by Christian Folini (who's pretty active on this mailing list and I'm sure will pipe up with his own answer - possibly before I hit send on this one!). They also run a training course on same site. To read up a bit more explanation as to how the OWASP CRS protects, and also see some proof of concepts with the more advanced techniques (though in my opinion they shouldn't all be used in production systems) then the "Web Application Defender's Cookbook" by Ryan Barnett gives some food for thought. The book isn't without flaws, but does show how you could push ModSecurity to cover more. Ryan also used to be heavily involved in maintaining both ModSecurity and OWASP CRS but has also moved on (though does lurk here so apologies to him if he takes the "flawed" statement above personally!). Not sure how this mailing list feels about blatant recommendations like that, but since I'm not directly affiliated with ModSecurity, OWASP or either if the books above, hopefully no one will mind me sharing my opinion.
_______________________________________________ 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
