On 4 May 2010, at 14:10, Marcos Caceres wrote: > Right. I have clarified this: > > [[ > A user agent must not navigate the browsing context of a widget > instance through the openURL() method: the concept of navigate is > defined in [HTML5]. This restriction is imposed so an arbitrary web > site cannot gain access to special features, such as those potentially > declared through the configuration document's feature element, that > may be enabled within the widget context. > ]] > >> >> If the method never returns, then the attack you're concerned about is >> probably infeasible (which would be good news); it would also tie widgets >> into a very specific application model that I don't know is desirable. You >> probably want to clarify this. >> > > I kinda get what you are saying here, but I'm having trouble > articulating it in the spec. Can you explain this a bit more or > provide an example.
What I thought of was that, if openURL never returned, it's obvious that interaction flooding style UI attacks can't occur. However, you couldn't actually open a URL and continue execution of a widget. That's not desirable. You might want to add a UI consideration around what could usefully happen if there are several pending approvals, though. (E.g., "approve navigating to this harmless link", "approve navigating to that harmless link", "approve sending this super expensive text message.") >> So, to the security considerations: >> >> - if openURL can be executed multiple times, then pretty much everything one >> can say about pop-ups applies. > > By "everything one can say about pop-ups", should I reference > something from the "Web Security Context: User Interface Guidelines"?: > > http://www.w3.org/TR/2010/WD-wsc-ui-20100309/#popups You could. :) > >> - as Adam said, file: URIs deserve some extra thought > > I responded to Adam and CC'd you: > > http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0439.html I'll be curious what Adam thinks about making non-support for data, file, and javascript normative. I'd lean toward being in favor of that. >> - it's perhaps worthwhile to spell out to implementers that there are many >> ways to write a URI handler that isn't safe, e.g., assuming that just >> because a scheme has a particular syntax that syntax is actually followed. > > What would be some recommendations for guarding against malformed URIs? So, you have the notion of un-trusted scheme handlers in the document already: > In the case that passing a URL to an un-trusted scheme handler, it is > recommended that a the user agent prompt the user prior passing the URI to a > scheme handler. In particular, this would apply, for example, to sms: and > similar schemes. Perhaps add something like this: "Note that URI syntax depends on the URI scheme. URI handlers therefore cannot rely on user agents to sanitize URI references before they are passed on, and need to be prepared to process arbitrary data securely."
