In an ideal world programmers would not have to worry about security because the language and compilers would protect them by doing the right thing. Unfortunately we do not live in such a wonderland.
Programmers must make a choice of one of the available languages (or write a new one!). That usually means tradeoffs in functionality, performance, security, etc. I will not even try to address the restrictions imposed by company politics, coming into an already partially developed project, etc.
In the end, the language chosen will be far from perfect. A good programmer knows the strengths and weaknesses of his tools. He plays to the strengths and *compensates* for the weaknesses.
Pick one: - wait for truly perfect language - don't bother with security - address security issues yourself
Yes it is completely true that C and C++ have unchecked pointers and array bounds that are frequently the source buffer overflow issues. However, any serious C programmer *knows* these issues exist.
The problem is that many programmers do not take the time to harden their programs against such attacks. They are often too focused on the program's real purpose to bother with security.
I should also point out that there are vulnerabilities in programs written in Perl (I'm not trying to pick on Perl specifically BTW). Often a CGI script can be passed a syntactic boobytrap in a parameter. Programmers can be lazy and forget about good input validation the same way they forget about overflow issues.
Another situation that programmers frequently miss is how the program behaves in low memory conditions. It is all to easy to assume that a memory allocation (implicit or explicit) will succeed. This may not result in a vulnerability, but it points to the larger problem.
The bottom line is that making programs resistant to attack requires attention to detail. Since this usually requires more effort on the part of programmers, we shouldn't be surprised that it is usually ignored.
Slashdot Mirror
In an ideal world programmers would not have to worry about security because the language and compilers would protect them by doing the right thing. Unfortunately we do not live in such a wonderland.
Programmers must make a choice of one of the available languages (or write a new one!). That usually means tradeoffs in functionality, performance, security, etc. I will not even try to address the restrictions imposed by company politics, coming into an already partially developed project, etc.
In the end, the language chosen will be far from perfect. A good programmer knows the strengths and weaknesses of his tools. He plays to the strengths and *compensates* for the weaknesses.
Pick one:
- wait for truly perfect language
- don't bother with security
- address security issues yourself
On the contrary, blame the programmers.
Yes it is completely true that C and C++ have unchecked pointers and array bounds that are frequently the source buffer overflow issues. However, any serious C programmer *knows* these issues exist.
The problem is that many programmers do not take the time to harden their programs against such attacks. They are often too focused on the program's real purpose to bother with security.
I should also point out that there are vulnerabilities in programs written in Perl (I'm not trying to pick on Perl specifically BTW). Often a CGI script can be passed a syntactic boobytrap in a parameter. Programmers can be lazy and forget about good input validation the same way they forget about overflow issues.
Another situation that programmers frequently miss is how the program behaves in low memory conditions. It is all to easy to assume that a memory allocation (implicit or explicit) will succeed. This may not result in a vulnerability, but it points to the larger problem.
The bottom line is that making programs resistant to attack requires attention to detail. Since this usually requires more effort on the part of programmers, we shouldn't be surprised that it is usually ignored.