Re: [widgets] API - openURL security considerations

That depends on what security context the browser thinkings you're
running in.  In general, you need to understand the security
implications of each API, regardless of how you implement them.

Adam


On Thu, Feb 18, 2010 at 1:09 PM, Scott Wilson
<scott.bradley.wilson@gmail.com> wrote:
> 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.
>>>
>>>
>>>
>>
>>
>
>

Received on Friday, 19 February 2010 21:18:44 UTC