5

Is it a problem when URLs in a web application redirect to the URL specified in the Referer header?

It's not an open redirect like any of the /whatever?url=evil.com examples I've seen, that can be exploited by having users click on a link to the legitimate application (or at least not as straightforward). This answer seems to indicate (toward the end) that referrers cannot be arbitrarily forged -- at least not without help from the user, in which case the redirect is probably not a problem.

MSA-15-0019 (related blog post) seems to be what I'm asking about, but it's not explained why it is a problem. As far as I understand it's more likely that the addition of the Referer URL to the button shown on the page resulted in a potential reflected XSS vulnerability.

Note that this is not about possible CSRF issues in any URL that doesn't show a response but instead is likely to act on input in some way; but specifically about the Location header redirect to the Referer URL. Is that a problem? If so, how/why?

If it matters, the application is written in Java, and the code I'm concerned about is basically equivalent to myHttpServletResponse.sendRedirect(myHttpServletRequest.getHeader("Referer")). Assuming nothing else of interest happens on the server as a result of this request, how can it be a problem?

abraham
  • 103
  • 1
  • 6
mwl
  • 51
  • 1
  • 3

3 Answers3

3

You're creating an open redirect vulnerability but no XSS flaw. However, I can't think of a legitimate use case to issue a redirect back to the referring page in the first place. At very least you risk creating a redirect loop.

Note that in other contexts it can be dangerous to allow user-controlled URLs, especially because an attacker might take advantage of pseudo schemes such as data: and javascript: to achieve XSS. E.g., printing <a href="[referrer]">Click me</a> is vulnerable even if you escape quotes and brackets.

But you don't risk that a pseudo scheme ends up in your Referer header because browsers never send them. Also, a header such as Location: javascript:alert(1) is considered invalid and has no effect in any major browser.

MDN also hints at that behavior but is less verbose:

A Referer header is not sent by browsers if:

  • the referring resource is a local "file" or "data" URI,

  • an unsecured HTTP request is used and the referring page was received with a secure protocol (HTTPS).

(Source)

Community
  • 1
Arminius
  • 43,922
  • 13
  • 140
  • 136
  • I updated the question with two references that may be relevant, I'd appreciate if you could take another look. Thanks! – mwl Aug 10 '17 at 14:58
1

Http referer headers can be spoofed. You asked if it was unsafe, but then excluded one of the main vulns that would make it unsafe so I'm not exactly clear on what you would like to know but from my understanding the short term answer to your question is yes.This link is also related to your answer, although i'm not sure how the app being coded in java figures into the equation when comparing it to a web application https://stackoverflow.com/questions/3104647/how-to-spoof-http-referer

Anonymous
  • 11
  • 1
  • You are correct in that the referer header can be spoofed, but perhaps that's not the main question? OP specifically mentioned "not an open redirect" (and ruled out other worries as well). If there is sufficient verification & validation of the referer, what evil could befall the application? – Sas3 Aug 10 '17 at 05:31
  • When you write they can be spoofed, who does that? In your link, it seems to be the user who'd access the URL just to get my web application to redirect them somewhere else rather than some third party attacking the user or me. If that's wrong, please explain -- maybe there's a problem here after all. – mwl Aug 10 '17 at 08:33
  • Perhaps this is a better explanation of how open redirects can be used against you.. In an environment where there is are other nodes on the network the open redirect can be manipulated to get information about your network that you may not want to expose from the article : "A good demonstration of an SSRF vulnerability is to reveal a system that is not accessible over the internet." https://www.hackerone.com/blog-How-To-Server-Side-Request-Forgery- – Anonymous Aug 10 '17 at 22:12
0

The only vulnerability will be a self open redirect, which have a really low impact.

You are right you can't spoof a referer with javascript or Ajax, the browser will overwrite the change. So it is not possible to open redirect a victim to another website.

Florian
  • 382
  • 2
  • 10