The HTTP Referrer check won't work if the Consumer's domain is a social networking site, and the attacker posted the authorization link to the victim's wall.
Allen Manger, James H 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 -~----------~----~----~----~------~----~------~--~---
