.
—
Sent from my phone
On Thu, Mar 5, 2015 at 4:06 AM, null
<[email protected]> wrote:
> Send Owasp-modsecurity-core-rule-set mailing list submissions to
> [email protected]
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> or, via email, send a message with subject or body 'help' to
> [email protected]
> You can reach the person managing the list at
> [email protected]
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Owasp-modsecurity-core-rule-set digest..."
> Today's Topics:
> 1. ModSecurity cPanel Reporting Capabilities (Chaim Sanders)
> 2. Re: Successful Redirect Attack Scoring only 3 with Core Rules
> (any clue?) (Christian Folini)
> ----------------------------------------------------------------------
> Message: 1
> Date: Wed, 4 Mar 2015 21:36:56 +0000
> From: Chaim Sanders <[email protected]>
> To: "[email protected]"
> <[email protected]>
> Subject: [Owasp-modsecurity-core-rule-set] ModSecurity cPanel
> Reporting Capabilities
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
> Are you using OWASP CRS and cPanel? We are happy to announce that cPanel has
> just added the ability to 'Report a Rule'. We are very excited about this new
> feature because, as we all know, a WAF is only as good as its ruleset. If you
> are using cPanel with OWASP CRS and you find that a rule is not working
> correctly we highly encourage you to follow the steps outlined at
> https://documentation.cpanel.net/display/ALD/ModSecurity+Tools#ModSecurityTools-Reportarule.
> This will file a report about the rule directly with the ModSecurity team
> and we will do our best to quickly address the concern. We'd like to thank
> the cPanel team for going the extra mile in implementing this feature, we
> really do think it will make everyone more secure. If you are not using
> cPanel please remember to open issues on GitHub or email the mailing list if
> you find a bug. We are always on the lookout for how to improve our rules.
> Chaim Sanders
> Security Researcher, SpiderLabs
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com<http://www.trustwave.com/>
> ________________________________
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/attachments/20150304/ecf963fe/attachment-0001.html>
> ------------------------------
> Message: 2
> Date: Thu, 5 Mar 2015 09:32:56 +0100
> From: Christian Folini <[email protected]>
> To: [email protected]
> Subject: Re: [Owasp-modsecurity-core-rule-set] Successful Redirect
> Attack Scoring only 3 with Core Rules (any clue?)
> Message-ID: <20150305083256.GA14398@elias>
> Content-Type: text/plain; charset=utf-8
> Hi Achim,
> Good to hear from you. Unfortunately, nobody else responded. We'll
> see how far we can get.
> On Tue, Mar 03, 2015 at 09:00:35AM +0100, Achim wrote:
>> this is a typical "header injection" attack. AFAIK CRS has no spezial
>> rules for that. What best fits is the HTTP Response Splitting rule 950911,
>> but it is far to specific to match in this case.
> You hit the nail on the head. We first had a response splitting
> vulnerability. Then we lowered the limit (which had been raised by
> a sysadmin on his own), then the pen-tester worked around the lower
> limit with this redirect vulnerability scoring 3 on the core ruleset.
>> I'd suggest to craft a new set of rules for header injections.
> I think that is due.
>> Also a variant of your example would be the meta tag, if the aplication
>> writes the paramter there.
> Agreed.
>> In OWASP Top 10 (2013) this is A1 and A10.
> dito
> So what can we do? I must say I am a bit at loss when thinking about a
> good _generic_ approach.
> (1) Disallow CR/LF in Query-Strings
> This seems do-able, but it does not help us with request bodies
> (2) Disallow CR/LF in Query-Strings and Request Bodies
> This will raise a ton of false positives. But tuning them away
> on certain input fields could do the job
> (3) Disallow CR/LF in Query-Strings and Request Bodies in combination
> with certain keywords
> This might bring less false positives, but "Refresh" is a standard
> word, so you can not rule them out.
> What keywords would need to be covered to address the issue?
> What transformation / escape variants?
> (4) Disallow refresh header / meta tag in response phases
> Will only work when ResponseBodyAccess is enabled.
> And I think there are are still tons of applications around who
> redirect applications in this way. -> False Positives
> (5) Define a list of allowed redirects, then disallow refresh headers /
> meta tags not pointing to these hosts/domains.
> I am not sure if such a list / variable-to-take-this-list
> exists in the core rules. It's definitely a pain in the A* to
> maintain. And the restriction with ResponseBodyAccess
> in (4) applies too.
> I am not particularly fond of all these variants and I would appreciate
> if somebody had a better idea.
> Ahoj,
> Christian
> P.S. I will talk about practical CRS Tuning in Berne, Switzerland,
> next Tuesday, 4pm. If anybody wants to join.
> More infos here: http://www.sig-switzerland.ch/de/event_bern.php
> --
> Any technology that does not appear magical is insufficiently
> advanced. ?
> -- Gregory Benford
> ------------------------------
> _______________________________________________
> Owasp-modsecurity-core-rule-set mailing list
> [email protected]
> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
> End of Owasp-modsecurity-core-rule-set Digest, Vol 71, Issue 2
> **************************************************************
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
[email protected]
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
