Talk:Referer spoofing

Solution

Since this is a computer security attack, I would think that it would be ethical to address a solution to this attack.

There is no way to get authentic referer information. Superm401 - Talk 18:07, 19 January 2007 (UTC)[reply]

Perhaps not, but there are still some things that can be done. For example, I disallow GET and HEAD requests where the request and referrer fields are the same - which logically should never happen as pages that refer to themselves do not cause browsers to (re-)fetch them upon clicking on such links. However, certain malicious spiders do present such bogus requests. I also check for off-server hotlinking. 71.106.211.51 (talk) 02:55, 5 October 2011 (UTC)[reply]

External links

Someone needs to check those links.

I'm uneasy about this; Wikipedia shouldn't be seen as abetting fraud. Rhinoracer 15:03, 28 September 2007 (UTC)[reply]

I wouldn't think of it as abetting fraud, since there are many legitimate reasons why people can use spoofers. Regardless, I'd think the links are advertising, so have removed them for the time being. —Preceding unsigned comment added by 82.36.229.11 (talk) 18:57, 12 November 2007 (UTC)[reply]

Cross-site request forgery

Currently this page is concerned with clients who intentionally spoof their own referrer. It should also discuss how and when an attacker performing cross-site request forgery can cause the victim to misrepresent their referrer (in order to circumvent referrer-based CSRF countermeasures), and how users can ensure that this isn't possible. —Saric (Talk) 16:04, 13 January 2012 (UTC)[reply]

Now there's a sentence about unintentional spoofing as well, but now it sounds like a third party can set the Referer header to arbitrary values. This is simply not true. But in some cases the Referer header is missing, e.g. if the source "web page" is a local file or a link in a local application, e.g. an e-mail client. (However, there used to be a bug in old versions of Flash that allowed any HTTP header to be set to any value, but the very same version also allowed remote code execution, which would have allowed CSRF tokens, session ids, or even (soft) client certificates to be read). --Crashie (talk) 12:27, 20 October 2016 (UTC)[reply]

Reverted move

See Talk:HTTP_referer#Reverted_move. Superm401 - Talk 01:36, 23 March 2012 (UTC)[reply]

Spelling of "refer(r)er"

The current statement is not persuasive, as there is no citation and a SET does not provide an overwhelming imbalance in results. To be sure, "referer spoofing" is common, but hardly "canonical" especially when WP and WP-influenced hits are disregarded (required, or else you get a circular argument). —DIV (120.18.112.31 (talk) 14:06, 27 June 2017 (UTC))[reply]

The English word is "referrer"—the technical term "referer" is a typo, acknowledged as a mistake by the author, as I recall. There have been quite a lot of arguments about it at Talk:HTTP referer. References from there should be used here. "Canonical" as used here just means the standard way things are done, because the original RFC contained the typo. Johnuniq (talk) 22:42, 27 June 2017 (UTC)[reply]