Race conditions: Does your API TOCK TOO much? »

We've written on the topic of API threat detection before, and also outlined a "top 10 API threats" to guard against, but race conditions are another area in which APIs are also vulnerable.  

A race condition is a bug where the output is dependent on a sequence of timing of other events.   APIs are vulnerable to a type of race condition called TOCTTOU (pronounced "TOCK TOO") .   

During this crack in time, malicious users are using race conditions that have been exploited as security vulnerabilities in systems for almost 4 decades.

Historically TOCTTOU attacks have been used to take advantage of a weak filesystem API and limited security controls to OPEN, RENAME, CHANGE OWNER(chown), CHANGE MODE from READ ONLY to READ/WRITE (chmod). Applications such as vi, gedit, rpm, emacs, gdm, and many other GNU programs have been exploited to take advantage of TOCTTOU weaknesses. (See this even longer list at the NIST CVE CCE Vulnerability Database.)

What can you do to reduce race conditions in APIs?

Mediate the request and response with a single atomic event that collapses the check (authenticate) operation with the use (open) events.  If you are building atomic transactions as the design principle, then buffer the system with a checkpoint between the user zone and the service zone — aka, the DMZ.

The use of a mediation proxy in the DMZ to perform the authentication and authorization checks adds latency indeed, but it improves the quality of the system by adding load balancing, packet and message body introspection, event logging, and possibly a second authorization on the response to verify that the user is authorized to receive the object requested.

A second authorization check can also:
-    prevent accidental data leakage
-    makes it more difficult to create a race condition
-    detect if the user is no longer authorized to read the content, or if the user is attempting to access an object without execution, read or write entitlements.

So if you are concerned that your firewall is not doing enough for you, or you are worried that your DMZ has been compromised by the firewall TCP Split Handshake vulnerabilities, then consider using an extra layer of mediation between client side applications and server side APIs.

A policy enforcement point (like our Apigee API Gateway)  - behind the firewall and in front of the API service - reduces the risk of a man-in-the-middle attack.