Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've worked on some applications like this, and it works pretty well. But be aware that a port on localhost is accessible to any local user - depending on the application you may need to prevent other users accessing it.

Running inside a real browser also limits the keyboard shortcuts you can use, because you don't want to clash with the browser's own shortcuts.



Can't this concern be easily alleviated by the backend requiring credentials, and sending them along from the frontend? Getting around this as an attacker means already possessing enough rights to not need sniffing the traffic to the backend. Or is there more required?


It can, but getting the credentials to the browser & storing them there isn't entirely simple. If you launch a browser process to a URL containing a token, an unprivileged local attacker can see it in the command line arguments (at least on some platforms) and copy it. That can be mitigated by launching the browser with a file:// URL which uses an HTML meta redirect to give the browser the token.

The obvious way to keep the browser authenticated is a session cookie. But cookies are shared between all ports on a domain, so a local attacker who tricks you into visiting another localhost service in the same browser can steal the cookie. localStorage doesn't have that issue, but it's not so convenient for authenticating requests.


Weirdly, Windows makes it easier to do this securely in that you can do NTLM authentication to authenticate local users (maybe MacOS as well, I believe internally it runs its own Kerberos server for the local machine).


AFAIK you can only do this if you disable the local loopback check that prevents windows auth from passing credentials to local host webservers.


Why did they put that in in the first place? To stop cracking of local passwords?


Usually if it's already local, you don't mind localhost connections. If you do, you can negotiate a shared cookie or other auth mechanism. Otherwise, you should at least check the host header to prevent DNS rebinding attacks.


You can capture most keyboard shortcuts in the browser these days, and the native server side can handle registration of global keyboard hooks if your app needs those.


I'm thinking more of the user experience if you take over shortcuts people already use for their browser.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: