The "If the attacker gets the printed file" is a big obstacle placing this within the realm of social engineering attacks, but it's interesting that the generated file contains the iframe content.

thestig - Does this fall into the category of "working as intended"?  Have the reporters invented "printjacking?"

If a site allows sensitive data to be framed in this way, doing a drag/drop clickjacking attack feels more compelling than this vector. This one seems more like  Issue 608669 , as yet another case where the user might be tricked into uploading something that contains private data.

We believe that the site is not to blame as it has CORS. In fact, Chrome blocks a screenshot why not this invisible iframe?

For example, a HTTP Redirect is a valid attack of phishing, even using social engineering, with this issue ocurrs the same.


We consider it a security issue, because it is a valid attack payload.
 

Re #5: I'm not sure what you mean when you say "blocks a screenshot"?

Nor do I understand what "A HTTP redirect is a valid attack of phishing" but unless that has anything to do with the issue at hand, we ought not discuss it here.

The question isn't really whether this is an "attack" (sure, it is) but rather whether it's practical for the browser to do anything to prevent the user from inadvertently releasing their own information in this scenario, and whether equivalent vectors broadly exist. For instance, a user could be enticed to Save a page containing foreign iframes to disk, then upload the resulting files to the server, unknowingly sending it "secret" data. Etc.

First of all, i love the term "printjacking"

When i say "blocks a screenshot" y try to say that:

Previous to this attack vector, i tried to do the same effect as printing, using html2canvas, (screen -> capture -> send to other server) and does not work, iframe are empty in screenshot capture by js (GOOD JOB!)

And respect to the last question, 

The malware evolves so quickly, and you have to get ahead. at the end, its the user who runs the browser, and you have to put it as easy as possible.

I think many people are not aware of the problem that might have printed an airline ticket or a gift voucher

Something new about this?

creis/nasko: Is this something that belong in the realm of OOPIF?

I don't think OOPIF will help much here unless we explicitly design this to not happen. The whole point of printing is to actually produce a visual output of all content on the screen, regardless of origin. This is contrary to the exposed APIs, which the reporter already tried and failed, since they are origin restricted.

I agree with #6 that this is equivalent to save-page-as and uploading the result. Even if we could prevent the iframe from being printed, the save-page-as will be equivalent attack vector and there will be nothing we can do to solve it, as it is working as expected.

Am I missing something here?

I'm not really sure what the suggested defense is here. We're printing a document, so there's a reasonable expectation that even cross-origin subframes will be included as part of the print output.

I think a user is more accustomed to working with office documents than with html, in addition web page (by javascript) I doubt that I can invoke the "save as" html option. Print deception is completely feasible

Yes, but just printing the page isn't sufficient to leak the data back to the attacker.  (If it were, that would be a large concern.)  The user has to upload or otherwise send the printed output to the attacker, which is a fairly large mitigating factor.

The attack in the video is nicely polished and doesn't show what's being stolen even if the user opens the printed file, but I tend to agree with others here that it's not the browser's job to prevent the user from printing pages with cross-origin iframes (or from uploading files in general).

nparker@: Maybe there's some behaviors here SafeBrowsing could be on the lookout for to flag as phishing pages?

This is clever, but I think not likely to ever be practical for any mass credential stealing campaign, given the high friction. And I don't think there's much Safe Browsing can do here to detect it explicitly (looking for image-over-iframe in printed docs would likely be all FP's).

In firefox it is not reproducible and it's obvious that the print has to be about visible content. From our point of view, it is an issue that requires social engineering like any attack of phishing or xss (even).

We agree that it is fixed by setting a correct iframe directive. But then, what is xss auditor for? And the mixed content HTTP/HTTPS? Both measures shoudn't be implemented by the browser. They can be fixed if the web is programmed well in the same way? What distinguishes this case?

But if you don't consider it important, then we will proceed to make the disclosure to the community. Thank you so much for everything.

Won't Fix, for the reasons described in #6 and #14.

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