This can help too on a already stored XSS on database or inject by other ways.
Klaubert On Thu, Apr 14, 2011 at 3:00 PM, Ryan Barnett <[email protected]> wrote: > Jonathan, > > I agree with your comments. > > Just to be clear - I am not suggesting that we should get rid of the > inbound XSS checks as they have a purpose. I am suggesting that we add in > this capability so that users can decide with methods of XSS defense they > want to use. I think that for many users, this new, additional approach > will help them to reduce false positives for XSS. > > -Ryan > > On 4/14/11 12:36 PM, "Jonathan Marcil" <[email protected]> > wrote: > >>Hi Ryan, >> >>I like the correlation between inbound and outbound in the POST. It >>gives you an insight on how the application is processing the input. >> >>But I see some ways that this can't replace full inbound checking and >>blocking : >>- What if the application is not outputting the input right away? >>- What if the application is actually outputting the input in many >>places in different ways? For instance, Drupal may output directly the >>content on a node after modification, but its doing security check on >>output in other places. Flaws can be everywhere in this case not just >>when you submit something. >>- What if a valid HTML in the output of a page that is not related to >>the user input can actually trigger a false positive? (let's say my >>website really do alert('XSS'); at some point ;-) >> >>Parsing on output seams harder to me because there's more stuff to parse >>: the whole page vs. a simple user input. >> >>Thanks, >> >>- Jonathan >> >> >> >>On 11-04-14 11:15 AM, Ryan Barnett wrote: >>> I have been thinking a lot recently about XSS Attacks and how >>>ModSecurity can potentially identify these attacks and respond - >>>http://www.modsecurity.org/documentation/XSS_Street_Fight-Ryan_Barnett-Bl >>>ackhatDC-2011.pdf >>> >>> I would like to get some community feedback on a possible new approach >>>for XSS. >>> >>> The big current issue I see with the ModSecurity CRS approach is that >>>the rules are looking for potentially malicious input and flagging them >>>as XSS and executing blocking. This approach is flawed for 2 reasons - >>> >>> 1. Many of the XSS signatures are too broad and are looking for any >>>html data on inbound. This may work OK if the application or specific >>>parameter is never supposed to contain html code, however many users >>>have apps that allow for some html code on the inbound. There are many >>>ModSecurity users who get upset because the rules end up blocking normal >>>transaction in applications like WordPress. The XSS signatures should >>>probably be broken up into separate files - 1) Malicious code which >>>would only contain signatures for confirmed, malicious code. These >>>rules can be acted upon for blocking actions in any circumstance. 2) >>>Html code which would trigger on any html-like code. This could be >>>activated for sites that don't allow any html code. >>> 2. Blocking inbound data for XSS is prone to False Positives. XSS >>>manifests itself when client-supplied data is echoed back out to clients >>>in a non-escaped format. The applications may actually be properly >>>output escaping user-supplied data and they don't need for ModSecurity >>>to do any blocking. It seems that the best place to choose a blocking >>>action for XSS is actually in the response back to the client. >>> >>> Here is an example approach for #2 above. >>> We are already flagging inbound data as potential XSS attacks and >>>saving the data in TX variables. If we were to not block for XSS on the >>>inbound, but instead inspect the RESPONSE_BODY variables for matches of >>>TX XSS data, we could then choose to block. Here is an example rule >>>which does just that - >>> >>> SecRule TX:/XSS/ "@within %{response_body}" >>>"phase:4,t:none,log,block,msg:'Malicious Client Data Found in Response >>>Page.',logdata:'%{matched_var}'" >>> >>> As a test, I sent the following request (from the ModSec audit log) - >>> >>> ############################### >>> --25ab4619-B-- >>> POST /cgi-bin/fup.cgi HTTP/1.1 >>> Host: localhost >>> Connection: keep-alive >>> Referer: http://localhost/upload.html >>> Content-Length: 429 >>> Cache-Control: max-age=0 >>> Origin: http://localhost >>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-US) >>>AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16 >>> Content-Type: multipart/form-data; >>>boundary=----WebKitFormBoundary5l4ChTnz96IS0ru8 >>> Accept: >>>application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,im >>>age/png,*/*;q=0.5 >>> Accept-Encoding: gzip,deflate,sdch >>> Accept-Language: en-US,en;q=0.8 >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 >>> >>> --25ab4619-I-- >>> note=%3cscript%3ealert%28%27xss%27%29%3c%2fscript%3e >>> --25ab4619-F-- >>> HTTP/1.1 200 OK >>> Content-Length: 308 >>> Keep-Alive: timeout=5, max=100 >>> Connection: Keep-Alive >>> Content-Type: text/html >>> >>> --25ab4619-E-- >>> <html> >>> <head> >>> <title>File Upload Results</title> >>> </head> >>> <body> >>> <h1>File Upload Results</h1> >>> >>> <p>You've uploaded a file. Your notes on the file were:<br> >>> <blockquote><script>alert('xss')</script></blockquote><br> >>> <p>The file's contents are: >>> <pre> >>> >>> </pre> >>> </body> >>> </html> >>> ############################### >>> >>> The new rule generated a number of events - >>> >>> [Thu Apr 14 11:00:59 2011] [error] [client ::1] ModSecurity: Warning. >>>String match within "<html>\\n<head>\\n<title>File Upload >>>Results</title>\\n</head>\\n<body>\\n<h1>File Upload >>>Results</h1>\\n\\n<p>You've uploaded a file. Your notes on the file >>>were:<br>\\n<blockquote><script>alert('xss')</script></blockquote><br>\\n >>><script></script>\\n<script></script>\\n<p>The file's contents >>>are:\\n<pre>\\n\\n</pre>\\n</body>\\n</html>\\n" at >>>TX:958052-WEB_ATTACK/XSS-ARGS:note. [file >>>"/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_customrules.con >>>f"] [line "17"] [msg "Malicious Client Data Found n Response Page."] >>>[data "alert("] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] >>>[unique_id "TacMK8CoqAEAAKdOIfUAAAAB"] >>> [Thu Apr 14 11:00:59 2011] [error] [client ::1] ModSecurity: Warning. >>>String match within "<html>\\n<head>\\n<title>File Upload >>>Results</title>\\n</head>\\n<body>\\n<h1>File Upload >>>Results</h1>\\n\\n<p>You've uploaded a file. Your notes on the file >>>were:<br>\\n<blockquote><script>alert('xss')</script></blockquote><br>\\n >>><script></script>\\n<script></script>\\n<p>The file's contents >>>are:\\n<pre>\\n\\n</pre>\\n</body>\\n</html>\\n" at >>>TX:958051-WEB_ATTACK/XSS-ARGS:note. [file >>>"/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_customrules.con >>>f"] [line "17"] [msg "Malicious Client Data Found n Response Page."] >>>[data "<script"] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] >>>[unique_id "TacMK8CoqAEAAKdOIfUAAAAB"] >>> [Thu Apr 14 11:00:59 2011] [error] [client ::1] ModSecurity: Warning. >>>String match within "<html>\\n<head>\\n<title>File Upload >>>Results</title>\\n</head>\\n<body>\\n<h1>File Upload >>>Results</h1>\\n\\n<p>You've uploaded a file. Your notes on the file >>>were:<br>\\n<blockquote><script>alert('xss')</script></blockquote><br>\\n >>><script></script>\\n<script></script>\\n<p>The file's contents >>>are:\\n<pre>\\n\\n</pre>\\n</body>\\n</html>\\n" at >>>TX:973300-WEB_ATTACK/XSS-ARGS:note. [file >>>"/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_customrules.con >>>f"] [line "17"] [msg "Malicious Client Data Found n Response Page."] >>>[data "<script>"] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] >>>[unique_id "TacMK8CoqAEAAKdOIfUAAAAB"] >>> [Thu Apr 14 11:00:59 2011] [error] [client ::1] ModSecurity: Warning. >>>String match within "<html>\\n<head>\\n<title>File Upload >>>Results</title>\\n</head>\\n<body>\\n<h1>File Upload >>>Results</h1>\\n\\n<p>You've uploaded a file. Your notes on the file >>>were:<br>\\n<blockquote><script>alert('xss')</script></blockquote><br>\\n >>><script></script>\\n<script></script>\\n<p>The file's contents >>>are:\\n<pre>\\n\\n</pre>\\n</body>\\n</html>\\n" at >>>TX:973307-WEB_ATTACK/XSS-ARGS:note. [file >>>"/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_customrules.con >>>f"] [line "17"] [msg "Malicious Client Data Found n Response Page."] >>>[data "alert("] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] >>>[unique_id "TacMK8CoqAEAAKdOIfUAAAAB"] >>> [Thu Apr 14 11:00:59 2011] [error] [client ::1] ModSecurity: Warning. >>>String match within "<html>\\n<head>\\n<title>File Upload >>>Results</title>\\n</head>\\n<body>\\n<h1>File Upload >>>Results</h1>\\n\\n<p>You've uploaded a file. Your notes on the file >>>were:<br>\\n<blockquote><script>alert('xss')</script></blockquote><br>\\n >>><script></script>\\n<script></script>\\n<p>The file's contents >>>are:\\n<pre>\\n\\n</pre>\\n</body>\\n</html>\\n" at >>>TX:973310-WEB_ATTACK/XSS-ARGS:note. [file >>>"/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_customrules.con >>>f"] [line "17"] [msg "Malicious Client Data Found n Response Page."] >>>[data "'xss'"] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] >>>[unique_id "TacMK8CoqAEAAKdOIfUAAAAB"] >>> [Thu Apr 14 11:00:59 2011] [error] [client ::1] ModSecurity: Warning. >>>String match within "<html>\\n<head>\\n<title>File Upload >>>Results</title>\\n</head>\\n<body>\\n<h1>File Upload >>>Results</h1>\\n\\n<p>You've uploaded a file. Your notes on the file >>>were:<br>\\n<blockquote><script>alert('xss')</script></blockquote><br>\\n >>><script></script>\\n<script></script>\\n<p>The file's contents >>>are:\\n<pre>\\n\\n</pre>\\n</body>\\n</html>\\n" at >>>TX:973331-WEB_ATTACK/XSS-ARGS:note. [file >>>"/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_customrules.con >>>f"] [line "17"] [msg "Malicious Client Data Found n Response Page."] >>>[data "<script>"] [hostname "localhost"] [uri "/cgi-bin/fup.cgi"] >>>[unique_id "TacMK8CoqAEAAKdOIfUAAAAB"] >>> >>> This approach seems to me to be more accurate for detecting/reacting to >>>XSS as you are doing the inspection/blocking in the outbound which means >>>that you have less false positives. >>> >>> Now, taking this approach one step further! With the upcoming >>>ModSecurity v2.6 you could actually extend the rule logic to use @rsub >>>against the STREAM_OUTPUT_BODY and actually remove malicious code from >>>response bodies and still send the page :) >>> >>> SecRule TX:/XSS/ "@within %{response_body}" >>>"chain,phase:4,t:none,log,pass,msg:'Malicious Client Data Removed From >>>Response Page.',logdata:'%{matched_var}'" >>> SecRule STREAM_OUTPUT_BODY "@rsub >>>s/%{matched_var}/MALICIOUS_CODE_REMOVED/d" >>> >>> Running new ruleset this is how the reflected XSS attack response >>>page would look to a client - >>> >>> $ curl >>>"http://localhost/cgi-bin/fup.cgi?note=<script>alert('xss')</script>" >>> <html> >>> <head> >>> <title>File Upload Results</title> >>> </head> >>> <body> >>> <h1>File Upload Results</h1> >>> >>> <p>You've uploaded a file. Your notes on the file were:<br> >>> <blockquote>MALICIOUS_CODE_REMOVEDalert('xss')</script></blockquote><br> >>> <p>The file's contents are: >>> <pre> >>> >>> </pre> >>> </body> >>> </html> >>> >>> Comments welcome! >>> >>> -Ryan >>> >>> >>> >>> >>> ________________________________ >>> 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. >>> >>> _______________________________________________ >>> Owasp-modsecurity-core-rule-set mailing list >>> [email protected] >>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >> > > > 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. > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > [email protected] > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
