Spammers Hijack Redirect Scripts With Their URLs

[Rufal]

Hi,

Not sure if this is the correct group, but I just found out a nasty thing today.
I was going through Google's Webmaster tools and going through the Content Analysis pages and saw approx 600 pages without a title tag.

Took a look and found out that a site has been linking a redirect code I have on my site. So all the URL's looked something like
http://www.example.com/redirect?id=53763&url=http://example.com/tds/go/sid/3/q/

After the 3/q/ follows a varied list of adult related keywords.

I went and immediately went and plugged that particular hole. But then when searching for that domain using inurl: I found a huge list of professional (non-adult) websites being hijacked in the same manner.

Taking a look at quantcast, they seem to have started in mid december and gotten a huge turnover using this method. Ranked ~ 5000

Take a good look at all you redirect code and make sure its locked tight,.

Regards

[edited by: tedster at 4:34 pm (utc) on Jan. 15, 2009]
[edit reason] switch to example.com [/edit]

[tedster]

Spammers have been using "open" redirect scripts for a while now - but I haven't recently seen bad ranking effects for the site whose script they use. I's mostly a technique that tries to help them, not to hurt you. If you do use a redirect script for external links, it still is a good idea to lock it down.

[smallcompany]

How do you know if the redirect script is opened or locked down?

Thanks

[tedster]

A "locked down" script will return a 404 for any url in the query string that is not one of your outgoing links.

[smallcompany]

I see those redirect attempts generating 404s, not via my script but rather just trying to use some form of myurl?URL=theirurl

If they try to use my redirect script though, any request for non-existing link will redirect to the page I set as default.

I guess I'm doing fine.

[Marcia]

How can this be guarded against?

[g1smd]

Guarded for whom? The site containing the redirect script, or the site being pointed at by the redirect?

[Rufal]

Best way to guard against it is to either not pass a whole url as a parameter to the redirect code (just an id for a table lookup)
or
Somehow make sure with a table lookup that the url passed is indeed something your site intended to redirect to.

The problem is with code that takes in the whole url as a parameter and no ID's. (or ID's + URL but does not verify the combination)

Making it very easy for external sites to link to themselves by linking to yours.

If you do have a redirect code that takes an URL as a parameter. Simply copy the redirect link (any link) and try replacing the external url with anything else (webmasterworld.com for example), if you get a resp 200 and get redirected, then you have this particular security hole open.

[g1smd]

*** if you get a resp 200 and get redirected... ***

200?

You shouldn't get 200 at all.

It would be 301, 302, or 307.

All of those would be bad news.

For non-valid values it should return 404, or better yet return 403.

[incrediBILL]

This reminds me of a post I made about 6 months ago (with a patch) about every webmail account on the Plesk 7 control panel that uses Horde has this very vulnerability.

[webmasterworld.com...]

The problem is resolved in Plesk 8 and above since the redirect script no longer appears to be in use.

Sometimes publicizing these products as vulnerable, unless it's your own code, will get people to correct the problems.