Please supply the files necessary to reproduce the issue that you are describing. 

I /think/ you're saying that a file that contains a JavaScript: URL allows execution of the script in that JavaScript URL. That would not represent a security vulnerability in the browser, which is designed to safely handle the execution of scripts within a file's context.

This is poc, only need to join the hyperlink to write javascript: alert () just fine

Deleted: poc.pptx 27.9 KB

poc.pptx 27.9 KB Download

Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I can reproduce script execution by clicking on the link in the file.

This doesn't seem to be interesting from an end-user security POV-- it's generally expected behavior that clicking on a link within a document loaded in the browser may result in the execution of script inside the browser's sandbox.

If you update your http://xiaopigfly.com/test.pptx POC file to replace 

   alert(1) 

with 

   alert(document.domain)


, what domain is shown in the alert? If it's "xiaopigfly.com", then this becomes mildly interesting insofar as it means that some websites may be vulnerable to "Stored XSS" attacks because the site owner does not expect that serving an untrusted PPTX file will allow script execution from their domain serving the untrusted PPTX.

xiaopigfly@gmail.com, could you reply to elawrence@'s question in #4?
Sorry, I don't have an iOS device to repro. 

hi,jialiul@chromium.org  and elawrence@chromium.org

Now that I have updated pptx, visit the address: http://xiaopigfly.com/poc.pptx 。 
 

Deleted: WX20171126-093448@2x.png 70.2 KB

	WX20171126-093448@2x.png 70.2 KB View Download

Thank you for providing more feedback. Adding requester "jialiul@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Thanks xiaopigfly@!
elawrence@, what do you think?  I feel there's very little can be improved here. 

The empty string here suggests that the code is running in an anonymous origin rather than in the origin of the hosting website. This suggests that this was intentionally mitigated and that this isn't a vector for stored XSS.

(It may be worthwhile to have an iOS dev familiar with this area take a look to confirm that there's nothing of interest here-- I was not previously aware that Chrome on iOS was able to preview documents in this manner. Presumably this is something that the underlying WkWebView provides?)

In iOS11 Safari, the script also executes, but shows a GUID for the document.domain value, also strongly suggesting that webkit is pushing the preview into an anonymous origin.

Thanks elawrence! 
per #9 and #10, I'll mark this as Won't fix (work as intended.) 

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