1

As part of a project with a partner, we are required to provide single-sign-on service on our app. Basically, people will log in through our partner's website, then they are redirected to ours. The redirected request will have the user's data in the HTTP header fields.

Here's where it gets "iffy". The process of authenticating if this request is valid or not is dependent on the value of the HTTP Referer field. Our partner tells us to check this field to see that the source is a legitimate one.

Now I know (and I'm glad to be proven wrong) that this field is easy enough to forge, and since no other method of authentication is given to us, a malicious user could easily construct a false HTTP request and gain access to our web app.

I'm a programmer first, and admittedly know very little about the intricacies of HTTP. So are my concerns real? Would using SSL (somehow) void this concern?

System Down
  • 6,192
  • 1
  • 30
  • 34

3 Answers3

2

Remember that rule number one is never trust client input. Like any other client input, the Referer header is trivial to forge. SSL does nothing for you because you still rely on client input. Also, note that browsers SHOULD NOT send Referer to http pages when referred by https pages.

Additionally, consider that many privacy-conscious people and proxies (that individuals may not have any control over) might strip Referer headers from their requests, breaking your scheme.

To do this properly, you need to use something like OAuth or OpenID, where the protocols have been designed to be secure.

josh3736
  • 139,160
  • 33
  • 216
  • 263
  • It's up to the Web client, as there's no specific rule in the RFCs. Either way, there's no way to guarantee any behaviour. – cmbuckley Mar 29 '12 at 22:27
  • Sorry, I meant to say that `Referer` isn't sent https->http -- which, @cbuckley, [is in the spec](http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3). – josh3736 Mar 29 '12 at 22:32
  • Indeed — I was attempting to agree with you on the generalisation. Sorry for my poor wording :-) – cmbuckley Mar 29 '12 at 22:36
  • ..it seems we're all having issues with wording! – josh3736 Mar 29 '12 at 22:37
  • +1 "never trust client input". Just wanted to make sure I wasn't being paranoid. – System Down Mar 29 '12 at 22:56
  • Yes, silly wording -- I gave a +1, bonus points for adding links to OAuth/OpenID overviews/references. –  Mar 29 '12 at 23:37
2

The HTTP Referrer header is unreliable: depending on the browser used it may not be sent.

Does http-equiv="refresh" keep referrer info and metadata?

Community
  • 1
  • 1
Dana Benson
  • 966
  • 7
  • 16
1

Yes - It is forgeable.

No - A client can just as easily send a (fake) HTTPS request as a (fake) HTTP request. The only difference is the connection is encrypted. It says nothing about the data transmitted.

That being said, it is another precaution that can be used. It should not be relied upon for security, however.

I would look at Microsoft Federation -- it's likely overkill, but it shows one way to implement SSO securely.