This is good suggestion for specific consumers. I think we might be able to use it for our internal consumers.
However, it's a challenge to figure out valid referrer for a consumer. Some of our consumers have multiple domains (yes, they all share the same consumer key). Zhihong On Apr 24, 3: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 -~----------~----~----~----~------~----~------~--~---
