Just remember that authentication and origin checking is completely up to the websocket server.
Any random page in a browser can talk to your websocket cross origin, and it's up to your server to check the "Origin" header to make sure it's actually your app on the other end.
Yes and no. Recently browsers started assuming that a response without CORS headers it unsafe unless from the same origin. So even though you can make a request if it fails preflight it will not even reach your server.
You can try this by opening a console on any webpage and trying to do fetch requests or add img tags to the page that are loading resources from localhost.
That's what I use, Caddy webserver with Gandi DNS (also used Route53 in the past) handling the ACME challenge and a `*.l.mydomain.tld` pointing to 127.0.0.1.
Adding reverse proxies for different local services becomes a piece of cake, but mkcert allows you to use `localhost` directly if needed. Personally I never have and like not having to make any changes to the trust store.
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.
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.
you are correct it could be theoretically pressed by someone else, but it should be really difficult because of the unpredictability of IDs. It should be simpler to attack flask or django based webinterfaces. doesn't it?
thank you for the advice. it should be pretty simple to protect an app from that kind of attacks. however this doesn't mean that remi is a safe web framework. personally I feel like @nicolaslem (look at his comment).
With websockets, it's actually up to the server to implement the cross origin detection. The library used in this application does not implement any protection.
So it's possible for any page on the net (eg evil.com) to connect to your socket and exfiltrate any data.
Make sure all tabs are closed and never visit any sites with advertising on it while this is running.
The websocket server needs to check the "Origin" header from the client. The code then needs to know what is expected (eg localhost or 127.0.0.q).
If the origin header is something like "evil.xyz.com", then it needs to reject the connection.
Yes, I understand how origin verification is done. Nothing stops any other local app to make make a WS connection to this app's server and pretend it is making valid requests while, potentially, executing destructive actions or stealing data.
I understand that the generic answer will be along the lines: "well, if you have local access, you're never safe", but there is zero protection here. Anything local can connect to it and impersonate the "front end".
Not really. By the time you make those signals provide feedback about your task rather than just whether Caps Lock is on, you'll have already accomplished your task and be into the part of the process where you're trying to download or compile some hack to use code to send something useful along Caps Lock signals. It's not a useful feedback mechanism when getting the feedback is an order of magnitude or two harder than the task you're trying to perform in the first place.
But if you host your site on your infrastructure, and it goes down, you can't post status updates to tell people what's going on/ when you will be back online.
Its quite reasonable to not host your own homepage or mechanism of updating your customers IMO.
I disagree. Your website should run on your own infrastructure and a separate status page, under a different (sub)-domain should be operated from another AS (autonomous system) e.g. statuspage.io or whatever you like/prefer.
If I understand correctly, there is a key in the DHT that is effectively a list of pointers to all your mail?
If so, an attacker could control your inbox by starting a bunch of nodes around that key, couldn't they?
To disable a persons mail, you would start up some altered nodes around the address space you want to attack, have them respond normally until you control enough or all of the nodes covering the target address.
Then flip a switch that makes them all start saying that inbox is empty. Then start backing off your nodes, and replacement regular nodes would replicate your altered state.
Would this be possible? Or am I missing something?
