It's a good idea. The problem is that it's trivial to fake a referrer header. All you need to do is tinyurl a link (to avoid suspicion) that redirects you to the authorization url via a proxy that adds the expected referrer header.
On Apr 24, 1:25 am, "Manger, James H" <[email protected]> wrote: > A (temporary) fix might be for Service Providers to check the HTTP Referer > request header when Users arrives at the authorization URI. > > If the Referer “matches” the application associated with the request token > then the User has not come from an Attacker’s link. > > A Referer check at the SP requires no change to consumer applications. > > For desktop applications, the SP could check that the Referer field is absent > (though I believe this can be readily spoofed, eg redirect the user through a > FTP URI). > > P.S. I don’t think an open redirector at the application’s web site defeats > the Referer check as the Referer field still lists the original URI, not the > URI that issued the redirect (at least in my quick test with Firefox 3). > > James Manger > [email protected]<mailto:[email protected]> > Identity and security team — Chief Technology Office — Telstra --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
