Possible security issue with access of commandline API scope in content script
Reported by
wascrisr...@gmail.com,
Oct 28 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36 Steps to reproduce the problem: 1. Follow example here at https://developer.chrome.com/extensions/devtools#selected-element. 2. See how commandline API scope (like $_ and $0, and so on) can be accessed by the function `setSelectedElement`, which is defined only in a content script scope, when that function is called by `devtools.inspectedWindow.eval`, passing in variables like $0, from commandline API scope (inspected page execution context), with the `useContextScriptContext` flag true. 3. Consider what is going on. What is the expected behavior? I do not know the internals of how this works, but it seems to me that, in order for $_ or $0 ( or others ) to be accessible to the function, then they have to be accessible within the content script context, somehow. What went wrong? This could be a security issue, but probably isn't, because I simply don't understand the internals. Did this work before? N/A Chrome version: 62.0.3202.75 Channel: stable OS Version: 10.0 Flash Version: Feel free to point me to the relevant place in the source code that explains how this execution works, if I'm mistaken about this being some issue. I don't think it would be a security issue because this is one of those "intersections" where security is obviously a thing and people would have already thought about it. Just in case there was something, and as a chance for me to learn, I'm submitting it.
,
Oct 31 2017
wascrisreally@ - Thanks for filing the issue...!! Could you please provide a sample test file to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
Oct 31 2017
Sorry no. Because I have not experienced any security issue with this, but I noticed something in the docs which might be an issue, and my intent in filing it was to get someone more experienced to reflect on if it was a problem or not. What I noticed was, as I wrote in the file, it seems you can access (as per the design in the linked docs) commandline API from content scripts, and it wasn't obvious how this was sand-boxed, and I wondered if there could be any vulnerabilities around that. That's all this issue filing is about.
,
Oct 31 2017
Thank you for providing more feedback. Adding requester "krajshree@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
,
Nov 1 2017
The issue seems to be out of TE-scope as the user want to understand the issue from unit level or code level as per comment #3. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team. Thanks...!!
,
Nov 7 2017
,
Dec 4 2017
Thanks for your report! Command line API provides the same objects as you can get from JavaScript and we do not bypass any security checks for this API. If you could provide more detailed attack script then feel free to reopen this issue. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by manoranj...@chromium.org
, Oct 30 2017