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

[Antoine Pitrou]

Hi,

> 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 (or any other similar type of check, for
example involving a challenge/response with a client-side Javascript
hash implementation - I know there are some for MD5, it's reasonable
workable). This is not difficult to do. It involves a two-step
interaction, which is not unexpected for dangerous actions.

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

> Using https is a pretty standard thing to do in a secure web
> application.

Sorry, but I call bullshit on this ;)
HTTPS is not available in a proper way for people using shared hosting
services (i.e. 99.99% of the Web). Also, HTTPS takes a lot of resources.
Thus it is not an option for most people.

Regards

Antoine.