<blockquote>
<div> <pre style="font-size: 9pt;"><tt><tt>> 2. The second problem is more serious you can create a specially<br>
> crafted web page to automatically log on to a web site and also add<br>
> that web site to the allow forever trusted site. The only<br>
> requirement is that you have to be logged onto the OpenID server.<br>
<br>
This case I don't understand well. If the provider prevents replay<br>
attacks of trust dialogs with the user (e.g. nonce in form) and requires<br>
the request to come from the user agent with a valid session, how could<br>
a remote site establish such permanent trust?<br>
<br>
<br>
</tt></tt></pre></div>
</blockquote>
<div><pre style="font-size: 9pt;"><tt><tt>I would assume this is a bug in the OP, which is probably accepting a POST without any credentials other<br>
than a session cookie.<br>
<br>
Terry<br>
</tt></tt></pre></div>
<div> <br>
</div>
-----Original Message-----<br>
From: Paul C. Bryan <email@pbryan.net><br>
To: gaz_sec@hushmail.com<br>
Cc: security@openid.net<br>
Sent: Wed, 21 Mar 2007 10:50 am<br>
Subject: Re: [security] MyOpenID<br>
<br>
<div id="AOLMsgPart_0_5774feea-0bd4-4c7d-ba27-e4e5bbbb3e99" style="margin: 0px; font-family: Tahoma,Verdana,Arial,Sans-Serif; font-size: 12px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<pre style="font-size: 9pt;"><tt>On Wed, 2007-03-21 at 13:33 +0000, <a href='javascript:parent.ComposeTo("gaz_sec%40hushmail.com", "");'>gaz_sec@hushmail.com</a> wrote:<br>
<br>
> 1. First of all if you sign into a OpenID server in this case<br>
> (MyOpenID.com) then logon to an OpenID enabled site like<br>
> (<a href="http://ficlets.com/" target="_blank">http://ficlets.com/</a>) then sign out of the OpenID enabled site. It<br>
> is possible to log them back onto the site from any remote web site.<br>
<br>
Presumably, this is true only:<br>
<br>
a) as long as I am still logged into the OpenID provider,<br>
b) the remote site knows the OpenID login URL of the client site.<br>
<br>
Correct? The risk here is that I would have a session with the client<br>
site without explicitly asking for it?<br>
<br>
> 2. The second problem is more serious you can create a specially<br>
> crafted web page to automatically log on to a web site and also add<br>
> that web site to the allow forever trusted site. The only<br>
> requirement is that you have to be logged onto the OpenID server.<br>
<br>
This case I don't understand well. If the provider prevents replay<br>
attacks of trust dialogs with the user (e.g. nonce in form) and requires<br>
the request to come from the user agent with a valid session, how could<br>
a remote site establish such permanent trust?<br>
<br>
> Both cases can be prevented if the OpenID specification requires<br>
> authorisation regardless of a cached token.<br>
<br>
I think the second case already requires authorization by the user.<br>
Properly developed providers should ask for the user to grant trust to<br>
the consumer site, and not be susceptible to crafted requests to bypass<br>
user dialog.<br>
<br>
Paul<br>
<br>
_______________________________________________<br>
security mailing list<br>
<a href='javascript:parent.ComposeTo("security%40openid.net", "");'>security@openid.net</a>
<a href="http://openid.net/mailman/listinfo/security" target="_blank">http://openid.net/mailman/listinfo/security</a>
</tt></pre>
</div>
<!-- end of AOLMsgPart_0_5774feea-0bd4-4c7d-ba27-e4e5bbbb3e99 -->
<div class="AOLPromoFooter">
<hr style="margin-top:10px;" />
AOL now offers free email to everyone. Find out more about what's free from AOL at <a href="http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir=http://www.aol.com" target="_blank"><b>AOL.com</b></a>.<br />
</div>