Facebook Referer Trapped

Is uiserver a common referer situation?

[dstiles]

A couple of days ago we blocked access to a customer who had just clicked on a newly-made facebook link which he'd created in the "work info section" (his description) of his facebook details.

The reason for blocking given in our security log was "Bad Referer".

The access was trapped on the part-word "iserver" - the full word was uiserver.php and was part of the facebook referer.

I've never seen that term before (at least, not in past year's security logs). The term "iserver" has several uses and definitions but includes a couple that are dangerous to web sites - eg they include scraping facilities.

It looks as if uiserver.php is a part of facebook's apps system but I can't be certain. Does anyone know anything about this?

There was also a reference in the Referer to IP 174.143.153.nn (shown in the Referer below as [IP]) which is in a Rackspace Cloud. One reason I can imagine for its inclusion is that someone using the Rackspace Cloud as a robot / interrogation / spy source was tracing the link (it has the parameter name "cancel_url").

Full Referer (broken into lines, URLs broken with spaces):

[www....] facebook. com/connect/uiserver. php
?app_id=181091351917024&next=http%3A%2F%2Fapps. facebook. com%2Fgettopwords%2F&display=page
&cancel_url=http%3A%2F%2F[IP]%2Ftopwords%2F%3Ftype%3Ddiscovery
&locale=en_US&perms=read_stream&return_session=1&session_version=3
&fbconnect=0&canvas=1&legacy_return=1&method=permissions.request

I do not want to lose iserver from the referer rejection list; to add uiserver as an over-ride would be annoyingly troublesome. :(

Am I likely to encounter this again? I haven't before and I know others of my clients use facebook.

[wilderness]

nearly 9,000 results on google [google.com]

[dstiles]

But none of those I found were much use. :(

[Pfui]

I haven't noticed uiserver, sorry. (But on a possibly related note...)

What I have noticed is an increasing number of hijacked graphics from Facebook users doing -- well, I'm not sure what they're doing, or where, or how. When I login and try to trackback, search, manually 'make' the links, etc., I get dead-ends.

For example, here are hijacked-graphics refs as-is, all w/ different Hosts:

http://www.facebook.com/home.php?
http://www.facebook.com/
http://www.facebook.com/?ref=home

There's no way any of our graphics would appear on FB's home page. So what's the deal with the fake refs? FWIW, here are still more dead-end ref formats:

http://www.facebook.com/photo.php?fbid=[numbers]&set=a.[numbers].[numbers].[numbers]&pid=[numbers]&id=[numbers]

http://www.facebook.com/permalink.php?story_fbid=[numbers]&id=[numbers]&ref=notif&notif_t=wall

http://www.facebook.com/note.php?created&&note_id=[numbers]

http://www.facebook.com/?sk=messages&tid=[numbers]

(I don't mean to hijack the thread w/ FB hijacking graphics; the tie-in is iffy refs:)

[g1smd]

Some of those may be when a user sends a private message or posts to a wall, a message containing a link to your site, and the FB system pulls a graphic from your site to show with it. Additionally, similar action when the message is viewed. Since some of this is done with AJAX and since the display URLs include fragment IDs (not used for their original purpose), it is likely the URL of the referring page (as seen by your server) is not the full URL for the actual FB page the thumbnail is displayed on, the URL having been truncated at the # symbol.

[wilderness]

I've not seen any FB links in raw logs that would arrive on the active page that is linking to the image.
Rather the link is a sort of FB landing page.

Has anybody seen otherwise?

[Pfui]

@g1smd: Thank you for the explanation. I basically have placeholder-type 'pages' on FB for domains and am unfamiliar with its machinations.

It's unfortunate FB's refs aren't back-trackable because graphics are repeatedly, and impermissibly, hijacked/hotlinked. But w/o accurate refs, you can't check on infringement, let alone serve notice under the DMCA.

Thank goodness for mod_rewrite's anti-hotlinking defense!