[security] MyOpenID

[thayes0993 at aol.com]

> 2. The second problem is more serious you can create a specially
> crafted web page to automatically log on to a web site and also add
> that web site to the allow forever trusted site. The only
> requirement is that you have to be logged onto the OpenID server.

This case I don't understand well. If the provider prevents replay
attacks of trust dialogs with the user (e.g. nonce in form) and requires
the request to come from the user agent with a valid session, how could
a remote site establish such permanent trust?







I would assume this is a bug in the OP, which is probably accepting a POST without any credentials other
than a session cookie.

Terry



 

-----Original Message-----
From: Paul C. Bryan <email at pbryan.net>
To: gaz_sec at hushmail.com
Cc: security at openid.net
Sent: Wed, 21 Mar 2007 10:50 am
Subject: Re: [security] MyOpenID

 
 
On Wed, 2007-03-21 at 13:33 +0000, gaz_sec at hushmail.com wrote:

> 1. First of all if you sign into a OpenID server in this case
> (MyOpenID.com) then logon to an OpenID enabled site like
> (http://ficlets.com/) then sign out of the OpenID enabled site. It
> is possible to log them back onto the site from any remote web site.

Presumably, this is true only:

a) as long as I am still logged into the OpenID provider,
b) the remote site knows the OpenID login URL of the client site.

Correct? The risk here is that I would have a session with the client
site without explicitly asking for it?

> 2. The second problem is more serious you can create a specially
> crafted web page to automatically log on to a web site and also add
> that web site to the allow forever trusted site. The only
> requirement is that you have to be logged onto the OpenID server.

This case I don't understand well. If the provider prevents replay
attacks of trust dialogs with the user (e.g. nonce in form) and requires
the request to come from the user agent with a valid session, how could
a remote site establish such permanent trust?

> Both cases can be prevented if the OpenID specification requires
> authorisation regardless of a cached token.

I think the second case already requires authorization by the user.
Properly developed providers should ask for the user to grant trust to
the consumer site, and not be susceptible to crafted requests to bypass
user dialog.

Paul

_______________________________________________
security mailing list
security at openid.net http://openid.net/mailman/listinfo/security 
 
  
________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20070321/daca3dd4/attachment-0002.htm>