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

Tyler Close tyler.close at gmail.com
Sun Jan 1 22:54:02 UTC 2006


Hi Gordon,

Thanks for sending this link to the Google 'Safe Browsing' extension.
The irony is astounding.

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.

For an example cross-site authorization attack, see end of the email at:

http://groups.yahoo.com/group/rest-discuss/message/5249

I think maintaining a secret URL space is crucial to implementing
access control in a WWW application; whether using capability URLs or
not. 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.

Tyler

On 12/29/05, Gordon Mohr <gojomo at bitzi.com> wrote:
> I like Tyler's notion of SSL-passed 'capability URLs', and had
> occasion to think about them again when reading the following:
>
>    Two Things That Bother Me About Google's New Firefox Extension
>    http://www.oreillynet.com/pub/wlg/8760
>
>    "1) Every request is transmitted to Google over HTTP, i.e. in
>    clear-text. This is not good. Here is why: Consider a web
>    application that uses SSL to encrypt the session. If this web
>    application were to submit private information about you via a
>    GET request (i.e in the URL, such as a credit card number),
>    this will now be transmitted to
>    http://www.google.com/safebrowsing/lookup in clear-text, allowing
>    someone on your network segment, or any router in between yourself
>    and google.com to sniff the information off the wire."
>
> Asking a trusted third party their opinion of an URL seems a
> reasonable anti-phishing measure. But if that "trusted" third
> party is careless in its handling of HTTPS URLs, as it
> appears Google has been in this design, the prerequisite
> URL secrecy required for capability URLs will be often and
> casually violated.
>
> Of course, any security measure can be thwarted with sufficient
> carelessness, and in this case the onus should be on Google to
> fix this oversight, and respect the privacy of HTTPS URL requests.
>
> But it's been 2 weeks since this problem was highlighted, and
> it remains unfixed and mostly undiscussed. That suggests to me
> that people's expectations of HTTPS URL secrecy -- and of the
> standards that toolbar/extension makers like Google should be
> held to in protecting user secrets -- are pretty low. Perhaps
> so low that capability URLs would only be usable by the
> hyper-conscientious, who generally do fine under any system.
>
> - Gordon
>
> Tyler Close wrote:
> > Hi Antoine,
> >
> > On 9/28/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >>> On 9/28/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >>>> I'm curious as to how "capability URLs" can't be stolen and re-used by a
> >>>> malicious piece of Javascript like other URLs can.
> >>> Simply because a capability URL is unguessable.
> >> It is permanent too,
> >
> > No, the lifetime of the URL is up to the application designer. Using
> > capability URLs does not place any duration restrictions on how you
> > define the lifetime of your resources.
> >
> >> And you have to keep this URL somewhere... Given that it's full of
> >> random ascii garbage, you can't keep it in your head (contrast this with
> >> a properly chosen password), and you don't want to copy it by hand
> >> either. So it /will/ end up in electronic clickable form somewhere: for
> >> example in your bookmarks.
> >
> > I think keeping capability URLs in your bookmarks is a perfectly
> > sensible thing to do, providing you then protect your bookmarks. I run
> > OS X, so my entire filesystem is encrypted, including my bookmarks
> > file.
> >
> >> >From your own explanation on the REST mailing-list : « The user just
> >> *clicks on hyperlinks*, without ever needing to be aware of the resource
> >> password. » Those hyperlinks have to be somewhere...
> >>
> >> (and of course, this totally mandates HTTPS, which is impossible for
> >> most Web sites for reasons I already explained)
> >
> > This argument is a little out of date. You can get affordable HTTPS
> > hosting from providers like GoDaddy and 1and1. Even before the advent
> > of shared hosting for HTTPS, colocation was already an affordable
> > option and likely required anyways in order to get the performance
> > characteristics that you want for your web application. For very small
> > scale projects, running Apache on your home machine with a dyndns
> > hostname and a 7.99 SSL certificate is also doable.
> >
> >> As a mix proposal, it would be more interesting if a new URL was
> >> generated everytime the user identifies (with login/password). More
> >> interesting again, it could be generated client side in Javascript using
> >> a formula like "HASH(HASH(password) + challenge)" where the challenge is
> >> a temporary value generated by the server for this very session (thus
> >> with an expiration time). Which means:
> >> - the URL is temporary (it expires with the challenge)
> >> - this URL does not need to be recorded anywhere on the client since
> >> it's generated at every new login
> >> - in plain non-encrypted HTTPS, the data which goes over the wire only
> >> gives temporary access to the resource
> >
> > When I attend DefCon, I am always amazed that people are surprised by
> > the Wall of Sheep, people who know that network snooping is possible.
> > I guess you just have to experience the efficiency of live network
> > snooping in order to truly appreciate it.
> >
> > With the rise of ubiquitous WiFi, passing secrets, even temporary
> > ones, over the network in the clear is asking for trouble. Your 15
> > minute session timeout is an eon on the timescale of a script watching
> > the network for your protocol and exploiting it on the fly.
> >
> > SSL has finally come into a somewhat reasonable price range. We should
> > go ahead and exploit it. We don't need to mess around with dodgy
> > timeout based designs.
> >
> > Thanks again for the questions.
> >
> > Tyler
> >
> > --
> > The web-calculus is the union of REST and capability-based security:
> > http://www.waterken.com/dev/Web/
> >
> > Name your trusted sites to distinguish them from phishing sites.
> > https://addons.mozilla.org/extensions/moreinfo.php?id=957
> > _______________________________________________
> > p2p-hackers mailing list
> > p2p-hackers at zgp.org
> > http://zgp.org/mailman/listinfo/p2p-hackers
> > _______________________________________________
> > Here is a web page listing P2P Conferences:
> > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> >
>


--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957



More information about the P2p-hackers mailing list