Security suggestion: prompt for password when running `./gdb-frontend`, and ask for whatever is set when browser connects

[rohanrhu]

Security suggestion: prompt for password when running `./gdb-frontend`, and ask for whatever is set when browser connects

[ell1e]

If you browse google.com in firefox, it can definitely access the debugger. (Like, google literally can. Or any other website) This is not commonly known, but most browsers allow this right now through Ajax requests and such. Same Origin and such is applied only to external hosts I think, the idea being that it allows integrating with local services like MEGASync and stuff like that. Not that I like it, I think it's a dumb default on behalf of the browsers, but that's how things seem to be. So this is maybe more of a problem than you think.

edit: but the website would still need to guess the port 5551 and wouldn't know how to operate a gdb debugger, so it's like, still a kind of weird attack vector. but this could become more of an issue once the tool becomes more popular seems like it can't due to same origin, not a full request that isn't immediately aborted at least 😅 but I'm not sure how it is with local network sites

[ell1e]

gdb-frontend doesn't even need to be open in a tab. Just any website you open can send HTTP requests to all your local network through your web browser via JavaScript.

The firefox bug for this is here: https://bugzilla.mozilla.org/show_bug.cgi?id=354493 (firefox doesn't seem to have any sort of permission or prevention for this in place at all right now)

The chromium bug for this is here: https://www.chromestatus.com/feature/5733828735795200 (as you can see they're testing that the connection is aborted if the localhost or network host http server doesn't respond with a certain opt-in HTTP header, but you can still get spammed with partial connections once that is in - and right now they're only testing it so this isn't actually enforced yet)

[rohanrhu]

It is interesting. I dont think it can be possible, just tried and got CORS error: Access to XMLHttpRequest at 'http://127.0.0.1:5551/' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Other localhost pages still can access the debugger but that means they are already running on your computer and they have full access on the computer already.

Can you produce it as accessing localhost from different hostname/address?

[rohanrhu]

Actually, it also must be not possible to different ports can access each other. I thought it maybe only possible with applications with multiplexed ports to same hostname with different URL paths.

[ell1e]

Where I came into contact with this is with MEGASync, which runs at a local port and even in private browsing mode, mega.co.nz can happily speak with the local instance. I suspect the local MEGASync backend must send the according Same Origin headers then to allow it, so I guess only then access from a different (possibly external) host + port is allowed? Sorry for jumping to conclusions 😅

In any case, I would prefer to keep local apps out via password too if possible 😊

[rohanrhu]

Yes we need a password option for better debugger sharing experience 😃

[rohanrhu]

Tmux is solving so many issues. Terminal sharing to web would be a problem without tmux. If you wonder about tmux sessions, different linux users can't access to other's tmux sessions.

[rohanrhu]

Default bind address is 127.0.0.1. (You can specify it with --listen=ADDRESS option: https://github.com/rohanrhu/gdb-frontend#--listenip--l-ip)

It is not possible to someone access your debugger from another IP address. But we still need a password-protected interface, so we can share our session as readonly with that feature.

Im adding this to v1.0 Roadmap.

[rohanrhu]

Do you mean a browser tab can access to another one?

[rohanrhu]

That is a horrible bug.

[ell1e]

Yeah I agree, even worse that it is "by design". It's a reckless idea if you ask me, exposing all local servers like that. Basically, nothing you run locally via HTTP without a password is safe from a modern web browser. (edit: same origin does still apply, I was wrong it seems like. but I'm not sure what exactly that means for local network tabs, so it's still not ideal maybe...? not sure) I hate it too, but not much that can be done to change it since all browsers behave like that right now 🤷‍♀️ so the best options are things like a password to keep snoopy javascript apps away

[rohanrhu]

As I understand, you don't mean other apps that are running on localhost can access the debugger naturally? You mean non-localhost web pages can access it?

[ell1e]

Hmm that depends on the app, that might also be possible. However, that would be less unexpected since it's already running on your local pc at that point. But I mean just any random website you visit can also access it, since the web browser will happily forward that random website's javascript HTTP ajax requests to your localhost port without asking you. It's considered a "feature" 🤦‍♀️ edit: seems like same origin still applies as I corrected above, at least for non-intranet hosts

[ell1e]

Ah interesting. So basically it is possible to reach it via HTTP but the browser will abort if it doesn't have a same origin header that allows any source? Maybe it's not as bad as I thought then.

Re-reading, it seems the issue of chromium also seems to be about one intranet site messing with another: https://www.chromestatus.com/feature/5733828735795200 so you might be correct that a google tab opened in a web browser couldn't fully operate a gdb frontend (and I was possibly likely wrong), and just send a single request that wouldn't fully go through due to same origin.

In that case you'd be right and this is mostly just a local app issue for e.g. flatpak sandboxing, but not nearly as bad as I thought (which is good I guess 😅 sorry for the scare)

[ell1e]

I've been poking around the run.py code some more, I wonder if it might sense to also add an option to not run it in tmux? (Since that is another "sharing" mechanism that might otherwise need to be passworded maybe, I don't use tmux so I don't know) Could be useful for those like me who don't use it anyway, I just use the web frontend and the terminal directly in the web tab and that's it

[rohanrhu]

I added password option. (cb1f3bc) You can use as --credentials=user:pass or -c user:pass. (Browser will ask same credentials for two times.)

But it is not ok yet because WebSocket debug server is still passwordless. It will be done when I added credentials to WS server too.

[rohanrhu]

I implemented a new WebSocket server into HTTP server. (33f20c1) So we are not using a different WS library and port no longer. Now we are using two ports. (Gotty port and HTTP server port)

HTTP Auth security is now done.