Security Engineering: A Guide to Building Dependable Distributed Systems, Second Edition

Chapter 18. API Attacks

One is happenstance; twice is coincidence; but three times is enemy action.

—— Goldfinger

Simplicity is the ultimate sophistication.

—— Leonardo Da Vinci

Introduction

Many supposedly secure devices have some kind of application programming interface, or API, that untrustworthy people and processes can call in order to get some task performed.

• A bank's server will ask an attached hardware security module 'Here's a customer account number and PIN, with the PIN encrypted using the key we share with VISA. Is the PIN correct?'

• If you enable javascript, then your browser exposes an application programming interface — javascript — which the owners of websites you visit can use to do various things.

• A secure operating system may limit the calls that an application program can make, using a reference monitor or other wrapper to enforce a policy such as preventing information flow from High to Low.

The natural question to ask is whether it's safe to separate tasks into a trusted component and a less trusted one, and it's recently been realised that the answer is very often no. Designing security APIs is a very hard problem indeed.

API security is related to some of the problems I've already discussed. For example, multilevel secure systems impose flow controls on static data, while a security API is often trying to prevent some information flow in the presence of tight and dynamic interaction — a much harder problem. It's also related to protocol security: as I will discuss ...