[cap-talk] Polaris tickle, POLA for Internet access, URLs
david.nospam.hopwood at blueyonder.co.uk
Tue Dec 7 02:15:24 EST 2004
David Wagner wrote:
> David Hopwood writes:
>>I don't see anything fundamentally insecure about page content being
>>modified by a script -- provided that the location of the script is
>>specified by the page that it is modifying.
> Let me give you an example. Consider: when your mouse hovers over a link,
> it shows you one URL. Just when you click on it (or after 5 seconds),
> the script changes what that URL refers to, so that the browser is driven
> to a different URL than expected.
There are two candidate security properties here:
1. Does the browser display the page that the author of the referring
page intended (this is the "y property" described at
2. Does the browser display the page that the user expected?
Property 1 is not affected by the above script behaviour: the browser
*does* go to the page that the author of the referring page intended
(modulo possible lack of authentication in the URL protocol or DNS).
It is not clear that property 2 is achievable. It's also not clear that
it is sufficiently well-defined to say whether it has been achieved in
any particular case or not. Finally, it's not clear how much users
actually care about being able to check in advance which URL they are
going to (provided that the browser cannot do anything harmful when
rendering a page). I basically agree with Jed and Jonathan's comments
on this point.
> didn't expect to (which is risky when you consider the file upload input
> method for forms).
Yes, this is the case of requests with side effects that I mentioned in
my previous post. However, confirming only requests with side effects
would be *much* less intrusive than confirming every page transition.
File upload is a separate can of worms, but I don't think it presents
any fundamental difficulties. Obviously it should require a trusted file
dialog to select the file, and that dialog should tell the user where
the file would be sent to if the form is submitted (it might not be).
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the cap-talk