Re: Clipboard API: Stripping script element
On Mar 29, 2013, at 4:21 PM, Paul Libbrecht p...@hoplahup.net wrote: 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? Unfortunately, that approach won't be backward compatible. Also, it's somewhat dangerous to leave an empty script element in the document. 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). The section was removed due to lack of implementations. I'm fine with not having an explicit algorithm. However, there appears to be a significant interoperability issue if we were to not define what user agents may or may not do. - R. Niwa
Re: Clipboard API: Stripping script element
On Fri, Mar 29, 2013 at 11:21 PM, Paul Libbrecht p...@hoplahup.net wrote: It seems highly implementation dependent to decide on the security of a fragment of content. I don't see why it would be. The whole idea is that browsers support the same set of features, so the security implications are the same. We're going to great extent to align and define the security model. -- http://annevankesteren.nl/
Re: Clipboard API: Stripping script element
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
spanhello/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
Re: Clipboard API: Stripping script element
The current clipboard API specification mentions security risks
of copy paste but doesn't seem to explicitly mention methods by
which user agents deal with such security risks.
Hi Ryosuke,
I did remove the section on cleaning up content because it was not implemented
by anyone and seemed unlikely to be - but there is some advice in section 8.1
(Security risks). It mentions The user might paste malicious JavaScript into
a trusted page. among the risks and suggests (in the table) that the UA may
sanitize content that comes from a different origin. I assume you want some
more details added here, right?
In particular, WebKit has been stripping script element from the
pasted content but this may have some side effects on CSS rules.]
AFAIK (without re-testing right now), WebKit's implementation is:
* rich text content that is pasted into a page without JS handling it is
sanitized (SCRIPT, javascript: links etc removed)
* a paste event listener that calls getData('text/html') will get the full,
pre-sanitized source
If that's correct I can add a short description of this to the spec, in the
informative section.
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: Clipboard API: Stripping script element
On 03/28/2013 12:34 PM, Hallvord Reiar Michaelsen Steen wrote:
On 03/28/2013 10:36 AM, Hallvord Reiar Michaelsen Steen wrote:
In particular, WebKit has been stripping script element from
the pasted content but this may have some side effects on CSS
rules.]
AFAIK (without re-testing right now), WebKit's implementation
is: * rich text content that is pasted into a page without JS
handling it is sanitized (SCRIPT, javascript: links etc removed)
* a paste event listener that calls getData('text/html') will get
the full, pre-sanitized source
If that's correct I can add a short description of this to the
spec, in the informative section.
Why would this be informative?
Mainly because it seems like spec'ing it is a bit out of scope for
this spec - I'm trying to spec how clipboard events should work as
seen from the JS side. Implementation details like how data is pasted
when there is no JS or event handling involved don't seem to belong
here, and IMO the interop issues are far-fetched (though the XSS
risks aren't).
I don't see why the interop issues are particularly far-fetched. The
approach of not problems in spec A because they ought to be addressed
some other hypothetical spec B is something we have tried before and it
hasn't worked well yet, so I don't think we should do it again here. As
the python doctrine goes, practicality beats purity.
Re: Clipboard API: Stripping script element
On Thu, Mar 28, 2013 at 11:42 AM, James Graham jgra...@opera.com wrote: I don't see why the interop issues are particularly far-fetched. The approach of not problems in spec A because they ought to be addressed some other hypothetical spec B is something we have tried before and it hasn't worked well yet, so I don't think we should do it again here. As the python doctrine goes, practicality beats purity. Agreed. You can't just define the API without defining the clipboard model. And actually, typically we put the model and API in the same specification. -- http://annevankesteren.nl/
Re: Re: Clipboard API: Stripping script element
On 03/28/2013 10:36 AM, Hallvord Reiar Michaelsen Steen wrote:
In particular, WebKit has been stripping script element from the
pasted content but this may have some side effects on CSS rules.]
AFAIK (without re-testing right now), WebKit's implementation is:
* rich text content that is pasted into a page without JS handling it is
sanitized (SCRIPT, javascript: links etc removed)
* a paste event listener that calls getData('text/html') will get the full,
pre-sanitized source
If that's correct I can add a short description of this to the spec, in the
informative section.
Why would this be informative?
Mainly because it seems like spec'ing it is a bit out of scope for this spec -
I'm trying to spec how clipboard events should work as seen from the JS side.
Implementation details like how data is pasted when there is no JS or event
handling involved don't seem to belong here, and IMO the interop issues are
far-fetched (though the XSS risks aren't).
Now, if there is interest in implementing this among other vendors, and general
agreement that we should have this in the clipboard events spec, I'm happy to
say something about this in normative prose. In other words, I'll just play
this ball right over to the Mozilla and Microsoft representatives: do you
currently implement, or do you plan to implement what WebKit does here?
It seems quite possible to construct
interop problems stemming from different implementations here e.g. a
site that assumes that there will never be script elements in pasted
text, or a site that assumes it can get scripts in the result of
getData(text/html). Therefore the exact behaviour of the platform in
this respect needs to be normatively defined.
The latter aspect should be normatively defined already, in so far the
normative getData('text/html') stuff doesn't spec any sanitization. So I think
the interop is taken care of. As an anti-XSS measure, how to handle pasting of
potentially risky content might be covered for example in specs for rich text
editing.
--
Hallvord R. M. Steen
Core tester, Opera Software
