We have implemented CSP policy in report-only mode and as part of violations received we have got a violation in "connect-src" directive where the blocked URI is mentioned as "properties".
It is difficult to identify what needs to be whitelisted and what is getting blocked. Mentioning the JSON below for reference.
Note: Violations were specific to Android Chrome Browser
JSON:
{
csp-report":
{
"document-uri": "https://*************",
"effective-directive": "connect-src",
"original-policy": "*policy*",
"blocked-uri": "properties",
"line-number": 2,
"column-number": 535042,
"source-file": "https://**************",
"status-code": 200
}
}
Just wanted to understand why this violation is coming up.
Usually such violations related to browser specific functions or browser extensions. So, this is not real URI blocked but something that browser tried to do.
In most cases such violations can be ignored until you get exact complains from users.
Related
I found chrome.declarativeNetRequest only supports static rules, What I want is to call some custom methods before actions like redirect/request. I haven't found a solution so far. I'm not sure if I can still do this under the Manifest V3.
There are two usecases for my extension.
Before the redirect, I need to execute custom method.
chrome.webRequest.onBeforeRequest.addListener(
function(requestDetails) {
//
// I can get id from requestDetails.url,
// then do some custom business logic.
//
custom_function(requestDetails.url);
return {redirectUrl:"javascript:"};
},
{urls: [ "url_pattern?id=*" ]},
["blocking"]
);
Before some request, I want add/modify requestHeaders according to the user's browser.
chrome.webRequest.onBeforeSendHeaders.addListener(
function (details) {
details.requestHeaders.push({
"name": "User-Agent",
"value": navigator.userAgent + "version_1.0.0"
});
return {requestHeaders: details.requestHeaders};
},
{
urls: ["*://url_pattern"],
types: ["xmlhttprequest"]
},
["blocking", "requestHeaders"]
);
#wOxxOm Thank you very much for your patient answer !
I prefer to spinner.html. But I have another problem.
I can't set the regexSubstitution to the extension address,
I can use the extensionPath, but the corresponding capture groups doesn't work here.
"regexFilter": "google.com*"
The following are all incorrect:
can't use the corresponding capture groups.
"extensionPath": "/spinner.html?url=\\0"
can't use the extension's address.
"regexSubstitution": "spinner.html?url=\\0"
Is my configuration incorrect?
Adding/deleting headers can only accept static values and it's shown in the official example.
Conditionally adding/deleting/modifying headers based on response headers is tracked in https://crbug.com/1141166.
Nontrivial transformations that exceed the functionality of the actions listed in the documentation naturally cannot be re-implemented.
When https://crbug.com/1262147 is fixed we will be able to define a declarativeNetRequest rule to redirect to a page inside your extension via regexSubstitution or extensionPath and append the original URL as a parameter. This page will act as an interstitial, it will display some kind of UI or a simple progress spinner, process the URL parameters, and redirect the current tab to another URL.
In many cases this approach would introduce flicker and unnecessary visual fuss while the interstitial is displayed shortly, thus frustrating users who will likely abandon using such extensions altogether. Chromium team members who work on extensions seem to think this obscene workaround is acceptable so it's likely they'll roll with it, see also https://crbug.com/1013582.
Use the observational webRequest (without 'blocking' parameter) and chrome.tabs.update to redirect the tab. The downside is that the original request will be sent to the remote server. And this approach obviously won't work for iframes, to redirect those you'll have to inject/declare a content script, to which your webRequest listener would send a message with a frameId parameter.
Keep a visible tab with an html page from your extension, and use the blocking chrome.webRequest inside its scripts. It's a terrible UX, of course, even though endorsed by the Chromium's extensions team, with many extensions using this kludge the user's browsers will have to keep a lot of such tabs open.
P.S. The blocking webRequest will be still available for force-installed extensions via policies, but it's not something most users would be willing to use.
When i debug javaScript on devtool.
chrome.runtime
see "http://www.qq.com",it show:
chrome.runtime is undefined. see http preview.
But when i debug it on https site (https://www.qq.com ).it work fine. see https preview.
tips: all script run on top frame.
Can i change "chorme:flags" to enable it ?
i got why now.
"chrome.runtime.sendMessage" not exist when no extension installed.---since chrome 66+.
see:https://bugs.chromium.org/p/chromium/issues/detail?id=835287
Comment 29 by rdevlin....#chromium.org, Apr 25 For at least some of
these cases from the duped bugs, I think this was caused by revision
39f8939309fe39bccc17fa1280b6c7f25c411947. This modified the
externally_connectable property of the cryptotoken component extension
(automatically built into Chrome) to only accept incoming connections
from https URLs, whereas previously it was all URLs. When it was set
to all URLs, chrome.runtime.sendMessage would always be available
because any URL could potentially send a message to the cryptotoken
component extension.
However, this is working as intended. The cryptotoken extension only
accepts connections from https origins (so any others would be
ignored), and sending a message to any other extension would require
the receiving extension to list the URL in the externally_connectable
options. Additionally, this means that before, any extension relying
on this behavior would likely have failed to send the message, but
done so asynchronously (once the message failed to find an appropriate
receiver) rather than synchronously (since runtime is undefined). If
the extension lists the URL in externally_connectable, then
chrome.runtime should still be present. If the extension does not
list the site in externally_connectable, then chrome.runtime not being
available is intended behavior.
Is there any case in which chrome.runtime is undefined for
non-sandboxed chrome-extension:// pages, or for web pages where an
installed extension specifies that web page's URL in the
externally_connectable field of the manifest? If so, please attach an
extension that demonstrates this issue. If not, this sounds like it's
WAI.
fix: add one extionsion with:manifest.
"externally_connectable": {
"ids": [
"*"
],
"matches": [
"http://test.yoursite.in:9090/*",
"*://*.chromium.org/*"
]
},
thinks all.
I'm building a Chrome Extension that interacts with an API that I wish to protect using Google recatcha, as I'm intending for it to be used beyond just the Chrome Extension. The API side is working, correctly verifying a recaptcha response with Google, however, displaying the recatcha widget inside the extension's browser action window is resulting in the following javascript error:
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('chrome-extension://pjhcgfibbbmibojnlkgjejaojpokgldl:80') does not match the recipient window's origin ('chrome-extension://pjhcgfibbbmibojnlkgjejaojpokgldl').
which is generated in recaptcha_en.js at the line:
(a.window || ne(a.Tg)).postMessage(JSON.stringify({
message: c || null ,
messageType: b
}), Zj(a.path));
The problem seems to be that the value of a.path is chrome-extension://pjhcgfibbbmibojnlkgjejaojpokgldl:80 but I don't know how I can affect this value.
The result of this error is that the recaptcha widget displays a message saying:
Please upgrade to a supported browser to get a reCAPTCHA challenge.
I'm displaying the widget via the auto render method, but have also tried the explicit method which results in the same error. For info, I'm using the following content_security_policy:
script-src 'self' https://*.google.com https://*.gstatic.com; object-src 'self'
Is there any way I can get this to work in my extension? And if not, what is the best alternative method for integrating recaptcha?
In recaptcha v3
manifest.json
"content_security_policy": "script-src 'self' https://.google.com https://.gstatic.com; object-src 'self'"
ADD CHROME EXTENCION ID TO ALLOWED DOMAINS IN RECAPTCHA ADMIN CONSOLE
chrome-extension://aailnablglhloogfnpkgddnjjfimhhhg
so you just put "aailnablglhloogfnpkgddnjjfimhhhg" without chrome-extension://
I have a built a Music Player Component with ember consuming the SoundCloud Api
Suddenly in Chrome i start getting this error notification in my console anytime i play a song in my application plus the songs does not play.
See the error
Report Only] Refused to connect to 'https://ec-media.sndcdn.com/YEqcIen0Pkq6.128.mp3?f10880d39085a94a0418a7ef69…fe493d321fb2a6a96186dcb97beab08f3cea5ad8b42d543c3edc7371f0eb5b2b00ba96395e' because it violates the following Content Security Policy directive: "connect-src 'self' data: cf-media.sndcdn.com ws://localhost:35729 ws://0.0.0.0:35729 http://0.0.0.0:4200/csp-report".
It is complaining about the "connect-src 'self' data: cf-media.sndcdn.com ws://localhost:35729 ws://0.0.0.0:35729 http://0.0.0.0:4200/csp-report".*"
This is because after bit of research i have modified in environment.js the content security policy like this
contentSecurityPolicy: {
// 'connect-src': "'self' data: https://cf-media.sndcdn.com",
'connect-src': "'self' data: cf-media.sndcdn.com",
},
Before my change the problem was the same and this was the console log error
So my question is, how can i give these permission in order to not violate the
Content Security Policy directive for 'connect-src'? What other action have i to take now?
Again the problem is only in Chrome
It looks like your property is not well-formed. Try:
contentSecurityPolicy: {
'connect-src': "'self' https://ec-media.sndcdn.com",
},
To more clearly address the content security policy and avoid further conflicts with more subdomains, I suggest changing it to be:
contentSecurityPolicy: {
'connect-src': "'self' https://*.sndcdn.com",
},
We run an extension that requires fetching and searching for data on multiple websites.
We have been using cross-origin XMLHttpRequests using Jquery, and have not faced an issue until now.
The asynchronous requests are being executed successfully. This has been the case even though we have not explicitly requested cross-origin permissions as suggested here: https://developer.chrome.com/extensions/xhr
This is what the relevant portions of our manifest currently look like:
{
"background" : {
"scripts": ["background.js"]
},
"permissions" : ["storage" ],
"content_scripts" : [
{
"matches" : ["<all_urls>"],
"js" : [ "jquery-2.0.0.min.js","jquery-ui-1.10.3.custom.min.js","date.js",
"file1.js","file2.js",
"fileN.js"],
"run_at" : "document_idle",
"all_frames" : false
},
],
"content_security_policy": "script-src 'self' https://ssl.google-analytics.com; object-src 'self'",
"web_accessible_resources" : [ "icona.png" , "iconb.png","iconc.png"],
"manifest_version": 2
}
Even though the permissions do not explicitly request access to urls from which data is asynchronously fetched, the extension has worked fine.
Off late, we have had a few complaints from users that the extension no longer works and no data is being displayed. We have not been able to replicate this issue in Chrome on Linux (Version 34.0.1847.132). The users who seem to be facing this issue seem to be using Mac OS X or, less frequently, Windows.
We cannot figure out why this issue is OS specific, or if that's a curious correlation.
If the problem is indeed one of wrong permissions, can we set the permission to
["http://*/","https://*/"]
without having the extension disabled automatically for manual re-enabling by the user?
We already require permissions for all urls through "matches" : ["<all_urls>"] Does this ensure that the addition of permissions as above will not trigger automatic disabling of the extension?
Chrome extensions allow for cross-origin requests, but you have to declare the hosts you want to access in the permissions section of your manifest. The matches section of content scripts shouldn't give you host permissions.
You should add host permissions to your manifest. I don't know what will happen on update. Considering that the user was already prompted to allow your extension access to all their web data, maybe your extension won't be disabled on update. You can simply test that by creating a testers only extension on the webstore with your original version, install it, update it, and see what happens.