Hacker News new | ask | show | jobs
by mic159 2821 days ago
Does it have any protection from malicious js on another site (say a bad ad on a news site) connecting to your application?

I have seen some applications like this, but they fail to check the origin header.

1 comments

No protection, it have to be intended as a full featured, standalone and remotable gui framework
I don't quite understand your answer. As the readme says: > Remi should be intended as a standard desktop gui framework. The library itself doesn't implement security strategies, and so it is advised to not expose its access to unsafe public networks.

So if listening on localhost to provide a GUI on the users desktop, is it not meant to be protected from attacks from the web?

you are right, it requires further explanation. it is intended to be used on localhost and also on the web, preferably on safe networks like VPN. it implements ssl encription and a basic http authentication. technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. I consider it unsafe because I never spent enough time to test the framework penetration resistance.
That's scary. Listening on localhost or serving a LAN/VPN behind a firewall does not make your web app secure from attackers on the Internet unless you air gapped. HTTP Basic Auth and HTTPS doesn't change that. Please do read up on CSRF.

This has been an issue for decades and just recently been in the news due to massive attacks against home routers (web apps listening on the LAN) and desktop apps (both web apps and web APIs listening on localhost). I get the impression that this has not been considered.

https://en.wikipedia.org/wiki/Cross-site_request_forgery

thank you so much for the advice. however, as previously mentioned: technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. this means that the attacker have to know the ID of an object instance, in the actual running instance to point to a defined function.

however, the safety of an application is up to the developer, that can leave opened also the door of a safe atomic bunker

Am I correct to interpret this as it's up to the app developer not to put any features that do anything of any importance in the web interface, because one should operate under the assumption that it's not only the logged on user in front of the computer (even when address='127.0.0.1') that can press the buttons?

Unless I'm completely misunderstanding I don't agree that is at all comparable with the security model expected of a "standard desktop gui framework" nor safe.

Though indeed if there are large, random and unpredictable IDs required to perform actions it may defeat or make the attack difficult.