User input is trying to kill you until proven otherwise. And even then, it probably still is. If you accept anything from a user, treat it like you're carrying spent nuclear fuel around your application; that doesn't just mean form inputs, either; sometimes you have to wear gloves that even consider files read from the filesystem as suspicious. There are numerous attacks on temporary files if implemented incorrectly.
Damned near every exploitable security problem in an application can be traced back to this one simple rule. XSS is a common one. The ones that don't conform to the rule are rare and magical, like unicorns, and usually involve something exotic like hardware side channels. If you take input it will be abused, so plan accordingly. That occasionally manifests in unexpected ways like timing attacks, in which case an attacker repeatedly sends you lots of carefully-chosen input to deduce something based on how long it takes your code to reply, much like cracking a safe. It's a basic attack on a string compare, which is O(n). This simple code is vulnerable:
A timing attack would try to deduce each letter here, since the string comparison will short-circuit once it finds a wrong character. Using a simplistic model, say I sent 'a' through 'z'; 's' took 10 time units to respond, but the other characters took 8. Now I try 'sa' through 'sz', and go from there. As a thought exercise, try to imagine a few ways to prevent it, and consider the pros and cons of each; now you're thinking in the security mindset.
Securing an infrastructure is another story, but the rule is applicable with the occasional clarification to everything there, too. There are domains of trust even within your own organization; malicious employees will try to harm you, as well, and you get little to no warning of those. Do your interns need root on machines containing customer data? Employees are users too.
Well, it's somewhat comforting to know it's mostly about user input. Thanks! Not that it's easy to secure input handling either.
I've seen that kind of timing attack discussed somewhere, and the solution there was to do some kind of byte-by-byte comparison that would always take the same amount of time. It makes sense.
Damned near every exploitable security problem in an application can be traced back to this one simple rule. XSS is a common one. The ones that don't conform to the rule are rare and magical, like unicorns, and usually involve something exotic like hardware side channels. If you take input it will be abused, so plan accordingly. That occasionally manifests in unexpected ways like timing attacks, in which case an attacker repeatedly sends you lots of carefully-chosen input to deduce something based on how long it takes your code to reply, much like cracking a safe. It's a basic attack on a string compare, which is O(n). This simple code is vulnerable:
A timing attack would try to deduce each letter here, since the string comparison will short-circuit once it finds a wrong character. Using a simplistic model, say I sent 'a' through 'z'; 's' took 10 time units to respond, but the other characters took 8. Now I try 'sa' through 'sz', and go from there. As a thought exercise, try to imagine a few ways to prevent it, and consider the pros and cons of each; now you're thinking in the security mindset.Securing an infrastructure is another story, but the rule is applicable with the occasional clarification to everything there, too. There are domains of trust even within your own organization; malicious employees will try to harm you, as well, and you get little to no warning of those. Do your interns need root on machines containing customer data? Employees are users too.