A Security Lesson that Transcends Programming Language and Operating System Religion
Hi, Michael here.
A few weeks ago, my boss, Steve Lipner placed a copy of eWeek on my desk opened to an article entitled, “Java Security Traps Getting Worse.” In summary, the article, which is also available online (http://www.eweek.com/article2/0,1895,2128071,00.asp) lamented the state of security in applications written using Java. I’ll let you read the article and draw your own conclusions, but I have my own thoughts on the problem, and I want to explain my position by way of example.
In 2003, I presented a paper on the SDL at the Workshop on Software Security (http://dimacs.rutgers.edu/Workshops/Software/abstracts.html) and the topic of conversation turned quickly to how bad the C and C++ programming languages are from a security perspective. Someone from the audience shouted out that “We should just ban C and C++ and replace it with Java.” I replied that we could ban <insert programming language of choice> and replace it with <another programming language of choice> and we’d still have lots of security bugs. I said this because programming languages by themselves don’t make secure code, but I believe that a number of people believe they will. I think a good many people believe that so long as the language is not C or C++, then the code is inherently secure.
This belief in a programming security silver bullet is very dangerous, and I believe we address this nicely in the SDL. In fact, a lack of a silver bullet is a core principle of the SDL. We teach people, actually, no we don’t teach people: we ram it down engineer’s throats: the number one skill a person designing, building or testing software should learn is that input should never be trusted. Regardless of OS or programming language. Ever.
Don’t get me wrong, I’m not bagging the data in the article; I’ve seen people believe that .NET code is a security panacea, and it’s not. In all of our SDL education we stress the point that .NET code is not a security cure-all, and we make sure that developers understand that if you choose to ignore the golden rule about never trusting input no language or tool will save you. Using safe string functions can help mitigate risks of buffer overruns in C/C++, but won’t help with integer arithmetic, XSS, SQL injection, canonicalization or crypto issues.
The key point is that languages are just tools; anyone using a tool needs to understand the strengths and limitations of any given tool in order to make informed use of the tool.
One final thought; in my opinion, well-educated software developers using C/C++ who follow secure programming practices and use appropriate tools will deliver more secure software than developers using Java or C# who do not follow sound security discipline.
