Referrer

from Wikipedia, the free encyclopedia

Referrer ( English to refer "reference") refers to the World Wide Web , the website through which the user has come to the current web page or file. In the case of an HTTP request (e.g. a website or an image), the web browser sends the URL of the original website to the web server .

The referrer is an optional part of the HTTP request sent to the web server . Although it is optional, the transmission is preset for all common browsers. Only if the current page is accessed via HTTPS and the page to be accessed is to be transmitted via HTTP, the transmission of the referrer should not take place. If, on the other hand, the page to be accessed is also transmitted via HTTPS, the referrer is transmitted regardless of the host. The transmission of the referrer “behind the back” of the user and the operator is a reason for the leakage of personal data from non-public web-based systems.

The RFC 2616 (Hypertext Transfer Protocol HTTP / 1.1) explains the technical background.

Example of an HTTP request with referrer transfer

Suppose the website http://example.org/referring_page contains a link to this Wikipedia article: http://de.wikipedia.org/wiki/Referrer . If the user selects (clicks on) this link in his web browser , the browser establishes a connection to the web server , which can be reached under the name de.wikipedia.org, and requests the desired page. In this example, the web browser sends the following request using the Hypertext Transfer Protocol (HTTP) syntax :

GET /wiki/Referrer HTTP/1.1
Host: de.wikipedia.org
Referer: http://example.org/referring_page

(For the notation, see below .) The information sent in the request depends on the web browser used and its configuration. The transmission of the referrer can be switched off in any common web browser - with on-board tools or with auxiliary programs.

What happens to the referrer

As a rule, each web server saves one line for each request in a log file , in which the referrer is saved in addition to the IP address , status information and the user agent information, i.e. the web browser used. The web server or its operator can process the information received in any way imaginable. This is mainly used for statistical evaluation; the operator of the website learns which external websites are referring to his pages. However, the web server can also provide a response that is dependent on the referrer. Some images can only be called up if the referrer is on the same website ; The operator wants to prevent other sites from including their own images. However, this procedure can be problematic because the user agent specifies the referrer, is fundamentally voluntary according to the protocol specification and can be suppressed, for example, when a proxy server is used.

Referrer spam is a special form of aggressive marketing and is mainly used by pornographic internet offers. A spam bot leaves a referrer with the URL of the offer on as many websites as possible. If one of these affected websites publishes their referrers, which is particularly popular with blogs , then the spam links to the pornography sites are below them.

Dereferrer

Depending on the web browser, the transmission of the referrer can be switched off. A dereferrer is a service that allows a website to be linked without this website receiving meaningful referrer information, even if the transmission is active in the browser.

A link to the page http://de.wikipedia.org/ via the fictitious dereferrer service http://www.example.org/ could look like this:

http://www.example.org/?http://de.wikipedia.org/

Here the web browser first calls up the example.org page and is then redirected to de.wikipedia.org . For the Wikipedia server it looks as if the link originates from example.org . This is z. Used to hide secret data in the original URL, e.g. B. a session ID in the query string or the mere existence of the referring website. Webmail providers may be mentioned here as an example : When e-mails are displayed in the web interface of the respective provider, any hyperlinks that may be included are replaced by a redirection via a separate dereferrer service. This prevents a malicious website from taking over the webmailing session via the session ID transmitted in the referrer (session hijacking) if a link to the malicious website is clicked in the e-mail displayed. Advantage compared to the browser-side configuration: The user does not need to know how to deactivate the referrer transmission on the browser side, nor can he forget to deactivate it.

When using dereferrers, it must be noted that anchors only work if the # has been replaced by % 23 , otherwise the web browser tries to find the anchor on the dereferrer page. When choosing a dereferrer service, it should also be ensured that the provider is able to collect information about the source and destination pages as well as the time and IP of the user.

The latter can be avoided by adding additional modules for web browsers, so-called add-ons , which generally prevent a referrer from being transmitted and only allow this on request. This is interesting for data protection considerations, among other things, since otherwise there is the possibility of linking the referrers with the user IP addresses.

Referrer spoofing

Under referrer spoofing , a form of URL spoofing , is meant pretending referrers when submitting the HTTP request . The aim of such a procedure is, for example, to gain unauthorized access to a website, as well as to obscure the information which web link one followed. This can be achieved through appropriate extensions for the browser or through proxies (e.g. Proxomitron ) (see also Cross-Site Request Forgery ).

Notation

The correct English spelling is Referrer . However, the original RFC ( RFC 2068 ) accidentally contained the wrong spelling Referer , making this wording the standard within HTTP. In other standards, such as in the DOM , the correct spelling is used (here:) document.referrer.

Web links

Individual evidence

  1. “The Referer [sic] request-header field allows the client to specify […] the address (URI) of the resource from which the Request-URI was obtained […]” RFC 2616 , § 14.36
  2. "Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol." RFC 2616 § 15.1.3
  3. Balachander Krishnamurthy: Privacy leakage on the Internet . (PDF) ietf.org, p. 47 ff. Google also closes data leak in cloud storage . Heise Online.
  4. Daniel Berger: Firefox 59 disguises referrers for better data protection. heise online, February 3, 2018, accessed on February 5, 2018 (German).
  5. Document Object Model (HTML) Level 1 . W3C