New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 136497 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Aug 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Security: XSS via Copy&Paste protection bypass using @formaction / General Iframe Sandbox Considerations regarding copy&paste / drag&drop

Reported by mario.he...@gmail.com, Jul 10 2012

Issue description

Chrome Version : 22.0.1201.0
OS Version: Windows 7
URLs (if applicable) : http://jsfiddle.net/PDb4N/1/

What steps will reproduce the problem?
1. Have a look at that HTML
2. Do what it suggests
3. Witness the glory of a JavaScript alert

What is the expected result?
> Not witnessing the glory of a JavaScript alert

I have a small concern about a) cross domain copy&paste and b) Sandboxed Iframes combined with editmode/@contenteditable. Let's have a look at the following HTML, a @seamless and fully Sandboxed Iframe using @srcdoc:

<iframe sandbox seamless srcdoc="Select<form><button formaction=javascript:alert(document.domain)>Finally click me!</button></form>me and copy me"></iframe>
<h1 contenteditable>Then paste me here

When you follow the steps dictated by the test-case (you can find a JSFiddle right over here: http://jsfiddle.net/PDb4N/1/) you can see, that the HTML copied from the "malicious" Iframe is not being sanitized. Clicking the button after pasting the markup into the hosting website will cause JS execution on that domain. That ain't good I guess.

Comparing that for instance tho this very code outlines the problem:

<iframe sandbox seamless srcdoc="Select<img contenteditable=false src=x onerror=alert(1)>me and copy me"></iframe>
<h1 contenteditable>Then paste me here <- nothing happens, onerror gets stripped

So - I see two issues here: For once, @formaction with a JavaScript URI survives a cross-domain copy&paste process. Secondly, the HTML5 Iframe Sandbox considers tons of use cases, @autofocus, @autoplay and what not - but doesn't consider copy&paste or - for same-domain Iframes drag&drop. I checked the WHATWG specs of 9th of July and found no precise intel on how the Iframe Sandbox should deal with editable content and copy&paste/ drag&drop. I believe though that especially in combo with @seamless, a small attack surface for these kinds of calamities exists. An attacker can of course also use overlay attack to leverage the XSS from within a Sandbox (boy, that's a big button!).  

<iframe sandbox srcdoc="Select<form><button style=position:absolute;top:10;left:0;height:999em;width:999em; formaction=javascript:alert(document.domain)>Finally click me!</button></form>me and copy me"></iframe>
<h1 contenteditable>Then paste me here

So - to conclude. I think two small issues: copy&paste protection bypassed and Iframe Sandbox of questionable quality (that's not a Chrome issue - more of a general concern). Feedback welcome. We're thinking about an academic publication on Iframe Sandbox protection features and bypasses - so a WONTFIX is extremely welcome here :P j/k
 

Comment 1 by jsc...@chromium.org, Jul 11 2012

Cc: rniwa@chromium.org
Yeah, I think we're already aware of some of this as  bug 112325 . Turns out that sanitizing pasted HTML is far more painful than it may seem. @rniwa - Should this be duped out to  bug 112325 ?

Not sure about the iframe sandbox case. I suppose we'll need to bounce that idea around a bit.

Comment 2 by rniwa@chromium.org, Jul 11 2012

Cc: dcheng@chromium.org abarth@chromium.org

Comment 3 by rniwa@chromium.org, Jul 11 2012

I don't think this is a dupe of the  bug 112325 . Also, we should file a WebKit bug for this.

Comment 4 by dcheng@chromium.org, Jul 11 2012

There's an algorithm described in http://www.w3.org/TR/clipboard-apis/#cross-origin-html-paste-sanitization-algorithm.  It shouldn't be hard to implement, though in its current form, it doesn't cover formaction either...
The algorithm indeed doesn't cover @formaction; It turns out though that this seems to be the only edge case getting through unfiltered. I tested with the entirety of H5SC vectors and didn't get a comparable result so far. 

One other thing getting through unfiltered are data URIs. No XSS in plain sight with those though.

Comment 6 by jsc...@chromium.org, Jul 19 2012

So, who's the right owner for this?
Tom? Adam? We haven't bothered Adam for far too long ;-)

Comment 8 by tsepez@chromium.org, Jul 19 2012

My recollection was that filtering was acceptable only in cross-origin cases, but that it was hard to determine the origin from whence the pasted markup was copied.

Comment 9 by rniwa@chromium.org, Jul 19 2012

Yeah, detecting cross-origin case is virtually impossible. I think we should just strip all @formaction whenever it contains scripts.
Can't we at persist the origin for copies that originated in WebKit? That way, we can skip applying the policy to WK -> WK pastes at least.

Comment 11 by rniwa@chromium.org, Jul 19 2012

How are we going to do that? If we're embedding some comments, etc... then attackers can easily add those comments themselves on other browsers or using clipboard.setData.
It would be out of band like webkit smart paste.

Comment 13 by rniwa@chromium.org, Jul 19 2012

smart paste doesn't store extra information on clipboard as far as I know.
https://cs.corp.google.com/#chrome/src/webkit/glue/webclipboard_impl.cc&l=191

It wouldn't be hard to add something similar for origin to WebCore::Clipboard and plumb it through to the browser.

Comment 15 by rniwa@chromium.org, Jul 19 2012

I'm not sure how things are implemented in Chromium but smart paste is a clipboard type, not an extra information attached to the clipboard, and the patch we implement here needs to work on all ports.
I don't see why we can't make it work.
If a port doesn't supply origin data (either because it doesn't understand it or the information isn't in the clipboard), then the origin will be empty.

If Clipboard::origin() != origin of page handling paste (which should never be empty?), only then apply filtering. This seems better than having no understanding of origin at all.

Comment 17 by rniwa@chromium.org, Jul 19 2012

I simply see a point in retaining @formaction when it contains scripts. We should just always strip them. The problem with the proposal you're making is that it'll make the parser aware of the clipboard origin. I don't think that's a wise idea.

Comment 18 by rniwa@chromium.org, Jul 19 2012

s/I simply/I simply don't/
I don't understand--why does the parser need to be aware of the origin?

parse(htmlFromClipboard, isFromSameOrigin ? NoFilter : Filter);

It seems trivial to persist the clipboard origin. And if we can do that, we can easily apply a filtering algorithm based on whether or not its same origin. And if we do that, then it makes the most sense to simply add the @formaction filtering there as well.

Comment 20 by rniwa@chromium.org, Jul 19 2012

Right now, fragment parsing algorithm does one thing regardless of from which origin it came from, and I'd like to keep it that way for simplicity.
We don't need to change the actual HTML fragment parser. We can just do the stripping after it's parsed into a fragment.

Legitimate use: something like Google Sites that allows you to edit pages with a contenteditable iframe. If you cut and pasted parts of it (say, a form) around, shouldn't it still work rather than silently stripping out things?

Comment 22 by rniwa@chromium.org, Jul 19 2012

Sure, but I don't want to be locked into this fragile tagging mechanism. e.g. if there is an app that reads clipboard data and writes it back the same content (e.g. third party clipboard manager), then this same-origin detection fails. Behavior changes like that are hard to understand for ordinary users.

Comment 23 by cdn@chromium.org, Aug 9 2012

Labels: -Pri-0 -Area-Undefined Pri-2 SecSeverity-Low Mstone-23 OS-All SecImpacts-Stable SecImpacts-Beta Area-WebKit
Status: Available
Status: Fixed
Fixed in http://trac.webkit.org/changeset/124520.
The biggest problem I have with annotating the origin is that it won't work with other apps well; e.g. clipboard manages and alike.
Project Member

Comment 26 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 27 by bugdroid1@chromium.org, Jan 18 2013

Labels: Restrict-View-EditIssue
Restrict-View-EditIssue is preferred since it allows anyone who can edit an issue (committers and contributors) to view the bug.
Project Member

Comment 28 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -SecSeverity-Low -Mstone-23 -SecImpacts-Stable -SecImpacts-Beta -Area-WebKit Cr-Content Security-Severity-Low Security-Impact-Stable Security-Impact-Beta M-23 Type-Bug-Security
Project Member

Comment 29 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityTeam -Restrict-View-EditIssue
Project Member

Comment 31 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 32 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 34 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 35 by sheriffbot@chromium.org, Jun 14 2016

Labels: -security_impact-beta
Project Member

Comment 36 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 37 by sheriffbot@chromium.org, Oct 1 2016

Labels: Restrict-View-SecurityNotify
Project Member

Comment 38 by sheriffbot@chromium.org, Oct 2 2016

Labels: -Restrict-View-SecurityNotify
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic

Sign in to add a comment