Re: Concerns regarding cross-origin copy/paste security

On 2/2/12 10:14 PM, Ryosuke Niwa wrote:
> Sorry for the extremely slow reply. It slipped through hundreds of 
> emails :(
>
> On Mon, May 16, 2011 at 8:41 PM, Hallvord R. M. Steen 
> <hallvord@opera.com <mailto:hallvord@opera.com>> wrote:
>
>         To me, it doesn't make sense to remove the other elements:
>         - OBJECT: Could be used for SVG as I understand.
>
>
>     OBJECT is considered a form element, so it might have hidden data
>     associated with it. It can also contain plugin content that could
>     inject scripts and be used for XSS attacks. It may be too
>     far-fetched or draconian to remove it though. (SVG is rich enough
>     to be its own can of worms by the way..)
>
>
> Given the improved support for inline SVG and MathML, it's probably 
> okay to strip it. However, we should add EMBED to the list since it's 
> a plugin element.
>
>         - INPUT (non-hidden, non-password): Content is already
>         available via
>         text/plain.
>
>
>     An input's @name attribute is basically hidden data the user will
>     not be aware of pasting. I'm not sure how much of a threat this
>     is, but we should give it some thought.
>
>
> You mean <input name="~">? I don't think that'll expose much 
> information. I'd prefer not removing these attributes as I've seen 
> bugs filed against WebKit for "form control" editors; apparently some 
> people would like to create form control editors using contenteditable.
>

Seems like a very minor risk for high security sites, e.g. banking, in 
identifying form elements.
In the spirit of giving it some thought:

There are various XSS headers that signal enhanced security for 
websites, even to browser extensions.
Perhaps some of them ought to be used in the "copy" mechanism. That way 
the data never reaches the clipboard for paste.

-Charles