Re: Safe copy and paste with scripts

Le Sun, 05 Mar 2006 15:45:58 +0200, Doug Schepers <doug@schepers.cc> a  
écrit:

>
> Hi, Jim-
>
> I think you raise excellent points. I'll reply inline.
>
> Jim Ley wrote:
> |
> | The bigger problem is not cancelling it's changing - so you
> | go to copy a url into an email message, and a different link
> | ends up on the clipboard.
>
> While this is tricksy and suboptimal, I don't see it as a genuine  
> security
> concern, merely an annoyance. But I am willing to be educated as to the
> danger of it.

Yes... it's a tricky problem and not exactly a privacy invasion. It's just  
like those "window shaking" scripts done by kids - still working in IE.

> In any case, it might be nice if the user were alerted in some way that a
> "copy" event has been triggered/changed, and I recommend that we include
> wording to this effect in an informative description.
>
>
> | Or if you simply happen to be on a page and the browser can look at
> | what is in your clipboard, even if it's your untrusted data,
> | yet allowing access to the content when you do want to give your
> | clipboard contents.
>
> I think this is best solved by simply not allowing script to have access  
> to
> the clipboard buffer unless the user specifically fires a paste event.
> Therefore, "paste" events should not work with createEvent().
>
> What other security concerns do people see?

Here are my suggestions:

1. Any script must not be allowed to read and write clipboard data unless  
the user allows so (via a confirmation or a setting in the UA, whatever).  
This must be a requirement.

This is a security concern that, for example, IE doesn't deal with. Any  
web site can overwrite clipboard data, or read the clipboard data without  
the unsuspecting user ever knowing.

AFAIK, Firefox does deal with this as suggested above (it asks the user  
for confirmation).

2. UAs should (or even must) make it so that the "clipboard data read and  
write" features are only opt-in, not opt-out.

3. Developers should have some DOM events that allow them to monitor the  
clipboard data (cut/copy/paste and probably even selection deletion). All  
these must work only after the user confirms access.

An idea that hasn't been discussed ... but might be worth it:

How about giving full access to a "page clipboard" (read and write)  
without any confirmation? This could be a ... sandboxed clipboard approach.

1. Scripts can do whatever they wish with the data users copy/paste within  
the site.

2. Via opt-in, they can disable the sandboxing, therefore allowing access  
to the entire clipboard of the OS/UA.

3. This sandboxed clipboard is per page: script won't have access to  
clipboard data of other pages opened in other tabs/windows in the same UA.

This is a bit more complex (implementation-wise).

Possible advantages to sandboxed clipboard would be: no user  
interaction/confirmation required, and the data that goes in could be of  
"complex types", more features, etc. This is where the spec could offer  
things not available in "traditional clipboard".

Sandboxing could be per page, per URL, per server, or user-customized  
filtering (if the UA allows so).

(I know this post goes a bit "off-topic" since it's not only about  
security concerns.)


-- 
http://www.robodesign.ro
ROBO Design - We bring you the future

Received on Sunday, 5 March 2006 16:50:43 UTC