[cap-talk] Comparing Web Powerbox with OAuth (was: Granting access to web services)

[Mark Seaborn]

Let's compare the Web Powerbox proposal with cross-site interactions that
can happen today using existing browser mechanisms.


Example 1:

Suppose a local web server provides a "take a picture" service.  To use this
service, a web app could redirect or link to the following URL:
http://localhost:1234/capture-from-webcam?when_done_post_to=http://mydomain.example.com/continuations/2563246435432535

The problem is, how does the web app discover the URL "
http://localhost:1234/capture-from-webcam"?

The Powerbox solves this discovery problem: it provides a way for web apps
to be introduced to services.  Hence web apps do not need to hard-code a
list of service URLs; and the user does not need to enter a service URL into
a form in the web app.  This is in contrast to the suggestion in [1] in the
context of a discussion about CORS.


Example 2:

Let's consider the problem of providing payments to a shopping site.
Suppose buystuff.com knows that your credit card company is bank.com (so its
discovery of bank.com has already happened, somehow).  To request a payment,
buystuff.com redirects to "
http://bank.com/request?amount=10&destination=buystuff".  bank.com displays
the amount with a button to confirm the payment [2].

As I understand it, this is approximately the arrangement that OAuth
supports.  (Furthermore, some people are proposing to use OAuth for
payments. [3])

The risks of this OAuth-like arrangement are:

* Clickjacking (UI redressing), if buystuff.com frames bank.com.  But
bank.com can detect framing and framebust.
* Phishing.  If bank.com never asks for sensitive information, like a
password, this should not be a problem.  Clicking "Confirm Payment" on a
spoofed web site would have no harmful effect.  (I am assuming the user is
logged in to bank.com with ambient credentials such as cookies or HTTP
auth.)
* XSRF.  To avoid this, bank.com must require that the form submission that
confirms payment includes a secret token and does not take effect based on
ambient credentials alone.  (However, the page "http://bank.com/request?..."
must include or fetch the secret token based on ambient credentials.)
* Asynchrony.  buystuff.com can choose when to redirect.  It could trick the
user into clicking the "Confirm Payment" button if the redirect happens fast
enough by engaging the user in a clicking game.  This is like clickjacking,
but it is arguably not UI redressing.  (Tyler Close mentions this scenario
in [4].)

On phishing:  Though I assumed above that the user is logged in to bank.com,
this assumption is not safe.  If the user is not logged in, it is tempting
for bank.com to offer to accept a username+password to log in.  As soon as
the user becomes accustomed to entering passwords through this route, this
arrangement becomes vulnerable to phishing.

None of the use cases I have listed on
http://plash.beasts.org/wiki/WebPowerbox involve the user entering sensitive
information.  Are there any other use cases that might involve this?

Interestingly, this OAuth-like arrangement actively depends on ambient
authority via HTTP credentials such as cookies.  If buystuff.com had a
web-key to a payment-requester form page on bank.com, it could authorise any
payment it wanted without going via the user, by sending HTTP requests
directly to bank.com, server-to-server.

So what does the Powerbox give us over OAuth?

* It removes the need for buystuff.com to be told about bank.com in advance.
* It removes the need for bank.com to use cookies.  The Powerbox is a
mechanism for the browser to hold a secret that is not accessible to
buystuff.com, and this mechanism is an alternative to HTTP ambient
credentials.
* Re: Clickjacking:  The powerbox allows bank.com's confirmation page to be
reached via a web-key, which buystuff.com does not have.  Thus bank.com does
not have to rely on any framing-detection or framebusting techniques.
* Re: Asynchrony:  We can ensure that opening the powerbox dialog only
happens in response to a user click, so that sites cannot open it
asynchronously.  So we can reduce the risk from a clicking-game attack to
some extent.
* Re: Phishing:  bank.com's confirmation page is reached via a trusted path,
i.e. by choosing bank.com from the powerbox dialog.  Suppose bank.com asks
for a confirm-payment password before proceeding.  To capture this password,
an attacker would need to spoof the powerbox dialog as well as bank.com's
page.  (I have more to say on this subject, which I'll save for a later
post.)


Thanks to James Ascroft-Leigh for his comments offline which prompted this
line of thought.

Mark

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0487.html

[2] This is actually more advanced than typical arrangements where the site
asks you to enter your credit card number, thereby granting use of your
whole account.

[3] http://wiki.oauth.net/OAuth-for-Payment-flow

http://stakeventures.com/articles/2010/02/11/opentransact-a-tiny-payment-standard
    http://www.opentransact.org/

[4] http://waterken.sourceforge.net/clickjacking/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100214/3f1f2d72/attachment.html