Re: [widgets] API - openURL security considerations

Hi Adam,

On Tue, Feb 9, 2010 at 3:57 AM, Adam Barth <w3c@adambarth.com> wrote:
> What about being about to link to file:// URLs?  You probably want to
> ban that.  Also, have you considered what happens if you put a
> JavaScript URL or a Data URL into openURL?

I've added the following non-normative security considerations to the
appropriate section that defines the security of openURL (but have not
checked in the draft yet):

[[
"Because user agents are not restricted in the set of URI schemes they
can handle through the openURL method, user agents should consider the
following recommendations to limit the attack surface of the openURL
method.

It is recommended that user agents ignore all requests pertaining to
the file: URI scheme, defined in [RFC1630], and ignore all requests
pertaining to the javascript: URI scheme defined in [JS-Scheme]. User
agents that support the data: URI scheme should consult the Security
section of [RFC2397]. "
]]

I was not able to dream up any use cases for invoking javascript
through this method.  Can anyone else think of any? Also, I wonder if
we should drop sentence 1 and actually make all this normative
requirements on UAs.

> Adam
>
>
> On Mon, Feb 8, 2010 at 8:36 AM, Marcos Caceres <marcosc@opera.com> 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.
>>
>>
>>
>
>



-- 
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au

Received on Tuesday, 4 May 2010 11:35:57 UTC