A malicious thought: how to imagine a security issue
Monday, October 22, 2007 1:17:31 PM
So Dan Kaminsky claims on Wired that the browser is the bug
after investigating Flash security policy issues. Well, we already know
that the Flash security policy is too liberal by default, and it's not exactly a bug in the browser
from my point of view -
But the Wired article is interesting, though not very detailed. Some scope for imagination.. so let's imagine he has found a way the page will "spoof" its own address to confuse the plugin when it tries to apply samedomain policies.
Just imagine, how might that happen?
One of the unbelievable shortcomings of the old Netscape plugin API is that it doesn't actually tell the plugin the address of the page you're loading
. That makes it kind of hard for a plugin like Flash to apply any meaningful samedomain security policy!
What Flash does to work around this is to ask the browser to open this URL:
Of course we can not set "location" because trying to set it will take you away from the page and destroy the plugin instance you're trying to confuse.
Is there any other way to hide the location object?
The malicious thought: elements with IDs populate the global object (aka window). What would happen if we added an element with the id "location" to the document? Something like..
<div id="location" href="http://www.example.com/"></div>
make the browser see something completely different if you read window.location.href ...
Here is a
Luckily for your online safety Opera, Firefox, IE7 and Safari on Windows all pass - so move on, nothing to see here. But it's a good test case to keep around - for next time we tweak how elements are exposed in the global scope - and perhaps it inspires more of you
to look for those places where feature + feature = security issue.
For security testing, every malicious thought is welcome!