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

Issue 779331 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Possible security issue with access of commandline API scope in content script

Reported by wascrisr...@gmail.com, Oct 28 2017

Issue description

UserAgent: 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.
 
Labels: Needs-Triage-M62
Cc: krajshree@chromium.org
Labels: Needs-Feedback
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...!!

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.
Project Member

Comment 4 by sheriffbot@chromium.org, Oct 31 2017

Labels: -Needs-Feedback
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
Labels: TE-NeedsTriageHelp
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...!!

Comment 6 by kozy@chromium.org, Nov 7 2017

Owner: kozy@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 7 by kozy@chromium.org, Dec 4 2017

Status: WontFix (was: Assigned)
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