Re: [widgets] API - openURL security considerations

Marcos,

first of all, kudos for thinking about security considerations for this method.  I'm glad you're considering factors like interaction flooding and tons of windows opening.

Reviewing the spec text:
http://www.w3.org/TR/2009/CR-widgets-apis-20091222/#the-openurl-method

... I wonder whether the specification actually says that openURL will ever return upon success.  You say that the widget's browsing context must not be navigated ("for security reasons" -- which ones?  Access to special features within the widget context?)  -- but do you forbid simply destroying the widget (or never returning) when openURL is invoked?

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.

So, to the security considerations:

- if openURL can be executed multiple times, then pretty much everything one can say about pop-ups applies
- as Adam said, file: URIs deserve some extra thought
- 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.

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>







On 8 Feb 2010, at 17:36, Marcos Caceres wrote:

> At Opera we've been discussing some of the security implications around the openURL method in the widgets API spec. We think the spec might benefit if we were to add a non-normative security consideration section for openURL.
> 
> We are basically concerned about protecting against a simple attack such as:
> 
> while(true){
>  openURL("http://...");
> }
> 
> The following text, which I did not write, can serve as a basis for the note - we are presenting it here for discussion, and you'll note it uses different terminology than the one found in the spec. In other words, please don't consider the following to be spec text, it needs a fair amount of editing but tries to get to the heart of the problem:
> 
> [[
> APIs to open external programs, such as opening a URL in a browser, SHOULD only be allowed automatically if the widget has focus. Opening such an external program, SHOULD result in the widget losing focus, for the purpose of opening more external programs. User interaction with the widget may restore the focus to the widget. Widget Managers MAY offer a dialog for other attempts to open external programs, or MAY fail the operation. User agents MAY also offer an override for users to allow a widget to open external programs automatically, even when minimized in the background.
> 
> Security considerations: Widgets may have managed run-time constraints, for instance on memory usage or domain access, and opening multiple instances of external programs may easily exceed those constraints. External programs may present dialogs to perform harmful actions, e.g. download dialogs, and multiple new windows in a short time span may allow for interaction flooding attacks or may lead to warning fatigue. This security measure ensures that users get a reasonable chance to manage the run-time constraints, and ensures that only one external program and/or dialog can be opened at a time.
> See http://www.w3.org/TR/wsc-ui/#popups for more details.
> ]]
> 
> We would appreciate any feedback people have about the proposed text.
> 
> 
>

Received on Thursday, 18 February 2010 09:50:48 UTC