Thanks Nicholas,


As you say, the Referer header is prone to false positives as it is controlled generated by other sites and extend their false positives to your site. This is the reason it is not searched for SQL injection signatures in the core rule set, and I checking now whether to do the same for XSS just as you suggest.  


My experience is that the Cookie header is also prone to false positives such as this, but I'm less inclined to include an exception for the cookie header in the Core Set for two reasons:


(a) It is controlled by the application itself, and many times, such as in your case, the application should be changed rather than the rule. Storing the external Referer header in a cookie and presumably using it somewhere is a very good recipe for a security disaster.


(b) The Cookie header is used a lot by applications and therefore may be an attack channel more often than the Referer header


Saying that, I assume that you do not have a simple way to have the application modified and therefore need another solution.


I think that in your case the simplest and most effective would be to exclude the cookie header also (!REQUEST_HEADERS:Cookie). Since the cookie is controlled by the referrer it is just a matter of time until another signature will match, so removing onClick is a short time solution.


~ Ofer


From: [] On Behalf Of Nicholas Vulgrinski
Sent: Friday, January 19, 2007 7:02 PM
Subject: [mod-security-users] (no subject)


The referer often contains the URL and parameters from another site, such as a web search page, when someone navigates to our site via a search. We have found the Time Warner's websearch contains an onClick parameter that sets of the XSS rule.

This fix was suggest to exclude scanning the referer.


This almost worked for me, but our FireClick implementation stores the referer in the session cookie, so I still get a match (see below).

Sorry about the old version (rule id 50004).

I had already remove the ".cookie" part of the rule because our site has cookies named something.cookie.

I don't want to exclude an XSS on the cookies because we have observed other XSS attack attempt in the cookie.

Any suggestions?

[16/Jan/2007:14:18:34 --0600] EPbcZKwQIh8AAATnGgcAAAAa 55719 80
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
UA-CPU: x86
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1)
Cookie: JSESSIONID=UMHAKCHLXFI35LAQEZBSCOVMCATDOH20; ABTest.4=3; sid={AC102643-14D7-7459-1102-2C2C8ACB9E1F}; visitCounter=1; PSRC=G21; VSRC=HRN MRKT; SSRC=; MSRC=; TSRC=1; fcC=X=C1854576&Y=1168978630937&FV=8&H=1168978630921&Z=1&vis=g409650#e409650zaaaa.com_-_exact_match#m54z0#m56z0#m11z0#m42z0#l39#m52z1#m53z1#l17#e125482z-#m54z1#g440958#m40z0&D=G409651#E409651zaaaa.com_-_exact_match&F=0&I=1168978713171&E=5041538; fcP=C=0&T=1168978568750&DTO=1168978568671&V=1168978630921&fcV.1=G409651`1171570570406&fcV.2=E409651zaaaa.com_-_exact_match`1171570570421; fcR=http%3A//
TE: chunked;q=1.0
Connection: TE, keep-alive
Accept-Encoding: gzip
Akamai-Origin-Hop: 1
Via: 1.1 (AkamaiGHost)
Pragma: no-cache
Cache-Control: no-cache, max-age=0

HTTP/1.1 200 OK
Set-Cookie: sid={AC102643-14D7-7459-1102-2C2C8ACB9E1F};; expires=Fri, 29-Oct-2021 20:18:33 GMT; path=/
Set-Cookie: PSRC=G21;; expires=Fri, 29-Oct-2021 20:18:33 GMT; path=/
Set-Cookie: VSRC=HRN MRKT;; expires=Fri, 29-Oct-2021 20:18:33 GMT; path=/
Set-Cookie: SSRC=;; expires=Fri, 29-Oct-2021 20:18:33 GMT; path=/
Set-Cookie: MSRC=;; expires=Fri, 29-Oct-2021 20:18:33 GMT; path=/
Set-Cookie: TSRC=1;; expires=Fri, 29-Oct-2021 20:18:33 GMT; path=/
Keep-Alive: timeout=3, max=59
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

Message: Warning. Pattern match "(?:\\b(?:on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\\b\\W*?=|abort\\b)|(?:l(?:owsrc\\b\\W*?\\b(?:(?:java|vb)script|shell)|ivescript)|(?:href|url)\\b\\W*?\\b(?:(?:java|vb)script|shell)|mocha):|type\\b\\W*?\\b(?:text\\b(?:\\W*?\\b(?:j(?:ava)?|ecma)script\\b|[vbscript])|application\\b\\W*?\\bx-(?:java|vb)script\\b)|s(?:(?:tyle\\b\\W*=.*\\bexpression\\b\\W*|ettimeout\\b\\W*?)\\(|rc\\b\\W*?\\b(?:(?:java|vb)script|shell|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder|background-image:)\\b|a(?:ctivexobject\\b|lert\\b\\W*?\\())|<(?:(?:body\\b.*?\\b(?:backgroun|onloa)d|input\\b.*?\\btype\\b\\W*?\\bimage)\\b|!\\[CDATA\\[|script|meta)|(?:\\.(?:(?:execscrip|addimpor)t|fromcharcode|innerhtml)|\\B@import)\\b)" at REQUEST_HEADERS:Cookie. [id "50004"] [msg "Cross-site Scripting (XSS) Attack"] [severity "WARNING"]
Stopwatch: 1168978713435236 735698 (233 2539 -)
Producer: ModSecurity v2.0.3 (Apache 2.x)
Server: Apache/2.0.52 (CentOS)



TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.