Hacker News Reader

Comment by thorum | Hacker News Reader

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?

View on HN

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.

I believe you're supposed to use Native Messaging for that: https://developer.chrome.com/extensions/nativeMessaging

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.

the docs are pretty explicit about it

But not their email.

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://* and localhost access is not a hidden small thing.

Native messaging is extremely broken and has bad documentation. I never got replies to my bug reports about it and gave up and just used websockets.

Out of curiosity, what were the problems you ran into with native messaging?

So native messaging is fundamentally about opening a named pipe to a child process managed by the browser. I found that the pipe would silently break or time out. In the former scenario, the app was running but could no longer exchange native messages with the browser or extensions - chrome was just ignoring the pipe traffic. In practice I was able to use native messaging to spawn the executable but to actually talk with it I needed to use a websocket, kind of defeating the point.

I initially assumed I was doing something wrong but after a week or so experimenting with simple test cases I could not get it to work. Maybe it works fine on Linux and Mac but not Windows.

I initially assumed I was doing something wrong

We should probably have a weekly HN column with that title.

You can probably get around this by setting up some DNS like localhost.pushbullet.com -> 127.0.0.1. It's probably not in the spirit of what they're asking for though, if it is indeed the problem.

If you have a half-decent router or firewall, this won’t work from outside the network.

Huh? What kind of router would filter out 127.x responses by default? Also, this wouldn't work with DoH enabled which is where we're heading with browsers.

It’s about negating security mechanisms that rely on the request/target "origin".

My router (AVM FRITZ!Box) blocks DNS results for anything in the LAN range, as part of protection against rebind attacks.

But actually 127.0.0.1 seems unaffected:

    $ host 127.0.0.1.xip.io
    127.0.0.1.xip.io has address 127.0.0.1
    $ host 192.168.1.1.xip.io
    # no result

Have you seen this fail? Drop box and spotify use this same trick, i assume it had wide support.

It might be a bit trickier, because if you hardcode the port in the manifest, the user wouldn't be able to change it?

Might be better than nothing I guess, but on the long term you'd need to add the port in settings and request the permission for localhost+port dynamically? But that's got another issue, e.g. last time I tried it [0] for my extension, Firefox didn't support dynamic URL permissions for URLs with ports.

[0] https://github.com/karlicoss/grasp/blob/f24378ebae68c22bea03...

Can’t you setup a DNS entry on your domain that resolves to 127.0.0.1 that you reference instead of localhost?

Your resolver may not always permit this sort of thing, and that would just obfuscate what they're doing a step further which may come across as sneaky.

I doubt it is at all common in end user environments, but unbound for instance can be configured to prevent local IPs from being resolved in other domains. It's a good practice to follow in a datacenter environment if you're connecting out to hostnames you resolve from DNS you don't control.

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!

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?

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.

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.

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.

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.

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.

Reply on news.ycombinator.com