HTML and CSS in URLs causing 404 errors (User Agent = Trident/4.0)

I've been getting some 404s with snippets of code (CSS, HTML and JavaScript) in the URL.

As best as I can tell the user is progressing through the site just fine during their session - its an ecommerce site and the affected users are putting stuff in their basket and checking out OK etc.

On certain pages I'm see 404 errors adjacent to a seemingly successful page display. I get the same 404 error every time that page is displayed (within that session).

Example of a logged 404 error:

404;http://www.example.com/rrepeat: repeat-y;

There is a single matching instance on the page in question (apart from the first "r"):

<td style="background-image: url(/i/lb_ccccccbrd.gif); background-repeat: repeat-y;">

I've checked the included CSS files and none have matches (and presumably if they did I would get a 404 on all the pages which include the CSS file)

My thought was that maybe its a PlugIn for IE8 that is spidering the page whilst th开发者_StackOverflow中文版e user is viewing it to cache something - or possibly for more malevolent purposes. The user-agent for pages and the 404 (within that session) is the same [don't know if a PlugIn would show differently to the browser itself?]

Other examples:

/r/table></form></td><td width= 
/r width=

/r alt= 

/rurn pair[1]; --&gt;</SPAN> --&gt;</SPAN>--&gt;</SPAN>function Set_Cookie( name, value, expires, path, domain, secure ) <SPAN style="color:red;font-weight:bold;background-color:yellow;">&lt;!--/ set time, it's in millisecondsvar today = new Date();today.setTime( today.getTime() );/*if the expires variable is set, make the correct expires time, the current script below will set it for x number of days, to make it for hours, delete * 24, for minutes, delete * 60 * 24if ( expires )<SPAN style="color:red;font-weight:bold;background-color:yellow;">&lt;!--expires = expires * 1000 * 60 * 60 * 24;--&gt;</SPAN>*/expires = (3650) * 1000 * 60 * 60 * 24;var expires_date = new Date( today.getTime() + (expires) );document.cookie = name +

All seem to start with an "r" that is not part of the code, then a snippet direct from the code for the page.

The page passes w3c.org HTML validation (so I don't think it is, say, an unlcosed quote, unless I have some goofy javascript breaking the HTML!!)

User Agent is always MSIE 8.0 or MSIE 7.0 and Trident/4.0. (I assume the MSIE 7.0 with Trident is IE8 in compatiblity mode)

I'm only seeing a few instances of this a day (less than 10 sessions), whereas I am getting hundreds sessions a day with User Agent including IE8 and Trident.

Thanks.

It seems to me that you're dealing with either malformed spider or an attempted XSS attack.

If it's happening on a small scale, the best course of action is to make sure you've locked down your application/site so that such attacks remain unsuccessful.

Keep an eye on your logs. If stuff like this picks up in frequency and/or changes it's vectors of attack, you'd best be aware of where such efforts are directed and respond accordingly.

Lastly, the "IE8/Trident" client identifier isn't anything special. It simply states that the client says they're running Internet Explorer 8 using the Trident layout engine (similar to Safari/WebKit or Mozilla/Gecko).

I was experiencing the same issue. On Trident 4.0 browsers, the application would suddenly start refering to weird js scripts i.e.

/js/jqu//%3C![CDATA[var%20Paginator_otherActivities%20=%20new%20Paginator();Paginator_otherActivities.setUrl(;

This would not affect the user experience though, as the website would still display fine. I managed to track down the issue, and re-run it on my local server with the same error happening, which made me think it's not an XSS attack.

I run some tests and it turned out that the problem was that the application was trying to include too many js files - when I reduced that number, the problem stopped occurring.

I was not able to find any information as to, if it's a limit introduced by Trident layout engine, but I remember that IE used to have limits on how many css classes you can use on each page, so maybe thats something to do with Microsoft trying to outsmart everyone.

(Trident/4.0 is what identifies IE 8, even if the User-Agent says IE 7 — which is IE 8 running in compatibility mode.) IE 8’s Lookahead Downloader has a quirk that affects url’s that span any 4096th byte. The resulting url generated is a concatenation of the string immediately preceding the cutoff and the string immediately following it. It appears to treat any single or double quotation marks as delimiters. if you use XHTML, there’s no practical way to avoid getting these 404 errors from IE 8 users.