Random /sorry.asp requests in my apache logs?

August 15, 2006 12:07 PM

Random /sorry.asp requests in my apache logs?

So... this is kind of weird, but it would appear that a fairly high number of people reaching some of our sites are going to /Sorry.asp after going to the index page. In other words -- they load index.php and then they get redirected by something to /Sorry.asp.

That's weird, because, we're an 100% linux shop. There isn't a single reference to an asp page anywhere in our code.

So... what would redirect people to sorry.asp? The logs don't really show any kind of correlation between sorry.asp's and a particular browser, although all of the machines in question appear to be windows boxes of various kinds.

Is there something within Flash that could do this? (A substantial number of the requests are also looking for crossdomain.xml.)

We cannot seem to reproduce this problem. We've tried various browsers on Windows XP, Windows 2000, Windows 98 to no avail.

posted by ph00dz to Computers & Internet (13 answers total)

The first thing that came to my mind when I saw "sorry.asp" was a custom 404 page. I'd try forcing a 404 to see where it takes me, and then after that (since most of them seem to come from your home page), I'd check all the links on my home page.
posted by Doofus Magoo at 12:11 PM on August 15, 2006

My first thought would be bots searching for some site vulnerability. There's a shopping cart called minicart that uses a file called sorry.asp, which seems like the sort of thing that might attract hacker-y bots.
posted by bcwinters at 12:31 PM on August 15, 2006

My linux server gets occasional probes to what are clearly Windows Server directories and files. Unquestionably it's the result of bots hunting for Windows servers which haven't been patched.
posted by Steven C. Den Beste at 12:41 PM on August 15, 2006

Response by poster: Nah... it's not scanners hitting, it's more like the doofus scenario -- in fact, almost all our pages are actually, secretly 404 pages.

So, you go to /business for instance, and while it does load a page, it's actually a 404 page driven by php to display the right content. A 200 "OK" header is also sent along before the content displays...

The headers we send look like this:
header("HTTP/1.1 200 OK");
header("Status: 200 OK");

We send 'em both to be sure....
posted by ph00dz at 1:01 PM on August 15, 2006

Could you use mod_rewrite to send these requests to a page that would capture the request headers? So you could see if they were actually coming from a link on one of your pages.
posted by bricoleur at 1:01 PM on August 15, 2006

Response by poster: Bricoleur... I'm pretty sure they're coming from our site. Here's an example of the log file:

217.44.XXX.XXX- - [15/Aug/2006:13:13:27 -0700] "GET /Sorry.asp HTTP/1.1" 200 74100 "/var/www/customerdomains/examplesite.com/index.php" "http://examplesite.com/siteAction=business" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6"

So... it goes IP, Date, Response code, # of bytes, file referenced, referrer, browser.
posted by ph00dz at 1:16 PM on August 15, 2006

ph00dz-that's probably the scanner trying to appear like legitimate traffic. It's not that hard to grab your index before trying to exploit Sorry.asp if it's present.
posted by evariste at 1:24 PM on August 15, 2006

Evariste: So the purpose of the initial visit to the index page is (partly) to get the URI so that it can be used to spoof the referrer in the request for sorry.asp? And the point of that is to make the requests look benign?
posted by bricoleur at 1:35 PM on August 15, 2006

Response by poster: Nah... it's something else, evariste. One of our customers purchased traffic, which I think is just popup ads being sent through some kind of frame, and he's the one complaining that people aren't getting to the right place.

(We build template-driven sites for people... they have no control over what the pages are called, just the content on the page.)

Here's what he describes: for some reason, the sorry.asp pages (which don't exist) are breaking the site out of the popup guy's frameset, upsetting the dude who's providing the popups, thus upsetting our customer.
posted by ph00dz at 1:36 PM on August 15, 2006

Now that's weird.
posted by evariste at 2:07 PM on August 15, 2006

Can you link to an example where this happens?
posted by evariste at 2:08 PM on August 15, 2006

ph00dz:

Is this happening with more than one site ("some"), or just the one?

And what happens, as far as you can tell, is: Random visitor clicks on popup on site X (and you have no control over site X, or this popup). Popup directs to your client's site, but within a frame on site X. [Something] redirects the visitor from the index page of the client's site to the non-existent sorry.asp file, and this causes: "breaking the [client] site out of the ... frameset [on site X]."

By "breaking the site out of the popup guy's frameset," do you mean that, in the attempt to open sorry.asp, the visitor's browser opens the client's site in a new window, rather than in the frame on site X? But when you go to site X and click the popup, you can't replicate this (purported) behavior?

Is there any reason to associate the "crossdomain.xml" requests with this problem, other than the fact that there are a substantial number of them and you don't have any other way to account for that?
posted by bricoleur at 3:15 PM on August 15, 2006

Best answer: So... I think we solved it.

And the answer is... well... kind of retarded.

Way back in the day, my boss stole some form validation code and dropped it into place on one of those templated pages that appears all over the place. What he didn't realize is that the code did some kind of weird ass time check, and if it failed, it would forward you on to... you guessed it, sorry.asp.

Of course, I didn't see this, because it was in a separate .js file.

Anyway... thanks a lot for your help.
posted by ph00dz at 3:46 PM on August 15, 2006