command api needs to be secured

[phritz]

anyone who can connect to the node's api port listening on 127.0.0.1 can issue commands, including sending messages that transfer FIL. some commands like message sending should really be protected, as signing happens on the other side of the api interface. other commands like getting the head of the chain one might want publicly accessible from the local machine eg if you are running something that consumes the api. i'm not sure the right thing to do here, but wanted to dump the following considerations:

• we need a threat model, otherwise it will be hard to know what measures make sense; even so:
• given the ease of xss and csrf, i doesn't seem like restricting access to the local machine is sufficient: if the user is using a web browser they'd be vulnerable. plus if you can get the user to run anything on their machine they're vulnerable.
• web-based threats could be mitigated by requiring a secret stored in the .filecoin directory to use the api, reducing security to that of the filesystem
• we should probably warn loudly if the api is run on anything other than a local loopback address

[anorth]

This will be made redundant by #3098, assuming the CLI is migrated to use the new API.