Re: [mod-security-users] Help formatting XSS block

[Bill B. <bra...@gm...>]

Thanks Ryan!

That worked perfectly. I have now passed all my penetration tests
testing....I hope.
The only change i made was that i didnt have that ruleset so i just
dumped it in the modsecurity_localrules.conf
where I had some SSL cookie forcing rules!


On Tue, Jul 21, 2009 at 7:41 AM, Ryan Barnett<rya...@br...> wrote:
> On Tuesday 21 July 2009 12:20:34 am Bill Bradley wrote:
>> Bill Bradley
>> to mod-security-u.
>>
>> show details 11:24 AM (11 hours ago)
>>
>>
>> Reply
>>
>> Follow up message
>> Hey All,
>>
>> I am new to modsecurity
>
> Hey Bill, welcome aboard!
>
>> but have implemented the
>> modsecurity_crs_40_generic_attacks.conf from the optional_rules
>> directory to block and log XSS scripting. So far it is working great.
>>
>
> The current Core Rule Set (CRS) does a decent job against most attack
> payload classes (including XSS) but as you found out, they are not perfect.
> The only way that they will get better is if users report these
> bypass/evasion issues. So thank you for reporting this issue. By the way -
> we have an official JIRA ticketing system so you can report issues there and
> it will be properly tracked to resolution -
> https://www.modsecurity.org/tracker/
>
> Also of note - we will be releasing CRS version 2.0 within the week which
> will include significant updates to the rules including a separate rule set
> just for XSS.
>
>> The app is being tested by penetration folks and they are still able
>> to pass on XSS attack:
>>
>>
>> XSS vulnerability found in backend parameter. The following attack
>> targets all browser(s) and was successful using plain
>> encoding:
>> "><iMg SrC=x OnErRoR=window.location=42114>
>>
>
> If you look in the modsecurity_crs_40_generic_attacks.conf file, you will
> see the XSS section. It starts off with the set-based pattern matching
> pre-qualifiers where it is looking for any core keywords for the attack
> class -
>
> SecRule
> REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer
> "@pm jscript onsubmit copyparentfolder javas
> cript meta onchange onmove onkeydown onkeyup activexobject onmouseup
> ecmascript bexpression onmouseover vbscript: <![cdata[ http: .innerhtml
> settimeout shell: onabort asfunction: onkeypress onmousedown onclick
> .fromcharcode background-image: .cookie ondragdrop onblur x-javascript
> mocha: javascript: onfocus lowsrc getparentfolder onresize @import alert
> script onselect onmouseout application onmousemove background .execscript
> livescript: vbscript getspecialfolder .addimport iframe onunload
> createtextrange <input onload"
>
> In looking at these keywords, there are other browser/DOM actions such as
> onblur, onfocus, onmousemove, etc... but it doesn't appear that we have one
> for your example payload - onerror. So, I would go ahead and add the
> following rule to a modsecurity_crs_15_customrules.conf file -
>
> SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES "\bonerror\b\W*?\=" \
> "phase:2,deny,capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'Cross-site
> Scripting (XSS)
> Attack',id:'1',tag:'WEB_ATTACK/XSS',logdata:'%{TX.0}',severity:'2'"





> I tested this new rule against the following example request -


>
> http://www.example.com/cgi-bin/test-cgi?foo="><iMg SrC=x
> OnErRoR=window.location=42114>
>
> The rule triggered appropriately and generated the following alert in the
> Apache error_log file -
>
> [Sun May 31 02:25:14 2009] [error] [client 192.168.1.103] ModSecurity:
> Access denied with code 403 (phase 2). Pattern match "\\bonerror\\b\\W*?\\="
> at ARGS:foo. [file
> "/usr/local/apache/conf/enhanced_rule_set-1.7.0/base_rules/modsecurity_ers_15_customrules.conf"]
> [line "2"] [id "958409"] [msg "Cross-site Scripting (XSS) Attack"] [data
> "onerror="] [severity "CRITICAL"] [tag "WEB_ATTACK/XSS"] [hostname
> "www.example.com"] [uri "/cgi-bin/test-cgi"] [unique_id
> "SiIiyn8AAQEAABGXB-QAAAAA"]
>
> Hope this info helps,
> Ryan
>
>