-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for "matches" and "js" keys from "content_scripts" in the chrome_extensions table #6140
Support for "matches" and "js" keys from "content_scripts" in the chrome_extensions table #6140
Conversation
const std::vector<std::vector<std::string>> matches_list = | ||
genContentScriptDetail(kMatchesKey, tree); | ||
|
||
for (int i = 0; i < script_list.size(); i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to test this implementation locally but I think we should explore an alternative. Instead of having the existing table with duplicated rows we should introduce a new table that reports these matches. Then a user can join them together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree. I'll roll this implementation into a new table. It looks like the Chrome extension ID is a decent candidate for joins.
da23681
to
aa121dd
Compare
Okay, I've refactored the features in this PR into a new table: Example:
|
The failure is unrelated to this PR, it's test_osqueryd.py and the relative python framework that needs a heavy refactor. |
d6b0209
to
d854e73
Compare
Is this ready for review? |
Yep! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe consider a different approach to genChromeBasedExtensionContentScripts
and have it expect a path
to an extension. You'll then avoid enumerating users and extensions twice as I assume folks will always want to join this table against chrome_extensions
?
If that is not the case then perhaps path
is still a good option if someone does join, you can optimize the search to only parse that extension.
specs/chrome_extensions.table
Outdated
@@ -16,6 +16,8 @@ schema([ | |||
Column("path", TEXT, "Path to extension folder"), | |||
Column("permissions", TEXT, "The permissions required by the extension"), | |||
Column("optional_permissions", TEXT, "The permissions optionally required by the extensions"), | |||
Column("script", TEXT, "The content script used by the extensions"), | |||
Column("match", TEXT, "The URL associated with the content script."), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick, inconsistent punctuation
I can provide an example of what I mean if that helps, just LMK! |
Yes, that would be greatly appreciated 😄 |
d854e73
to
f4aa5bb
Compare
c270f96
to
07791ef
Compare
Content scripts are able to pass information to the extensions from web pages that the browser visits. Matches specify which of these pages the content scripts will be allowed to access. This PR adds support for matches and scripts to the
chrome_extensions table
.Example: