3

After reading the question about referrer and the answer of @D.W., I did not understand the following part:

XSS defense. Strict referer checking can make reflective XSS attacks harder, because other sites can't trick the victim's browser into visiting the vulnerable URL.

I did not get it. So if on my site I implemented the referrer checker and it redirects me to a specific page if I am coming from anything else outside of my site, how does it helps me with XSS attacks.

May be I misunderstood something, and also sorry if it is obvious for someone.

Salvador Dali
  • 1,745
  • 1
  • 19
  • 32

5 Answers5

4

Many of the cross-site request forgery countermeasures will make reflective XSS more difficult to exploit but not impossible. It may still be possible to exploit one of these flaws with clickjacking or other methods. Clickjacking and other vectors should also be fixed, but its not a simple or foolproof solution when compared to input validation/sanitation.

There are problems with the referer header as a security measure. If the request originates from an HTTPS page going to an HTTP page then Referer will be absent. The origin header was created to address this issue. An OWASP A10: Unvalidated redirects and forwards could also be used to bypass a referer check.

rook
  • 47,004
  • 10
  • 94
  • 182
  • 4
    +1. Either you block null-referer and break a number of legitimate cases, or you don't block it and you can be hit by the various means of referrer-hiding. Summary: Referer-checking is not a good defence against XSS (or really, on its own, anything much). – bobince Nov 23 '12 at 10:31
3

Referer protection isn't fool proof if you have other vulnerabilities on the site.

If you have an open redirect on your site (or even one with checks to see if the link is internal), we can place the vulnerable URL into this redirect, and the users gets sent to the vulnerable page with a correct (internal) referer.

fin1te
  • 391
  • 1
  • 3
2

Referer checking will help with some classes of XSS - reflected XSS and DOM XSS but will have no effect on stored XSS.

Vitaly Osipov
  • 863
  • 6
  • 14
  • ‘Can help’, not ‘will help’. The client doesn’t have to send any *Referer* at all. – Gumbo Nov 23 '12 at 18:49
  • @Gumbo, read the original context, where it referred to *strict* referer checking (which means that if the request has no Referer header, the request is denied). P.S. I agree that even then, it's a 'can help', not 'will help'. – D.W. Nov 24 '12 at 01:48
  • @D.W., Why do you say 'can help'? It will help *some* kinds of XSS attacks, not "can help". – Pacerier Jun 08 '14 at 14:05
  • @Pacerier, because it depends on other factors. There may still be ways to exploit some XSS vulnerabilities, even if strict Referer checking is in place. (e.g., if there's a redirector on the same site; if user content is allowed on the site; if loose Referer checking is used rather than strict Referer header). Also there is no guarantee that Referer checking will help with DOM-based XSS, contrary to what this answer might tend to suggest. – D.W. Jun 08 '14 at 21:17
  • @D.W., Yes I undestand that point. So it *will* help some kinds of XSS attacks, and it will not help other kinds of XSS attacks. – Pacerier Jun 09 '14 at 12:48
  • @Pacerier, this is the difference in talking about attacks vs. vulnerabilities. I'm talking about XSS vulnerabilities. For a single XSS vulnerability, there might be multiple ways to exploit it, some of which will be stopped by strict Referer checking and some of which will not. – D.W. Jun 09 '14 at 19:53
  • @D.W. Would you be able to share an example of a reflected XSS that will still be exploitable with Referer checking? – Vitaly Osipov Jul 01 '14 at 05:49
2

Note: I'll make an answer since the current accepted answer didn't actually answer the question.

Reflective XSS basically involves tricking a victim to click a link to your website:

  • An attacker can email a victim the link your-website.com/query?<script>alert('hacked!');evil();</script>

  • evil.com can link to your-website.com/query?<script>alert('hacked!');evil();</script> and trick a victim into clicking it.

If your website does strict referrer checking, it will reject requests like those above.

Of course, if your website allows users to post links, then an attacker can post the link your-website.com/query?<script>alert('hacked!');evil();</script> under your website. Strict referrer checking will then fail, since the referrer is your own website.

Pacerier
  • 3,263
  • 6
  • 34
  • 61
0

I think, it's actually quite simple: since the page, you are being redirected to, only accepts referrers from your own site (that is: domain), XSS is harder (only one site allowed).

But that would have the downside that you cannot access that page from the outside, only the referrer - making readability of url's for example quite complicated (but the downsides are quite well explained by D.W.).

an example: say you have a blog. direct access to blog/post/id/12 isn't allowed (referrer checker), but access to the perma-link of the post (blog/post/perm/12) is allowed. The perma-link only serves you the referrer, the referrer redirects to the post (blog/post/id/12) - et voila!

alex
  • 101