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

[Tyler Close]

Hi Nick,

On 9/26/05, Nick Lothian <nlothian at educationau.edu.au> wrote:
> It does depend on the secured urls only being available under https,
> though, which is somewhat non-obvious.

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

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

If the site has a XSS bug, the jig is up regardless of what
authorization mechanism you are using. The attacker can completely
control the presentation and functionality of the web page, including
remote controlling it on the fly.

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

There are no HTTPS history files. HTTPS history is only stored in RAM
for the duration of the browser session.

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

Reading 128 bits from /dev/random is pretty easy to implement. App
servers with these kinds of bugs are pathetic.

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

I am skeptical of defenses based on expiration times, but if that's
what you want, you can certainly time out your URLs, just as you do
your session ids.

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

I don't think this is an acceptable state of affairs, but beyond that,
this example is just that, an example. This type of attack is present
in many browser and non-browser scenarios. Really, it can be done
anytime you are using ACL based authorization. The problem is that the
user's authority gets paired with an identifier selected by the
attacker. Whenever your software accepts an identifier from a
potential attacker, you are vulnerable to this kind of attack. This is
really serious if you think about what software does. Basically, all
software does is pass around identifiers, and each transfer is an
attack point when you are using ACL based authorization.

A capability-based design is not vulnerable to this kind of attack.

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

Software attacks are automated attacks. Human scale timeouts are futile.

Thanks for your comments. It's great to have an excuse to talk about this stuff.

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