On 7-Feb-07, at 10:20 PM, Allen Tom wrote: > Having the OP follow all the redirects returned by the return_to > all the way to the end, and presenting the final url to the user > might seem to be an improvement, however, the evil RP could just be > one of many intermediate servers, which would enable all sorts of > interesting man in the middle type attacks. > > so for instance: > > return_to=go.com/redirect?1,2,http://evilsite.com/ > redirect?....good.isp.com > > If the OP just followed redirects to the end of return_to url, and > then matched it up with the realm, the evil RP could claim to be > absolutely anything that it wants to be, since the evil RP could > just be the redirect server, and the claimed site would just be at > the end. > > evilsite.com would be able grab a positive Auth Response and play > it to good.isp.com in a Stateless type request. EvilSite.com could > even behave nicely when the OP is probing it (perhaps by > recognizing the OP's IP address or User Agent).
This kind of playback is prevented by the return_to URL verification: when goodisp.com verifies the response, it will fail because either the return_to URL doesn't match with what it is expecting, or the signature doesn't match (if evilsite.com modified the return_to in the response). I'm still not sure I understood the full attack vector from beginning to end - what is evilsite.com trying to accomplish by fooling the user/OP with redirects? If you could describe a step-by-step scenario it would greatly help (me at least) to understand what needs to be fixed. Johnny _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
