@ryanc @adamshostack @tess @sophieschmieg @Vrimj @singe
Conversely, to your point, nobody needs to care why someone would do an SQLi.
But that’s exactly what I do care about in a threat model. For example, if my database is using access control that restricts the queries that a client can run to the set of things that are exposed, what extra rights can an attacker gain by injecting SQL? If I have an API that allows the client to submit SQL, and another that allows them to run pre-generated queries, and the second is vulnerable to SQL injection because the attacker could just use the same endpoint. In contrast, if I’m using the set of SQL queries that are run in my trusted component to restrict what the user can do, then I care a lot about SQL injection.
The key difference between these two cases is what the attacker is trying to achieve. Whether it’s tampering with other customers data, extracting trade secrets, or trying to find location data on another user to spy on them, the motivation of the attacker is key.
This is particularly true in a compartmentalised system. For a lot of the #CHERIoT work, we have compartments where we assume an attacker can get arbitrary-code execution. To reason usefully about security we have to think about what they want to achieve. Do you want to compromise the control-system logic? Do you want to join a botnet mounting a DDoS attack on other devices (and not care at all what this device is, just that it has a network connection)? This factors into high-level system decide and lets you reason about what classes of attack are in scope and where we care about vulnerabilities.