fix: add content-type check to user management routes to mitigate CSRF

[MarcusWichelmann]

This applies the fix from #206 to the newly added routes.

Without this Content-Type check, it might be possible for a foreign site to send a POST request to wireguard-ui, while a user is logged in, and create a new admin user. This would be really bad.

I did not manage to successfully exploit this yet, but theoretically, it could be possible.

[systemcrash]

What happens if the UAC isn't a browser? But instead e.g. curl?

Don't requests anyway require/use an admin cookie?

[MarcusWichelmann]

@systemcrash CSRF is only an issue with browsers. Here is a description about it: https://owasp.org/www-community/attacks/csrf

In short:
If you are logged in to wireguard-ui and visit a malicious website, it could do a cross-origin request to e.g. create a new admin user or change your password.

[systemcrash]

Does including this have the potential to break normal operations and frustrate existing users?

Further, the diff looks only to add app+json check, so any PUSH request containing such json would succeed, no? But if the idea is to only defend from browsers, then it seems like this is fit for purpose.

[MarcusWichelmann]

@systemcrash This should not break existing setups, because the XHR request the webinterface makes are always application/json already. Even if someone uses curl to interact with wireguard-ui, he should still already be using application/json, if he does things correctly.

The check for the content-type is sufficient as a basic CSRF protection, because bwosers do not allow cross-origin requests with a non-default content-type.

As mentioned above, this fix is already applied to most API routes but was forgotten when adding new ones, so this PR is just adding it where it's missing: #206

But if the idea is to only defend from browsers, then it seems like this is fit for purpose.

Yes, only browsers, because CSRF is not a relevant attack vector when using curl.