Join Mark O'Neill and I for a webinar this Tuesday. We have two actually, on EMEA and North American time. Register here. The webinar goes through the topics in my forthcoming whitepaper (whitepaper is here) The Curious Case of API Security.
In this project we channel the spirit of Father Brown, Hercule Poirot, and Sherlock Holmes. We approach the top security issues in APIs the same way a detective would. Our basic process is as follows:
- Understand the context in which our APIs exist
- Look for clues of possible vulnerabilities
- Catalog what tools we use to identify and track vulnerabilities
- Identify countermeasures that we can use to close out vulnerabilities
- Provide evidence that can measure the efficacy of the countermeasures
I will briefly summarize the top ten issues here, but join the webinar and read the paper for the full version. To help crystallize the issue, I included a representative Sherlock Holmes quote.
1. Unprotected APIs
Most enterprise cores are as soft and chewy as the center of a candy bar. That means that once inside an attacker has free reign. Therefore, the API layer is a table pounding, must have security priority.
2. Weak Authentication
“There is nothing more deceptive than an obvious fact” -Sherlock Holmes
Just because your APIs have authentication, does not mean it will withstand scrutiny from an opponent. Its on security engineers to build stronger forms of authentication.
3. Brute Force
“The world is full of obvious things which nobody by any chance ever observes” -Sherlock Holmes, Hound of the Baskervilles
APIs are particularly vulnerable here because they are always on. Yet most APIs lack basic scrutiny of the type and velocity of inbound requests. These are deemed uninteresting, but as Marcus Ranum says the number of times an uninteresting thing happens is interesting.
4. Injection
“I never guess. It is a shocking habit, —destructive to the logical faculty” -Sherlock Holmes, The Sign of Four
Assuming they have access control, many APIs then simply guess that the input is ok and pass it along to the backend. Guessing that input is ok, may be habit forming and can destroy your backend systems integrity.
5. Lateral Movement
“As a rule, the more bizarre a thing is the less mysterious it proves to be.” -Sherlock Holmes, The Red-Headed League
Who would have guessed a priori that HVAC systems and payment systems would be linked? But a better question to ask may have been, what is in place to stop any linkage between the systems? Once an attacker gains an entry point what is to stop or even detect follow on actions?
6. Session Promiscuousness
"I had," he said, "come to an entirely erroneous conclusion, my dear Watson, how dangerous it always is to reason from insufficient data"” -Sherlock Holmes, The Adventure of the Speckled Band
For Web apps, session cookies have all sorts of protections that engineers can use to try to provide a margin of safety around them. After all these cookies are used to mint and convey authority to use the system. For APIs though these basic protections against attacks like clickjacking, replay, and other impersonation vectors are usually missing.
7. Invisible Attacker
“You know my method. It is founded upon the observation of trifles.” -Sherlock Holmes, Boscombe Valley Mystery
Securing APIs does not stop at access control, the API security layer must also try to detect malice. This means logging and monitoring activities to develop pattern recognition for friend from foe.
8. Broken TLS/SSL
“Crime is common. Logic is rare. Therefore, it is upon logic rather than upon the crime that you should dwell.” -Sherlock Holmes, The Adventure of the Copper Beeches
While threats get all the attention, vulnerabilities and countermeasures are in fact where security engineers can be proactive. Threats are common, countermeasures are rare. We should spend our time on countermeasures. TLS/SSL has been taken for granted for a long time, but now its efficacy is challenged by BEAST, Poddle, et al. It goes to show how much engineering effort must be sustained to deliver even the basic protections we have today. For APIs, there is the additional burden of certificate management which is another long run area of struggle. If the level of attention paid to the talks at hacker cons was given to focused certificate management, we might wind up in a different place as an industry.
9. Inversion of Control
“When you follow two separate chains of thought, Watson, you will find some point of intersection which should approximate to the truth” -Sherlock Holmes, The Disappearance of Lady Carfax
The big picture of API security must include the client. Unfortunately this is an area with few good practices. The server has the DMZ as a pattern, for all its warts, its a pattern that people know how to use and we have tools there. The client side is different, now it has data and whether mobile, cloud, or IOT client its doing stuff with it. How to protect it? How to deal with server pushes where the client comes becomes the server in effect by bi directional communication channels?
10. Order of Operations
“The principle difficulty in your case,” remarked Holmes in his didactic fashion, “lay in the fact of there being too much evidence. What was vital was overlaid and hidden by what was irrelevant. Of all the facts which were presented to us we had to pick just those which we deemed to be essential, and then piece them together in their order, so as to reconstruct this very remarkable chain of events.” -Sherlock Holmes, The Naval Treaty
APIs can appear to be a static set of getters and setters, but once they are built into other applications the combinations and permutations can drive unexpected behavior on the enterprise back end.
11. Trusted !=Trustworthy
“Always approach a case with an absolutely blank mind. It is always an advantage. Form no theories, just simply observe and draw inferences from your observations.” -Sherlock Holmes, The Adventure of the Cardboard Box
The security architect’s most difficult opponent is probably not a malicious attacker. The security architect’s most difficult opponent is probably themselves. Microsoft’s John Lambert says it well, “Defenders think in lists, attacker think in graphs. As long as that is true attackers win.” The security mindset is most effectively deployed as mistake avoidance, which means in practice not buying into silver bullets, but instead engineering capabilities margins of safety.
Comments