HTTP Referer Spoofing, don't get confused, don't worry, Block or Avoid

HTTP Referer?
It's an optional HTTP Request Header which can be set to URI to inform the WebServer the source URI which led the client to current URI.

Analytics Benefit:
It's useful for Web content publishers for analysis sake as per which are the web portals that are attractive more visitors to that URI.

Security Benefit:
It has also been seen to be used as an extra layer of check by WebApps to confirm if the requested URI has been accessed via proper channels and respond accordingly.

HTTP Referer Spoofing ?

As other popular spoofing attack this doesn't involve attacker trying to hide their identity.

Here attacker will actually retain and embed their identity into the HTTP Request made to your WebServer. The spoofing in this case happens of is forging a custom HTTP Request with a fake HTTP Referer header added to make the WebServer believe some user is visiting their service by getting the link from attacker's injected referrer URI.

For past sometime I've been viewing a flood of spoofed HTTP referers on the user statistics page.

Here is a screenshot of web statistics page from one of my other blog for span of a month on one of the date-ranges. These are top-chart statistics for reported traffic referrals.

As you can notice... among top 10 referring URLs 5 are spammers, namely

1. http://r-e-f-e-r-e-r.com/(target-specific-uri)
2. http://adfoc.us/(some-numeric-id)
3. http://www.googlecorrection.com/
4. http://justforlaughsgags.tv
5. http://smarts-loans.com/

Threat ?

There are potential 2 types of threats which arise from it:

1. Opening an Infected Website
   Most of these referer spoofing happens to trick the website admin/publisher into thinking a new/dis-respected portal is referring to their content. In some of those cases, out of curosity the site admin/publisher tend to visit the URI mentioned as referer.
   Now if the URI leads to an infected portal, the visit is as safe as the attempt to click on an untrusted link. It might be just an advertisement portal or a generously malware spreading service.
   
2. Indirectly triggering WebApp Vulnerability
   This is more of an indirect attack where the site-admin/publisher doesn't need to visit the referer URI but just view it on a weak web-application responsible to show the analytics.
   Now, since anything can be injected into the HTTP Referer Header. Any web-view dealing with the rendering of it or any backend application/database dealing with processing it can fall pray to a cleverly designed referer entry. The attacks possible here have a wide range and depend on the components involved at site-admin/publisher end to analyze it.

Solution ?

Don't be curious of unknown referers.

If building something yourself to analyze these, make sure your own code is safe enough.