Conversation

Notices

1. Embed this notice
   Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Wednesday, 27-Mar-2024 17:07:04 JST Ryan Castellucci :nonbinary_flag:

   • Dana Fried
   • Sophie Schmieg
   • Adam Shostack :donor: :rebelverified:
   • Vrimj
   • Dominic White
   • David Chisnall

   @adamshostack @tess @sophieschmieg @david_chisnall @Vrimj @singe My work focuses on fraud detection and prevention, and in this context motivation and incentives help to inform what to look for.

   I actually do find being an "attacker therapist" useful in anti-abuse contexts because there is an iterative processes of detections and evasions. Getting inside their head helps me predict what they'll do.

   Conversely, to your point, nobody needs to care why someone would do an SQLi.

   • Embed this notice
     David Chisnall (david_chisnall@infosec.exchange)'s status on Wednesday, 27-Mar-2024 18:29:52 JST David Chisnall

     in reply to

     • Dana Fried
     • Sophie Schmieg
     • Adam Shostack :donor: :rebelverified:
     • Vrimj
     • Dominic White

     @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.