Vivek’s Soapbox

A higher-order injection attack happens when an attackers stores a malicious string into persistent storage, using a context where it is not considered malicious, to be executed at a later time in a different context where the string can actually do damage.

Borrowing an example from F. Valeur, D. Mutz, and G. Vigna: consider a script that deletes old users who haven’t logged in for a while:

Here the username string is where the malicious payload is stored. Consider what happens if the username is ‘OR ‘1′=’1. When the username is read into this script, the last line has a WHERE clause that evaluates to true, and thus deletes all users.

As pointed out by the CSSE (context-sensitive string evaluation) paper, such higher-order attacks are particularly hard to guard against. Data coming from persistent storage such as a database is considered trusted to start with, and rarely checked. Runtime approaches that detect injection attacks by adding metadata to strings (such as CSSE, or our taint propagation approach) would actually need to also make their metadata persistent, and then restore it when persistent data is read back into memory. In implementation terms this is much harder because it touches parts other than the VM or interpreter — such as the database, or filesystem. Also, if metadata is written out to persistent storage, it might interfere with the operation of other programs that work off the same data.