EoP Threat Suits - T (Tampering)

  • Article

Tampering (T) is the second suit of threats in the STRIDE threat enumeration.

Tampering describes any threat that allows an attacker (or accidentally causes a user) to alter or destroy data which the application has not allowed them to. Accordingly, the characters on the cards are green gremlins whose open mouths and sharp teeth could indicate either shouting or a desire to eat.

Tampering threats are generally countered through quality implementations of Integrity protection and Authorisation.

Another successful way to mitigate tampering is to not care about the integrity of data - this only works if you are able to handle abusive and incorrect data without causing a loss of function (this Wiki is an example of what happens in this model!). Ignoring integrity and hoping that attackers will not alter or destroy data is not a valid mitigation strategy.

The cards in the Tampering suit are as follows (NOTE: Someone must have tampered with the 2, because it isn't here)

  • 3 T - An attacker can take advantage of your custom key exchange or integrity control which you built instead of using standard crypto
  • 4 T - Your code makes access control decisions all over the place, rather than with a security kernel
  • 5 T - An attacker can replay data without detection because your code doesn’t provide timestamps or sequence numbers
  • 6 T - An attacker can write to a data store your code relies on
  • 7 T - An attacker can bypass permissions because you don’t make names canonical before checking access permissions
  • 8 T - An attacker can manipulate data because there’s no integrity protection for data on the network
  • 9 T - An attacker can provide or control state information
  • 10 T - An attacker can alter information in a data store because it has weak ACLs or includes a group which is equivalent to everyone (“all Live ID holders”)
  • J T - An attacker can write to some resource because permissions are granted to the world or there are no ACLs
  • Q T - An attacker can change parameters over a trust boundary and after validation (for example, important parameters in a hidden field in HTML, or passing a pointer to critical memory)
  • K T - An attacker can load code inside your process via an extension point
  • A T - You’ve invented a new Tampering attack

[When completed, each card description above will link to a copy of the card, along with examples of the threat and some specific mitigation steps. Point to Patterns & Practices documents, excerpts from Writing Secure Code, etc, where possible. Emphasise that the information is already out there, so that dev teams widen their horizons.]