Improve security about slashboard-pulsar

[xadaemon]

I will happily tackle it, this is perfect for jwt tokens because we can store every needed info on the token itself, also username/password can be kept in a file, only thing is, I would store the password hashed just in case but we can start with just storing them in a json file.

[xadaemon]

Actually it was very bad the key was expected in the url which is very much public and visible to anyone even with TLS so it was not secret at all, I'm about to drop a PR

[xadaemon]

I think this can be closed since we merged the change, unless you want to keep this one around for the other 2 points

[BSoDium]

Currently, the only actual implemented security measure is a 64-char alphanumeric key which prevents random people who know your server's ip and port to access its status. However I am aware (although I have no idea how to fix it) that there might ways of overriding this.
I'd love to know what your concerns are, and how you plan on fixing them 😄

[xadaemon]

I already took a look at the code my first idea is to make it a username/password combination and (correct me if it already is) serve the endpoints under tls i.e https since right now the "key" is sent plaintext and this is highly insecure unless you only work inside your private network. So in short my idea is two fold:

• Make the credentials username/password based and switch over to a jwt/session system to avoiding sending the pair every request, jwt is nice here because it's self contained and can work without a db;
• Optionally expose the endpoints over https(make it optional as local networks don't need it as much) or offer guidance on reverse proxying the server;
• Add host whitelisting (i.e only respond to allowed ips);

I further suggest implementing these in 2 phases, first and foremost replace the current "key" system with the proposed or similar, and the optional tls, finally implement the host whitelisting.

[xadaemon]

We can later improve it with more secure methods (but that require more setup so make them like available not mandated) like certificate based authentication or similar

[BSoDium]

These are good ideas indeed, for now, I want to keep user data such as settings and saved servers in a client-side json file, so storing these in a database for each account is something I want to avoid.
However, improving the key system is a good thing (I didn't spend a lot of time researching on that subject because no actual sensitive information is being shared, but it might be better to implement this anyways). If you want to take care of this, you can, otherwise I'll tackle the issue later when I'm done finishing up the front-end and the API routes.

Anyways, I'm adding this to the backlog.

[xadaemon]

feel free to assign me to this

[BSoDium]

There you go

[BSoDium]

Yes, I'm closing this, I'll reopen it if needed.