Re: Concerns regarding cross-origin copy/paste security

On 2/2/12 10:27 PM, Ryosuke Niwa wrote:
> On Thu, Feb 2, 2012 at 10:20 PM, Charles Pritchard < 
> <>> wrote:
>     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:
> But even for those websites, what could input / textarea elements can 
> reveal more than what user sees?

Many sites use <input hidden> elements with what are essentially image 
maps for entering a PIN.

In that case, a user does not see the PIN, though they do see an image 
map which has been obscured through various means.

I doubt there are security risks in this area.

>     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.
> That's also an option and may need to be spec'ed to some extent.

It's the best I have to offer, in hypothesizing how we may address the 
High security sites use high security headers. If they've opted into 
those headers, we can do a lot to limit data exposure.

There are many sorts of XSS attacks for sites that do not implement 
security headers. We can't help those, there are just too many leaks. 
So, I'd focus on specifying additional clipboard constraints for high 
security sites.

I would put out one word of caution: such restrictions could be used for 
censorship. I don't think we have an option there.

It's becoming more common that top level domains are being restricted or 
redirected to country codes. It seems plausible that domains may further 
be restricted to HTTPS (SSL) signatures. Going further, sites may be 
restricted to those which serve appropriate security headers against XSS 
attacks. Disabling the "copy" mechanism for any portion of a site does 
risk censorship. But, we are only examining high security portions of 
high security sites, such as <input hidden> and <input type=password>.

We're examining those elements for the sake of consumer protection for 
users doing online banking and otherwise cooperating in a secure 
environment for private data. That's a good thing.


Received on Friday, 3 February 2012 06:43:55 UTC