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

Question

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 effected 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 dispalyed (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"):

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 the 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]; --> -->-->function Set_Cookie( name, value, expires, path, domain, secure ) <!--/ 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 )<!--expires = expires * 1000 * 60 * 60 * 24;-->*/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.

Answer 1

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).

Answer 2

We're having the same problem. For us, the user agent that is reported for these problems is always MSIE 8.0. We're seeing the same problem as you, HTML and javascript in links. We're also seeing a similar but even more strange behavior - misspellings in URLs for javascript that is referenced from our pages. We have the following script-tag on our pages:

<script type="text/javascript" src="/scripts/jquery.cookie.min.js"></script>

The error we're seeing in our logs is a 404 error for "jquery.ckoie.min.js" or "jquery.ckooie.min.js" or other variations where the word "cookie" is misspelled. We're referencing other scripts from the same pages but the errors always seem related to this particular reference.

This seems like a very strange attempt at a XSS attack to me, but I'm no expert.

We're also using javascript, but I find it unlikely that it should cause these types of errors only in IE8. It is not impossible, but unlikely. We can't reproduce the problem no matter how we try.

We're having approximately 35000 visitors each day (don't know how many pageviews, but I'm guessing at least 100.000). We're seeing this problem maybe 30 times each day, which means that a very small percentage of our visitors experience this. It is annoying anyway, especially since we don't know what the cause is.

Did you ever find a solution (or a cause) for this problem?

Answer 3

We are experiencing this same issue, just today we found a couple if IE6/Win98 users getting the same problem. but for every one instance its been IE8.

Does every body experiencing this bug all have a conditional IE CSS inclusion? < ! - - IF IE .....

I tried moving our conditional include to see if i could change the errors, doesn't seem to have worked. Any more updates on this topic?

Answer 4

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.