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

[Nick Lothian]

> 
> 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.
> 

Fair enough.

It does depend on the secured urls only being available under https,
though, which is somewhat non-obvious. 

There is also increased vunerability to cross-site-scripting attacks. If
the attacker can get the window.location passed to a third party site
then they get access to your resource.

HTTPS urls show up in a browser's history, too, which makes your history
files a much more tempting target for spyware etc.

I'm not convinced that the "unguessability" of the URL is something I'd
want to bet on either. There have been plenty of vulnerabilities that
allow attackers to guess/predict session id cookies from application
servers. This appears to be the same problem, but made easier because
the URLs don't have a time limit on how long they remain valid for
(unlike session ids, where the attacker has a very limited time to try
and find a valid session id before it expires)

> > 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
> 

Yes, I read that example in the REST group archive.

It is an interesting attack, but one the user can work around. For
instance, in IE if you open your session to the bank in a separate
instance of IE (instead of just a separate window) then the credentials
won't be shared. I don't think Firefox lets to start multiple instances,
though (on Windows anyway)

The other thing is that both the bank and the user can limit the
timeframe of potential secutiry breaches and increase security by either
(a) enforcing short session time outs and/or (b) logging out of the
application. 

Nick


IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party.
This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise.
It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects.
education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email.