[p2p-hackers] Re: [rest-discuss] Re: RESTful authorization

[Tyler Close]

Hi Antoine,

On 9/27/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > Unfortunately, browsers are very promiscuous with HTTP authentication
> > credentials in other ways. For example, consider a resource at my bank
> > which will perform a spend when sent a POST with the expected HTTP
> > Auth credentials. This resource may be located at
> > <https://bank/account/pay>. Imagine I log into my bank account, check
> > on some pending transactions and then go visit some interesting blogs.
> > At the end of a blog post is a form submission button that claims to
> > create a blog post comment. The form actually points to
> > <https://bank/account/pay> and does a spend when I click on it. I
> > click on the button, and my browser does the form POST, happily
> > responding to the bank's HTTP Auth challenge using it's cached copy of
> > my password.
>
> The bank's website is at fault if it does not check for fraudulent
> requests.
> The bank's website should generate (server-side) an unique ID each time
> the client asks for a spend. Then on return from the form, the server
> checks the unique ID is genuine

The first interesting thing to note is that your proposed solution
implicitly acknowleges the fact that the username/password is not
providing access control. In your proposed solution, the use of
username/password is irrelevant. The unguessable ID is providing the
access control. Note that the ID must be unguessable, not just unique.
If the ID is predictable, your proposed solution is foiled by the same
attack I describe above.

Your proposed solution has the flavour of what I am proposing, using
unguessable IDs for access control. Unfortunately, you have reified
the authority to submit a spend as an unguessable ID, but you have not
so reified the authority to request a spend. This is where your
proposed solution fails. For example, the blog post page from the
example above could do a GET on the URL that produces your FORM that
contains a newly generated spend ID. The blog post page could then
extract the spend ID from the returned FORM and use it to construct a
new FORM, like the one it constructed in the example above. Now, when
the user clicks on the generated submit button, the browser does the
FORM POST, again happily responding to the bank's HTTP Auth challenge,
as well as providing the expected spend ID.

> So I don't understand why you put the guilt on the HTTP protocol itself
> (or its client implementations).

I don't put the guilt on the HTTP client, server or protocol. They are
all faithful implementations of an ACL model. The problem is that the
ACL model is broken.

Your proposed solution is still vulnerable to attack, precisely
because it is still depending upon an ACL check. Were you to reify the
rest of the application's exported authorities as unguessable IDs, the
application would no longer be vulnerable to this kind of attack, and
you would have a design much like what I am proposing.

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