Implement better security for JSON API

[broofa]

That the following endpoint actually works is concerning for a number of reasons:

http://www.thrustcurve.org/api/v1/getrockets.json?username=mapeki9543@dghetian.com&password=mypassword

(BTW, that's just a temporary account I made that I have no attachment to, so don't really care that the credentials are public here.)

Specifically ...

• Because that request goes over http, the credentials are available as cleartext to anyone who has access to the data packets. (Think packet sniffers on insecure wifi networks, man-in-the-middle attackes, etc.)
• Because the credentials are in the query params, they end up in the browser history
• ... and also in the weblogs of any intermediate proxies, firewalls, routers, etc.

At the risk of being a bit dramatic, those credentials were almost certainly compromised even before I posted them here. 😦

There are several action items that flow from this:

• [ ] Drop support for http access. Instead, configure your hosting service to automatically redirect all incoming http connections to the https: interface. (This is standard practice for all websites these days.)
• [ ] username and password query parameters should not be allowed. (In fact, I would argue the server should error with a message to the effect of, "You need to change your password!") if it sees either of these query parameters.
• [ ] I would suggest you also drop support for passing credentials in the body of POST requests as well. While it's acceptable only if the connection is over https, it's not really a great practice. Instead, I would require all authentication be done via standard HTTP authentication. ("Basic" authentication is pretty easy to do and will suffice as long as the connection is via https). Bonus: Pasting an API url into the browser will pop up a nice little login window.

[JohnCoker]

There are existing users of this API, most of which don't log in, so we should continue to allow HTTP access, at least for the XML endpoints other than getrockets and saverockets. For example, RockSim and OpenRocket both use it and I doubt they would handle a 30x return value properly.

The site already redirects all HTTP access other than the API to HTTPS, see app.js:69. Right now both modes are supported so it's up to the client. I agree any modern client will use HTTPS, but we have some legacy ones out there too.

[broofa]

My concern here is that the way the API is currently presented encourages people to develop new clients that rely on these bad-practices, which just exacerbates the problem. It'd be nice if there were a path forward that took this into account.

I agree any modern client will use HTTPS, but we have some legacy ones out there too.

I think you're on to the right approach in your comment in #18. Keep the current v1 API in place for legacy clients, and treat v2 as "the future". Once v2 is available, the v1 API can be deprecated (in documentation if nowhere else).

[JohnCoker]

I think you're on to the right approach in your comment in #18. Keep the current v1 API in place for legacy clients, and treat v2 as "the future". Once v2 is available, the v1 API can be deprecated (in documentation if nowhere else).

Feel free to take over the Swagger spec for the v2 API.