Chrome Extension - declarativeNetRequest remove requestHeader "origin" not working - google-chrome-extension

I am trying to remove requestHeader 'origin' using declarativeNetRequest. It's not working as the origin is still being sent with SharePoint rest api call. How do we ensure the rule is being triggered or not? How can we troubleshoot the issue?
Here is my manifest.json and rules.json
{
"short_name": "SPO Helper",
"name": "SPO Helper",
"icons": {
"16": "favicon.ico",
"48": "logo192.png",
"128": "logo512.png"
},
"manifest_version": 3,
"version": "0.0.1",
"background": {
"service_worker": "./static/js/background.js"
},
"content_scripts": [
{
"matches": [
"<all_urls>"
],
"js": [
"content.js"
],
"all_frames": false,
"run_at": "document_end"
}
],
"action": {
"default_title": "SPO Helper"
},
"declarative_net_request": {
"rule_resources": [
{
"id": "ruleset_1",
"enabled": true,
"path": "./rules.json"
}
]
},
"permissions": [
"tabs",
"activeTab",
"cookies",
"scripting",
"declarativeNetRequest",
"declarativeNetRequestFeedback"
],
"host_permissions": [
"https://*.sharepoint.com/"
],
"content_security_policy": {
"extension_pages": "script-src 'self'; object-src 'self'"
}
}
rules.json
[
{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"requestHeaders": [
{
"header": "origin",
"operation": "remove"
}
]
},
"condition" : {
"domains": ["cbgbfoeehbjllcimibeojmpgeoncgjcl"],
"resourceTypes" : ["main_frame", "sub_frame"]
}
}
]

using onRuleMatchedDebug you can check if your rule is being triggered.
you must add the declarativeNetRequestFeedback permission in your manifest.json and add this in your service worker:
chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(function (o) {
console.log('rule matched:', o);
});

Related

Issue with creating an extension NativeMessaging in V3: unknow key path and type

I'm trying to make a Chrome extension that opens a local exe (nativeMEssaging) but when I'm trying to load it I have this error: It doesn't know the key path and type so how can I do?
Here is my manifest.json:
{
"name": "debug.reader.eid",
"description": "Console app use to read an eid and send date to extension",
"path": "C:\\debug.reader.eid\\debug.reader.eid.exe",
"type": "stdio",
"externally_connectable": {
"matches": [
"https://*.extranet-test.debug.be/*",
"*://localhost/*"
]
},
"background": {
"service_worker": "background.js"
},
"author": "debug",
"icons": {
"128": "addon-debug.png"
},
"manifest_version": 3,
"permissions": [
"nativeMessaging"
],
"version": "1.0",
"content_scripts": [
{
"matches": [
"<all_urls>"
],
"js": [
"content.js"
],
"run_at": "document_start"
}
],
"action": {
"default_icon": {
"16": "addon-debug.png"
},
"default_title": "test",
"default_popup": "popup.html"
}
}

Declarative net request rule.json is not working

I'm trying to block a website with a chrome extension that uses the new declarative net request API for Manifest V3, but it isn't working. I have added the permission in the manifest and made sure to add the priority, id, action and conditions, but it still doesn't do anything at all. I am trying to modify the response headers. Here is the applicable part of my manifest.
Manifest.json
"background": {
"service_worker": "background.js"
},
"content_scripts": [
{
"matches": ["https://mail.google.com/*"],
"css": ["base.css"],
"js": [
"jquery-1.10.2.js",
"inboxsdk.js",
"loader.js"
]
},
{
"matches": [
"https://mail.google.com/*",
"https://localhost:1234/*",
"http://localhost:1234/*",
"http://localhost:5000/*"
],
"js": [
"version.js"
]
}
],
"host_permissions": [
"*://*.google.com/*",
"*://*.googleusercontent.com/*",
"https://localhost:1234/*",
"http://localhost:1234/*",
"http://localhost:5000/*"
],
"web_accessible_resources": [{
"resources": [
"icon128.png",
"logo-pink.svg",
"logo-white.png",
"logo.png"
],
"matches": [
"https://mail.google.com/*",
"https://localhost:1234/*",
"http://localhost:1234/*",
"http://localhost:5000/*"
]
}],
"declarative_net_request": {
"rule_resources": [{
"id": "ruleset_1",
"enabled": true,
"path": "rules.json"
}]
},
"permissions": [
"scripting",
"declarativeNetRequest",
"declarativeNetRequestWithHostAccess",
"declarativeNetRequestFeedback"
],
"manifest_version": 3
}
rules.json
[
{
"id": 1,
"priority": 1,
"action": {
"type": "modifyHeaders",
"responseHeaders": [
{
"header": "script-src",
"operation": "set",
"value": "script-src https://localhost:7000"
}
]
},
"condition": {
"regexFilter": "/content-security-policy/i",
"resourceTypes": [
"main_frame",
"sub_frame",
"script",
"object",
"xmlhttprequest",
"csp_report"
]
}
}
]
Is there any Idea how to test whether the headers are being modified or not
There are several problems.
regexFilter doesn't support JS RegExp literal syntax.
Solution: Remove / and the i flag.
regexFilter is for the URL of the request, not for a header name. Currently there's no way to match requests by checking a header.
Solution: Remove regexFilter or use a valid expression for the URL or use other types of conditions like urlFilter or requestDomains, see the documentation.
"header": "script-src" should be "header": "content-security-policy"
Example:
[{
"id": 1,
"action": {
"type": "modifyHeaders",
"responseHeaders": [{
"header": "content-security-policy",
"operation": "set",
"value": "script-src https://localhost:7000"
}]
},
"condition": {
"requestDomains": ["example.com"],
"resourceTypes": ["main_frame", "sub_frame"]
}
}]
P.S. To change script-src it's sufficient to process main_frame and sub_frame types.

Why does URL redirect permission work in Chrome Manifest v2 but not v3?

I'm trying to redirect a URL using the Chrome declarativeWebRequest API but it does not work.
The match pattern in the "permissions" key worked with Manifest V2 but it's now throwing a Permission '*://www.youtube.com/*' is unknown or URL pattern is malformed error in V3.
manifest.json:
{
"manifest_version": 3,
"name": "Redirect Test",
"version": "0.0.1",
"permissions": [
"declarativeNetRequest",
"*://www.youtube.com/*"
],
"host_permissions": [
"*://www.youtube.com/*"
],
"declarative_net_request": {
"rule_resources": [
{
"id": "1",
"enabled": true,
"path": "rules.json"
}
]
}
}
rules.json:
[
{
"id": 1,
"priority": 1,
"action": {
"type": "redirect",
"redirect": {"url": "https://www.google.com"}
},
"condition": {
"urlFilter": "*://www.youtube.com/*",
"resourceTypes": [
"main_frame"
]
}
}
]
I'm using Chrome 88.0.4324.104
The manifest documentation for declarative net requests at the time of posting isn't exactly accurate.
This is the
Permissions key in manifest.json from the documentation:
"permissions": [
"declarativeNetRequest",
"declarativeNetRequestFeedback",
"*://example.com/*"
],
However, the site should be specified in just host_permissions instead:
"host_permissions": [
"*://example.com/*"
],
It should be noted that this explicit declaration is only necessary if action.redirect is specified like in this example:
{
"id": 1,
"priority": 3,
"action": {
"type": "redirect",
"redirect": {
"regexSubstitution": "www.youtube.com/embed/"
}
},
"condition": {
"regexFilter": "(www\\.youtube\\.com\/watch\\?v=)",
"resourceTypes": [
"main_frame"
]
}
}

chrome.tabs.executeScript not working on amazon.com

the callback function never get called on amazon product pages, eg:
https://www.amazon.com/AmazonBasics-0188-3-PACK-Multipurpose-Scissors/dp/B01BRGU8R0/ref=sr_1_13?dchild=1&keywords=amazonbasics&pf_rd_p=9349ffb9-3aaa-476f-8532-6a4a5c3da3e7&pf_rd_r=14VHDM69CE2KAX6H70ED&qid=1596591703&sr=8-13
chrome.tabs.executeScript(tabId,
{
code: script,
allFrames: true,
},
function (result) {
console.log('run script result:', result);
sendReplyToQuicker(true, "", result, msg.serial);
})
as simple as only one line code will not getting result:
1;
When run this code on other site:
When run this code on amazon page, callback function nerver called:
The extension manifest.json (full code):
{
"name": "Quicker Chrome Connector",
"version": "0.3.1",
"manifest_version": 2,
"description": "Native message connector with Quicker application",
"background": {
"scripts": [
"main.js"
],
"persistent": false
},
"content_scripts": [
{
"matches": [
"<all_urls>"
],
"js": [
"jquery-3.5.1.min.js",
"content.js"
],
"all_frames": true
}
],
"icons": {
"128": "icon-128.png"
},
"browser_action": {
"default_popup": "popup.html"
},
"permissions": [
"nativeMessaging",
"tabs",
"<all_urls>",
"debugger"
],
"optional_permissions":[
"bookmarks",
"browsingData",
"topSites",
"downloads",
"history",
"pageCapture",
"cookies",
"sessions",
"management"
],
"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",
"homepage_url": "https://getquicker.net"
}

Why does my manifest.json trigger a lengthly review due to Broad Host Permissions?

The chrome webstore flags my extension as having "Broad Host Permissions", but I cannot figure out what in my manifest.json is causing this result.
{
"name": "AudioEye Smart Remediation Builder",
"description": "Solve any issue of accessibility without writing code. Select elements, apply changes, and fix the web.",
"devtools_page": "src/main.html",
"version": "1.31.0",
"content_security_policy": "script-src 'self' https://myother.website.com/scripts/loader.js https://myotherother.website.com/somescript.js; object-src 'self'",
"author": "AudioEye",
"background": {
"scripts": [
"src/background.bundle.js"
]
},
"browser_action": {
"default_icon": {
"16": "icons/ae16.png",
"48": "icons/ae48.png",
"128": "icons/ae128.png"
},
"default_popup": "src/popup.html"
},
"content_scripts": [
{
"matches": [
"*://my.website.com/*"
],
"run_at": "document_end",
"all_frames": true,
"js": [
"src/installDefinition.js"
]
}
],
"externally_connectable": {
"matches": [
"*://my.website.com/*"
]
},
"icons": {
"16": "icons/ae16.png",
"48": "icons/ae48.png",
"128": "icons/ae128.png"
},
"manifest_version": 2,
"optional_permissions": [
"http://*/*",
"https://*/*",
"tabs"
],
"permissions": [
"cookies",
"webNavigation",
"activeTab",
"storage",
"contextMenus"
],
"web_accessible_resources": [
"src/inspected-window.bundle.js",
"src/smart-remediation-metadata.js"
]
}
I only use a broad match in the optional_permissions object, which gives the user explicit ability to allow/deny the permissions on each page they visit.
Why does my extension require a two week review due to broad host permissions?

Resources