Of all the new features in the latest version of Cascade Server, I’m most excited about the REST API. I’m a heavy user of the current Web Services API, but as a SOAP service it’s a hassle to use and doesn’t play nice with languages like Clojure.
The REST API can leak your username and password
I wanted to call out one thing I saw in the documentation, however — the Cascade Server REST API allows the client to pass their username and password in the URL. The documentation also implies that this is the “default” approach.
Passing credentials in the URL query string has long been understood to be poor security practice, and is called out by OWASP in both their vulnerabilities wiki and in their proposed list of 2017’s top web vulnerabilities.
The Cascade Server documentation tries to provide some assurance in their notes:
Using REST API it is allowed to pass authentication to the URL. This is secure for the network over SSL — the credentials will be encrypted so that nobody can intercept the network connection and get the credentials.
While they’re right that passing the credentials in the URL over HTTPS helps prevent man-in-the-middle attacks, it’s misleading to say that it’s “secure over the network.” In fact, the very first paragraph of OWASP’s wiki on exposing credentials in the URL warns that “simply using HTTPS does not resolve this vulnerability,” as the credentials are leaked in:
- Server logs
- Browser history
- Browser cache
- Shared network resources
Keeping your credentials safe
To be fair, Hannon Hill’s documentation does call out one of the above issues: the leaking of API credentials in server logs.
However, there is a chance that the server itself has logging enabled that stores accessed URLs. At that time, the server administrator could access the logs and see the password.
To mitigate this issue, Hannon Hill has given developers the option to make all API requests with the HTTP
POST method, including “read”, with the credentials passed in the
POST payload instead of the query string.
This helps with the security issues above, but breaks one of the main conventions of RESTful web services. (I could also talk about how
POST isn’t an idempotent HTTP method, but that’s a little inside baseball for today.)
In my perfect world, Hannon Hill might have followed the lead of other major APIs and implemented the HTTP
Authorization header, though this is a tiny bit less convenient for developers, especially if OAuth is used.
The addition of a REST API to Cascade Server is really cool, and is going to make hooking up to sites a lot more pleasant.
It’s unfortunate that Hannon Hill’s implementation asks developers to choose between securing their keys or breaking RESTful conventions, but I would ask that you all just save yourselves future headaches and make all your API calls via