Maybe I'm naive but what if pushbullet.com was just running a server-side fetch and returning the result? That would bypass CORS, essentially acting as a proxy server.
That's a great question, and it's not limited to Chrome extensions.
In general, for any resources that don't require credentials to access, pushbullet could hypothetically serve them at like pushbullet.com/proxy/gmail.com/favicon or something. But resources requiring credentials are another thing entirely.
In general, the thing that prevents a third-party server from MITM'ing your interactions with a target server is a combination of domain names and SSL certificate. That doesn't prevent a site from trying to get you to let it act as a MITM, but it prevents the site from acting as the MITM while claiming it's something else.
As a concrete example, let's imagine pushbullet.com wanted to act as MITM for your GMail account. If it has your username and password, then (handwaving here; GMail's authentication model is complex) it could do that; it could forge well-crafted requests that look like they come from your browser, and get proper responses back.
But if it doesn't have your username and password, there's not a lot it can do. Your browser won't give pushbullet.com cookies scoped to gmail.com, and if pushbullet tries to ask you for your password, they can only do so much to make it look like GMail's the one asking (SSL certs make it hard for pushbullet to try and forge a GMail front-page with a gmail.com domain). It can still happen, but "user was tricked into ignoring the domain name and gave their password to another service" isn't something web security models can fix.
Thanks for the explanation! I guess I was looking at it more from the perspective of merely making requests (without creds).
My understanding is that if an extension has a wildcard 'https://*' origin listed in its manifest, then it can make cookie-populated requests to any domain that matches the wildcard. That's actually pretty scary from privacy and security perspectives. But I suppose that's part of the reason CWS has moderation in the first place.
Pushbullet doesn’t need a Chrome extension to tell their server to make a web request. But, their server doesn’t have your cookies, so there’s no security concern.
In general, for any resources that don't require credentials to access, pushbullet could hypothetically serve them at like pushbullet.com/proxy/gmail.com/favicon or something. But resources requiring credentials are another thing entirely.
In general, the thing that prevents a third-party server from MITM'ing your interactions with a target server is a combination of domain names and SSL certificate. That doesn't prevent a site from trying to get you to let it act as a MITM, but it prevents the site from acting as the MITM while claiming it's something else.
As a concrete example, let's imagine pushbullet.com wanted to act as MITM for your GMail account. If it has your username and password, then (handwaving here; GMail's authentication model is complex) it could do that; it could forge well-crafted requests that look like they come from your browser, and get proper responses back.
But if it doesn't have your username and password, there's not a lot it can do. Your browser won't give pushbullet.com cookies scoped to gmail.com, and if pushbullet tries to ask you for your password, they can only do so much to make it look like GMail's the one asking (SSL certs make it hard for pushbullet to try and forge a GMail front-page with a gmail.com domain). It can still happen, but "user was tricked into ignoring the domain name and gave their password to another service" isn't something web security models can fix.