Google 'Safe Browsing' vs. RESTful authorization Re: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization

[coderman]

On 1/1/06, Tyler Close <tyler.close at gmail.com> wrote:
> ...
> I'm not sure what to do about this kind of attack. Since the browser
> is disclosing all the visited URLs, we have to assume that the
> attacker now has them. Given this knowledge, the attacker has
> everything he needs to mount a cross-site authorization (Confused
> Deputy) attack against a design that relies on HTTP Auth, or session
> cookies. So in addition to destroying the user's privacy, Google has
> also made it difficult to protect the user's authority. Assuming use
> of the 'Safe Browsing' extension and an active attacker, I suspect the
> access control of most applications on the web today could be
> circumvented.

yeah, that sums it up nicely.  for http (not https) you can s/safe
browsing/wireless/g.  the times when you could be sloppy with auth and
get away with it are rapidly ending.


> I think maintaining a secret URL space is crucial to implementing
> access control in a WWW application; whether using capability URLs or
> not.

agreed and this is a reasonable and straightfoward process.  my
personal preference is using a VPN to authenticate users and provide
them access to a private network.  within this private network any
authenticated users may share and collaborate using capability URL's
and so forth.

the moment a user is revoked (by terminating VPN account) they no
longer have any useable capabilities / authority on that private
network.

likewise, disclosure of the capabilities / session ids / http auth
outside of the VPN does not provide an attacker any benefit unless
they can also compromise user authentication to get into the VPN.


> It's sad that people with high level access to critical
> infrastructure don't understand this. Hopefully, the more obvious
> privacy issues will be enough to ensure the 'Safe Browsing' extension
> is not widely deployed. In the past, these privacy concerns have been
> sufficient to derail similar applications.

the problem is this will remain an assumption open to abuse.  how do
you ever really _know_ that such an active attack is not mounted? 
especially over wireless?

VPN's are a reasonable solution and perhaps with enough interest and
developer motivation they can be made much more usable and common than
they currently are.

on this note, the new SSH will support OpenVPN style networks using
tun/tap devices: http://www.securityfocus.com/columnists/375

see also: http://openvpn.net/