Hi Allen I just realized that although you can use either a POST or a GET with OpenID 2.0, our libraries use a POST. Would I be correct that the redirect services would NOT redirect a POST? If so, then an OP can protect against the attack by using POST instead of GET.
-- Dick On 7-Feb-07, at 10:20 PM, Allen Tom wrote: > Hi Johnny, > > 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). > > At any rate, when serving an Auth Request, the OP only knows the > return_to url, so there should be a way in the protocol for the OP > to somehow verify the return_to url. Instead of performing the > verification on every request, the OP and the RP could register > themselves and do whatever verification is required during the > association process. > > One possibility would be for the RP to pass its return_to url when > making the Association Request, and the OP can probe it before > returning the assoc_handle and secret. It might be sufficient for > the OP to just bind that assoc_handle to the return_to url, so one > possible implementation would be for the OP to encrypt details > about the association into the assoc_handle, so that the given > assoc_handle can only be used for that return_to. However, it might > be necessary for the OP to verify that the RP owning the return_to > URL actually initiated the Association request, so perhaps an > additional round trip would be needed after the association is > initiated. > > Allen > > > > Johnny Bufu wrote: >> >> Another simpler (though maybe not as solid) solution would be for >> the OP to perform a fetch on the return_to URL and present the >> final URL - after following the redirects - in the message to the >> user. So the user will actually see that he's about to go to >> http://www.jyte.com, for: >> >> return_to=http://www.aol.com/ams/clickThruRedirect.adp? >> 1,2,http://www.jyte.com >> >> If the rogue RP further tries to hide itself by setting >> realm=*.aol.com, the realm verification performed by the OP will >> fail (again, using the return_to URL after following redirects). >> >> >> Johnny >> >> >> > > _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
