6 ms·

Does your browser extension really need to access localhost/* - as in, port 80 on my local machine? That would make me very uncomfortable about installing the e

by thorum 6y ago

Does your browser extension really need to access localhost/* - as in, port 80 on my local machine? That would make me very uncomfortable about installing the extension. Would it be possible to restrict the extension to accessing a specific port or endpoint that is used by PushBullet?

raegis 6y ago
Right, this suggests the app either (1) runs a web server on the client device, or (2) wants to access a third party webserver on the client device. I don't know if this is common. Or maybe I don't know/understand why this is needed. Also, isn't allowing access to the app's website the same as allowing access to any website? Can't you just redirect?
- shadowgovt 6y ago
  Redirects shouldn't compromise the CORS / XSRF security model, which is the key item of concern from a Chrome Extension standpoint. Like if pushbullet.com redirects to foo.com, the crex is now looking at the foo.com page and its permissions will apply accordingly.
  - lostinroutine 6y ago
    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.
    - wolfgang42 6y ago
      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.
    - shadowgovt 6y ago
      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.
      - lostinroutine 6y ago
        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://*' 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.
stingraycharles 6y ago
This is a very good suggestion, and could very well be the root cause of these rejections. It’s a potential security vulnerability that is triggering the violation. I hope the author sees thorum’s comment!
Guzba 6y ago
We use localhost to communicate with our desktop application which is commonly installed alongside our extension by users. An example of how we use this communication channel is preventing both our extension and desktop apps from showing notifications on the same computer. Our apps are all about notifications so this would get unacceptable very fast. We ping our local desktop app via localhost to see if it can manage the notification, and show it with our extension if it isn't running. Maybe if we limit it to just the local port we use? Seems like it can't hurt to try that too.
- paulirwin 6y ago
  I believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/nativeMessaging
  - rosywoozlechan 6y ago
    This may be well what needs to change, but in any case the message from Google should have been explicit about it instead of the dev involved having to create a blog post, hope it gets traction on HN and that someone here knows what the problem is.
    - maartn 6y ago
      the docs are pretty explicit about it
      - ldiracdelta 6y ago
        But not their email.
    - nolok 6y ago
      Yes and no, I would be glad if Google in general could get much much better at this but in this specific case I'm sorry but http://* http://* and localhost access is not a hidden small thing.
  - 6y ago
jbritton 6y ago
I have a desktop application that communicates on localhost. I recently read that it’s advisable for the server to bind port 0 and then a free port will be chosen to avoid conflicts. I guess the port could be a configurable option. Although for my users it would just add confusion. I can see why the security conscious would not like a dynamic port though.

by thorum 6y ago

raegis 6y ago

Right, this suggests the app either (1) runs a web server on the client device, or (2) wants to access a third party webserver on the client device. I don't know if this is common. Or maybe I don't know/understand why this is needed. Also, isn't allowing access to the app's website the same as allowing access to any website? Can't you just redirect?

shadowgovt 6y ago
Redirects shouldn't compromise the CORS / XSRF security model, which is the key item of concern from a Chrome Extension standpoint. Like if pushbullet.com redirects to foo.com, the crex is now looking at the foo.com page and its permissions will apply accordingly.
- lostinroutine 6y ago
  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.
  - wolfgang42 6y ago
    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.
  - shadowgovt 6y ago
    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.
    - lostinroutine 6y ago
      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://*' 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.

stingraycharles 6y ago

This is a very good suggestion, and could very well be the root cause of these rejections. It’s a potential security vulnerability that is triggering the violation. I hope the author sees thorum’s comment!

Guzba 6y ago

We use localhost to communicate with our desktop application which is commonly installed alongside our extension by users. An example of how we use this communication channel is preventing both our extension and desktop apps from showing notifications on the same computer. Our apps are all about notifications so this would get unacceptable very fast. We ping our local desktop app via localhost to see if it can manage the notification, and show it with our extension if it isn't running. Maybe if we limit it to just the local port we use? Seems like it can't hurt to try that too.

paulirwin 6y ago
I believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/nativeMessaging
- rosywoozlechan 6y ago
  This may be well what needs to change, but in any case the message from Google should have been explicit about it instead of the dev involved having to create a blog post, hope it gets traction on HN and that someone here knows what the problem is.
  - maartn 6y ago
    the docs are pretty explicit about it
    - ldiracdelta 6y ago
      But not their email.
  - nolok 6y ago
    Yes and no, I would be glad if Google in general could get much much better at this but in this specific case I'm sorry but http://* http://* and localhost access is not a hidden small thing.
- 6y ago

jbritton 6y ago

I have a desktop application that communicates on localhost. I recently read that it’s advisable for the server to bind port 0 and then a free port will be chosen to avoid conflicts. I guess the port could be a configurable option. Although for my users it would just add confusion. I can see why the security conscious would not like a dynamic port though.