[whatwg] Fixing two security vulnerabilities in registerProtocolHandler

[Ian Hickson]

On Mon, 9 Apr 2012, Tyler Close wrote:
> 
> The browser's popup blocker would block that interaction, unless you 
> require an additional click inside the iframe. UX people are generally 
> fanatical about eliminating extra user clicks.

I'm suggesting sending the information at the same time as you currently 
open the window.


> For RPH to be used in an offline scenario, the %s argument is put in the 
> URL fragment component of the RPH handler's URL.

It can also be put in the query or path component, if the relevant path is 
marked as being a FALLBACK namespace.


> Here's another concrete attack scenario showing how this vulnerability 
> could be exploited in a mailto RPH handler. Consider a site that 
> requires a user to confirm a security sensitive operation by sending an 
> email with a confirmation number in the Subject field. The site expects 
> this email to be signed by the user's mail software. The web page that 
> sets up this user interaction includes a mailto link to open a 
> pre-populated email editor. This mailto: link includes a subject 
> parameter that contains the confirmation number. The attacker has 
> previously setup an operation that is waiting on such an email 
> confirmation from the victim user. The attacker has additionally lured 
> the user into browsing the legitimate site in a window that the attacker 
> has a reference to. The attack page waits for an iframe to show up in 
> the legitimate site's frame hierarchy at the place where a mailto RPH 
> confirmation action is being done.

It seems highly weird to me that anyone would use a mailto: link with a 
target="" attribute, but ok.


> The attack page overwrites the iframe's URL fragment with a mailto URL 
> that contains a subject parameter specifying the confirmation number for 
> the operation setup by the attacker, instead of the one that the victim 
> user was setting up.
>
> The user sends the email, confirming the attacker's operation, instead 
> of their own. From the user's perspective, they see that they are at the 
> legitimate web site and they setup an operation in the normal way which, 
> as expected, opens an email editor with a confirmation number. The user 
> typically never looks closely at the confirmation number, it's just some 
> number chosen by the legitimate web site. So, everything looks normal to 
> the user. From the perspective of the RPH handler page, everything also 
> looks normal. It opens and finds a mailto URL in the %s position in it's 
> URL fragment. It has no idea that the URL fragment has changed since the 
> legitimate site first specified it.

It doesn't even have any idea that there is a legit site.


> We can fix this by putting the %s data in a DOM field that cannot be 
> overwritten by an attacker in this way.

That's what Web Intents does, but it doesn't really help with the 
server-side implementations of handlers, which are the expected common 
case here, and it doesn't even really help with the client-side 
implementations of handlers, who have no way to know who is "legit".


> Consequently, the legitimate site can securely pass a confirmation 
> number to the RPH handler. The attacker can still navigate to the mailto 
> URL from one of the attacker's own pages, but can't do it from one of 
> the legitimate site's pages. So the attacker can't make it look like the 
> legitimate site is asking the user to send the confirmation email.

How is the mailto: handler supposed to know who is legit and who isn't?


> The important thing to understand here is that a communication channel
> that is vulnerable to tampering can be abused in unexpected ways.

You don't need to tamper with the communications channel as far as I can 
tell. If you can navigate an <iframe> as you describe, then even if the 
mailto: information is put in the path or query component it would still 
be possible to do the attack you describe. Just wait for the iframe to 
appear and then navigate it to the mailto: handler with the parameters you 
want. Since browsers only allow "tampering" with the fragment identifier, 
the simpler solution is to just not use the fragment identifier.


> Rather than quibble about how a future attacker might make use of this 
> vulnerability in some future application, the right thing to do is 
> eliminate the vulnerability.

I don't see how what you propose eliminates the vulnerability.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'