Let's compare the Web Powerbox proposal with cross-site interactions that can happen today using existing browser mechanisms.<br><br><br>Example 1:<br><br>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:<br>
<a href="http://localhost:1234/capture-from-webcam?when_done_post_to=http://mydomain.example.com/continuations/2563246435432535">http://localhost:1234/capture-from-webcam?when_done_post_to=http://mydomain.example.com/continuations/2563246435432535</a><br>
<br>The problem is, how does the web app discover the URL "<a href="http://localhost:1234/capture-from-webcam">http://localhost:1234/capture-from-webcam</a>"?<br><br>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.<br>
<br><br>Example 2:<br><br>Let's consider the problem of providing payments to a shopping site. Suppose <a href="http://buystuff.com">buystuff.com</a> knows that your credit card company is <a href="http://bank.com">bank.com</a> (so its discovery of <a href="http://bank.com">bank.com</a> has already happened, somehow). To request a payment, <a href="http://buystuff.com">buystuff.com</a> redirects to "<a href="http://bank.com/request?amount=10&destination=buystuff">http://bank.com/request?amount=10&destination=buystuff</a>". <a href="http://bank.com">bank.com</a> displays the amount with a button to confirm the payment [2].<br>
<br>As I understand it, this is approximately the arrangement that OAuth supports. (Furthermore, some people are proposing to use OAuth for payments. [3])<br><br>The risks of this OAuth-like arrangement are:<br><br>* Clickjacking (UI redressing), if <a href="http://buystuff.com">buystuff.com</a> frames <a href="http://bank.com">bank.com</a>. But <a href="http://bank.com">bank.com</a> can detect framing and framebust.<br>
* Phishing. If <a href="http://bank.com">bank.com</a> 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 <a href="http://bank.com">bank.com</a> with ambient credentials such as cookies or HTTP auth.)<br>
* XSRF. To avoid this, <a href="http://bank.com">bank.com</a> 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 "<a href="http://bank.com/request?..">http://bank.com/request?..</a>." must include or fetch the secret token based on ambient credentials.)<br>
* Asynchrony. <a href="http://buystuff.com">buystuff.com</a> 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].)<br>
<br>On phishing: Though I assumed above that the user is logged in to <a href="http://bank.com">bank.com</a>, this assumption is not safe. If the user is not logged in, it is tempting for <a href="http://bank.com">bank.com</a> 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.<br>
<br>None of the use cases I have listed on <a href="http://plash.beasts.org/wiki/WebPowerbox">http://plash.beasts.org/wiki/WebPowerbox</a> involve the user entering sensitive information. Are there any other use cases that might involve this?<br>
<br>Interestingly, this OAuth-like arrangement actively depends on ambient authority via HTTP credentials such as cookies. If <a href="http://buystuff.com">buystuff.com</a> had a web-key to a payment-requester form page on <a href="http://bank.com">bank.com</a>, it could authorise any payment it wanted without going via the user, by sending HTTP requests directly to <a href="http://bank.com">bank.com</a>, server-to-server.<br>
<br>So what does the Powerbox give us over OAuth?<br><br>* It removes the need for <a href="http://buystuff.com">buystuff.com</a> to be told about <a href="http://bank.com">bank.com</a> in advance.<br>* It removes the need for <a href="http://bank.com">bank.com</a> to use cookies. The Powerbox is a mechanism for the browser to hold a secret that is not accessible to <a href="http://buystuff.com">buystuff.com</a>, and this mechanism is an alternative to HTTP ambient credentials.<br>
* Re: Clickjacking: The powerbox allows <a href="http://bank.com">bank.com</a>'s confirmation page to be reached via a web-key, which <a href="http://buystuff.com">buystuff.com</a> does not have. Thus <a href="http://bank.com">bank.com</a> does not have to rely on any framing-detection or framebusting techniques.<br>
* 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.<br>
* Re: Phishing: <a href="http://bank.com">bank.com</a>'s confirmation page is reached via a trusted path, i.e. by choosing <a href="http://bank.com">bank.com</a> from the powerbox dialog. Suppose <a href="http://bank.com">bank.com</a> asks for a confirm-payment password before proceeding. To capture this password, an attacker would need to spoof the powerbox dialog as well as <a href="http://bank.com">bank.com</a>'s page. (I have more to say on this subject, which I'll save for a later post.)<br>
<br><br>Thanks to James Ascroft-Leigh for his comments offline which prompted this line of thought.<br><br>Mark<br><br>[1] <a href="http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0487.html">http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0487.html</a><br>
<br>[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.<br><br>[3] <a href="http://wiki.oauth.net/OAuth-for-Payment-flow">http://wiki.oauth.net/OAuth-for-Payment-flow</a><br>
<a href="http://stakeventures.com/articles/2010/02/11/opentransact-a-tiny-payment-standard">http://stakeventures.com/articles/2010/02/11/opentransact-a-tiny-payment-standard</a><br> <a href="http://www.opentransact.org/">http://www.opentransact.org/</a><br>
<br>[4] <a href="http://waterken.sourceforge.net/clickjacking/">http://waterken.sourceforge.net/clickjacking/</a><br><br>