Re: [widgets] API - openURL security considerations

Hi both,

Apache Wookie (incubating) currently implements the widget.openURL  
method by directly calling the browser's window.open() function - in  
this example is there anything particularly special about the fact its  
being called by a widget? Should our implementation do anything extra,  
or is it better just leaving it to the browser to handle any problems?

S

On 18 Feb 2010, at 09:50, Thomas Roessler wrote:

> 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.
>>
>>
>>
>
>