API CSRF protection

[mcginty]

(This continues the discussion from #26)

Temporary solution

We can have some basic CSRF protection by requiring custom headers with some unique information, as experimented with in #37.

This type of solution is far from ideal, and is instead just a means to stop the simplest of this class of attacks.

Idea A: Signature-based authentication

Curve25519 keys, those used by WireGuard, can be converted to be used in Ed25519 signatures.

Peers could use their private keys to sign API requests (kind of like what AWS does), and through that would prove that the initiator of the request is in possession of the peer's private key.

Advantages

• No extra keys or magic secrets
• Could be used as an authentication method not just for innernet-server, but eventually for other services on an innernet network.

Disadvantages

• Curve25519

Idea B: Token-based authentication

The innernet-server could give peers a token when peers first join (or re-join) the network, and require that they pass that token along with every request.

Advantages

• Simple, tried-and-true method

Disadvantages

• Not completely clear when exactly the token is generated and given to peers, and how/if it's rotated.
• Only really an applicable solution for innernet-server, every other service has to work their own stuff out.

Idea C: ???