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

[Tyler Close]

Hi Nick,

On 9/26/05, Nick Lothian <nlothian at educationau.edu.au> wrote:
> Interesting idea.

Thanks.

> It may not be security via obscurity, but it does appear to ignore a
> number of practical considerations.
>
> For instance, what about the secret URL being passed on in referrer
> headers to other pages? I think some browsers block it when you go from
> a secure page to a non-secure page on another site (although I'm unsure
> about that).

Fortunately, browsers don't send a Referer header field when the
referrer is an https URL and the linked to site is from a different
domain. I've been watching this implementation detail for a long time,
and it has been reliable.

> OTOH, all browsers block HTTP authenticaion credentials from being
> passed in the referrer header.

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 spend goes through as it was sent from my machine,
using my password.

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