W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Clipboard API: Stripping script element

From: Paul Libbrecht <paul@hoplahup.net>
Date: Sat, 30 Mar 2013 00:21:28 +0100
Cc: James Graham <jgraham@opera.com>, public-webapps@w3.org
Message-Id: <48E9ADA0-BB78-4E3F-87B7-3EFC20ABF401@hoplahup.net>
To: Ryosuke Niwa <rniwa@apple.com>
Nice catch for this example you provide below.
The "solution" to this issue would be to simply empty the script element instead of stripping it away. Right?

In your original mail, however, you write:
> It would be great to mention what kind of manipulations user agents are allowed to do to make the pasted content secure.


I think this claim is exactly why Halvord has removed the sanitization section. It seems highly implementation dependent to decide on the security of a fragment of content. 
I feel the section on the sanitization should be expressed with "should" expressing recommendations such as that of emptying script elements or replacing object  or embed elements by a corresponding images.  I'm pretty sure conservative approaches will start by doing a similar replacement with video elements, for example, but might include them after some other introspection (e.g. that it is not pulling from a streaming source).

Paul


> The particular case I had in my mind was something like:
> 
> <div>
> <script>~</script>
> <span>hello</span>
> <style>
> div {
>     color: red;
> }
> span:nth-child(2) {
>     color: green;
> }
> </style>
> </div>
> 
> If we had striped the script element, the hello will be shown in red instead of green. We ought to define what UAs are allowed to do (e.g. strip script element) even if we couldn't specify the exact algorithm so that authors won't be surprised by some UAs stripping script elements and others emptying out the text nodes within it.
> 
> FWIW, stripping script element appears to be the nominal behavior both among browsers and various mail apps (e.g. Gmail, etc…).
> 
> - R. Niwa
> 
Received on Friday, 29 March 2013 23:22:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 March 2013 23:22:27 UTC