Inquiry Regarding Security of Native API Calls in Chromium Extensions

[Wx Gopher]

Hi,

I just get started on a Chromium project, and we are currently conducting research on issues related to extension security. We hope to clarify the following points:

We understand that Chrome extensions have several features, such as the ability to call APIs (called "features"). However, one can imagine that if the render process is not trusted, calling an API could pose a security risk. How does the Chrome browser process handle relevant authentication and isolation mechanisms? We noticed that the frame.mojom file mentions that context types cannot be used for secure authentication. However, at the entry point for calling the API (which I think is SimpleFeature::IsAvailableToContextImpl), the context authentication method is used. Could you please explain how the security assurance mechanism works in this case?

I am not sure if this is the appropriate place to ask these questions, so please forgive any disturbances. I look forward to your kind response.

[Dave Tapuska]

You likely are looking for the enforcement in the browser process here.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/3d3b4e17-43e4-46d0-8eff-d2efcf3a388dn%40chromium.org.

[Dave Tapuska]

>Can we safely claim that moving content script to background script?

A poorly implemented extension even on the correct architecture design could be worse. Communication between a content script and an extension (whether it be a background script or service worker) still represents an IPC boundary and if communication isn't validated on the more trusted process side you can have problems, see the guidance you highlighted.

In terms of the extension process itself, you load the extension and you choose what code is run in it specifically (arbitrary external scripts aren't allowed). So you should be able to trust the code in the extension process.

Hopefully that answers your questions.

dave.

On Wed, Jan 31, 2024 at 6:02 AM Wx Gopher <wxgu...@gmail.com> wrote:

Hi Dave,

Yes, that was exactly what we were looking for! 

I'd like to post a follow-up question that I hope you don't mind:

In process_map.cc::160, we assume any process (including a compromised renderer) can host content script. 

We wonder how can we stay secure if our extension requires content script actions (injecting scripts into webpage and invoking native C++ calls) to function? 

I could think of using the extension service worker (as we do not have the direct access to DOM, this might require a bit engineering).

Can we safely claim that moving content script to background script (as a service worker) is safer/better? 

(We did find a discussion here claiming this, because 1) we assume extensions should not execute malicious script and 2) the existence of OOP iFrame)

Thanks,

[Wx Gopher]

Hi Dave,

Yes, that was exactly what we were looking for! 

I'd like to post a follow-up question that I hope you don't mind:

In process_map.cc::160, we assume any process (including a compromised renderer) can host content script. 

We wonder how can we stay secure if our extension requires content script actions (injecting scripts into webpage and invoking native C++ calls) to function? 

I could think of using the extension service worker (as we do not have the direct access to DOM, this might require a bit engineering).

Can we safely claim that moving content script to background script (as a service worker) is safer/better? 

(We did find a discussion here claiming this, because 1) we assume extensions should not execute malicious script and 2) the existence of OOP iFrame)

Thanks,

On Wednesday, January 31, 2024 at 2:33:52 a.m. UTC+8 Dave Tapuska wrote:

[Wx Gopher]

Yeah that helped a lot!

Cheers,