Hi Barry, first, thank you for your very detailed answer.
On Sun, Apr 16, 2017 at 08:46:44PM +0000, Barry Pollard wrote: > 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?). yes, I just tried to that. > 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. I thought through that before, but I thought Modsecurity stores it in memory... I've found few e-mails on mailing lists, where users discusses about hash tables for session/ip, session/UA, but I didn't dound any other information about that. Anyway, is there any information about it in Modsecurity DOCS? > 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). well, now that's clear, many thanks for your explanation. >> 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!). yes, I found those features and I could tested them. > 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! right, > 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)? yes, but this answer indicates new question(s) :). Eg. is there a good documentation about the ruleset language? I mean, where can I see the BNF of language? Where can I find any documentation how can I write a custom own rules? (Sorry, I know that's these questions aren't relates to CRS, rather to libmodsecurity.) > 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. good feature, > 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. I'ld like to protect my webservers against the attackers, not the "regular" users, so I think that's a good and useful feature :). > 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. I could't reached this point - as I wrote above, I'm looking up a mini-howto, or any other doc about the own rules. > 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. well, thanks for your personal opinion. I don't want to confide the full protection to Modsecurity, but I think that would be a good additional module for a full stack. > 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. thanks for your tips, I'll review those. > 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!). thanks too, > 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. yes, you're right, I know - and apologize for this thread. Many thanks for your help again. a. -- I � UTF-8 _______________________________________________ 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
