Should I verify HTTP Referer in OAuth 2 Callback?

Question

I am successfully able to authenticate Facebook and Google accounts using my Oauth2 servlets. I am using state with a timer and a session cookie to try to verify that it is indeed a legitimate Oauth callback.

Is there any benefit if I also examine the HTTP Referer header to ensure that I was redirected from the provider's OAuth page?
If no benefit, could there be a problem if I also examine the HTTP Referer field?

`HTTP Referer` and such header can be easly simulate. User can send any header. — safarov, Apr 02 '12 at 21:31
BUt i think you can check ip adress to ensure requested source — safarov, Apr 02 '12 at 21:32
No, token from server will be servers ip adress (facebook, twitter etc). But you need always control that ip adress list , they may change — safarov, Apr 03 '12 at 07:52

score 7 · Answer 1 · edited Jun 20 '20 at 09:12

7

No.

I can simulate any headers I want as a malicious attacker. I can make it look like I'm coming from http://cia.fbi.gov.vpn/uber1337h4x. This is obvious and well known.
Any pages coming from HTTPS do not send a refer header as per RFC2616 sec15:

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
Breaks usability as per RFC2616 sec15:

Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent.

In short, you are not given greater security. Your security is not in inspecting a vastly insecure transport protocol, it's in the OAuth layer. You also break usability.

Don't do it.

edited Jun 20 '20 at 09:12

Community

1
1

answered Apr 08 '12 at 22:07

Incognito

20,537
15
80
120

Definitely no greater security. In fact, I didn't mention the word security in my question; just "benefit". I am using state for security and that's good enough. I did use the word "legitimate" which was in light of denial of service attacks. Yes, they can be forged, and your mention of https not having referer makes it unlikely that any mainstream provider will return a referer. Since essentially the content is the same as the other answer, I am more inclined to accept the earlier one. However, you have my upvote regardless. – necromancer Apr 09 '12 at 06:14
@agksmehx what beneficial information could the referer header possibly convey that the presence of state parameter already doesn't? – Esailija Apr 09 '12 at 10:32
@Esailija, please see my own answer. – necromancer Apr 09 '12 at 18:46
The attack's goal is to make the user perform a request with the attacker's token: the attacker sends a URL to the user, and the user goes to the URL. As such, the attacker can *not* control the Referrer header the user sends. The point of checking the Referrer header (in the poster's question) is to prevent an unsuspecting user from associating an attacker's token with his/her account. – Ilya Dec 24 '17 at 01:23

score 6 · Accepted Answer · edited Oct 07 '21 at 07:13

The answer is:

No, you shouldn't use it, and there is NO valuable benefit of doing it.

Authorization Servers are very aware of this also. And here was stated.

From the mailing list of OAuth-WG:

Callback URL pages SHOULD redirect to a trusted page immediately after receiving the authorization code in the URL. This prevents the authorization code from remaining in the browser history, or from inadvertently leaking in a referer header.

If you are worry about CSRF, you SHOULD NOT use the HTTP Referer as a technique to verify the origin of an authorization, that's why the parameter state is (which sound you're using).
If you worry about an specific security concern of the oauth2 protocol, there is a full section inside the draft.
If you worry about other Security Considerations, this is the source.

I suggest you give all your effort implementing all the validations around the param: state.

Edit:

After reading the nuances of the question, you are really answered your own question. The use of cookies (probably HTML5 local storage) for both cases, is the best solution we know so far.

The first nuance is about CSRF and one of the possible countermeasures available is Checking the HTTP Referer header, and this was already addressed in the protocol.

The second nuance, I'm not completly sure, but is probably a case of Extension Grant, this is because it sounds that you may work as an "auth proxy requester", same as SAML oauth2 extension.

hey, thanks for the great answer. could you please look at my own answer and possibly relate your answer to mine? i am not aware of the term Session Fixation (and probably not other users). I kinda feel you are addressing the issues that I am in my own answer, and therefore I would like to accept your answer if you could add just a little bit more of explanation. Thanks! :) — necromancer, Apr 09 '12 at 18:01
i'm granting the bounty since it expires very soon. i hope you'll edit the answer (perhaps merge with mine) so i can also accept it. thanks! — necromancer, Apr 09 '12 at 18:51

score 2 · Answer 3 · edited Oct 07 '21 at 07:15

2

Don't verify the HTTP referer; the "state" parameter (which it sounds you're using) is the approach OAuth 2.0 defines to defend against cross-site request forgery (CSRF) attacks.

You may want to have a look at the new O'Reilly book Getting Started with OAuth 2.0 by Ryan Boyd. It describes this and related security considerations.

edited Oct 07 '21 at 07:15

Community

1
1

answered Apr 04 '12 at 22:00

Will

6,601
3
31
42

yes, i am using state for a very robust check. thanks for the link to the RFC (but the engineer in me is kinda offended to be referred to an O'Reilly book for something as simple as using Oauth just for authentication) – necromancer Apr 05 '12 at 05:38
Apologies; I didn't mean to offend! To be honest I've found the book really valuable, the main reason I recommended it. =) (That and it's new, so not widely known.) I have no affiliation with it; just a good read. – Will Apr 05 '12 at 13:54
Oh, please don't apologize! I was merely being humorous ;) I am glad you found the book valuable and I am sure so will many others benefit from a detailed reading of the excellent book! I am sure it has invaluable and critical information about the complex client, server + browser communication workflows, not to mention devices and apps. With a fine animal on the cover it is also an environment-friendly book. (and for reading this you get your first upvote ;) – necromancer Apr 05 '12 at 18:47

score -1 · Answer 4 · answered Apr 09 '12 at 17:58

Plain security was not a concern of the question because the state parameter is being used.

The main concerns I had in mind were:

Whether it is the same browser that my app sent to Facebook that's coming back to present a candidate token?
Whether the agent (browser-like agent) or agents are repeatedly doing OAuth requests and presenting me with bad OAuth tokens that cause my app to repeatedly contact Facebook with bad tokens leading to potentially adverse treatment by Facebook.

The only possible solution to the first problem is to also set a cookie in addition to using state. referer would help if most providers weren't using https.

The second problem has a nuance. The mis-behaving agents need not be directly controlled by a malicious entity. They may be normal users browsers redirected via some indirect means (a popular hijacked website, social engineering).

Because of the nuance there is a chance that the referer header may not be forged. However, https precludes any meaningful benefit.

Cookies definitely help in the second case also because if you are setting cookies in a POST no third-party website can cause them to be set and you cannot be flooded with bad OAuth responses due to hacked websites redirecting users en masse to OAuth you.

This is not a clear answer (or question) but hopefully this shows the nuances behind the question.

Should I verify HTTP Referer in OAuth 2 Callback?

4 Answers4