Specifying secure code
A look at the National Vulnerability Database might lead you to believe that writing secure software is almost impossible; security flaws for almost every popular application appear in the NVD. Part of the reason that secure software is hard may be due to the way that specifications are written and the way that computer science classes are taught today.
Many of the worst security vulnerabilities that software has are due to the way an adversary can take advantage of careless processing of user-supplied data. Buffer overflows, SQL injection and cross-site scripting are all examples of attacks that are easily prevented if user-provided data is carefully checked for validity. These attacks all work by taking advantage of how invalid data is handled.
If an application carefully checks data for validity then these attacks can be avoided, and it may be possible to write specifications that require this. The problem is that most specifications aren't written with this in mind. The way in which algorithms and data structures are typically taught today seems to reinforce this.
It's common for computer science students to see proofs of the correctness of algorithms. These proofs typically show something like "given a particular input, this algorithm produces the correct output." What's typically not discussed is the case where unexpected inputs are provided. So an algorithm that processes a character string assumes that it's provided a valid and well-formed character string, for example. Algorithms designed under this assumption may be vulnerable to out-of-range or unexpected input, because what happens in these cases is totally undefined in their specification.
So one way to avoid vulnerabilities that are based on unexpected input might be to define the specification of the software more carefully. Instead of "given a particular input, this algorithm produced the correct output," such a specification might be extended to "given a particular input, this algorithm produces the correct output and raises an error condition if other input is provided." This may be fairly tricky to do, but it may also provide a way to eliminate most of the exploitable security flaws that software now has.





Comments