Programming language security: These are the worst bugs for each top language
Static code analysis security firm Veracode has released numbers on the types of vulnerabilities that are most prevalent in 130,000 apps it scanned for security issues.
The main issue for applications written in .NET is information leakage, found in 62.8% of .NET apps, while for C++ error handling is the top issue, found in 66.5% of these apps.
And for Java apps, the top flaw found is Carriage Return or Line Feed or CRLF injection, present in 64.4% of them. Finally, the top security problem for Python apps, present in 35% of them, relates to cryptography.
Veracode chief research officer Chris Eng explained to ZDNet why some of these trends in vulnerabilities in apps written in different languages are occurring and how to ensure they don’t become an expensive headache to fix.
“When we look at the overall numbers, as an industry we haven’t eradicated any category of flaw over the past 10 years,” says Eng.
“Nothing has completely gone away. A lot of things are fluctuating but when you look at the averages, it tends to more reflect the change in language choice and language popularity more than anything else.
“We see buffer overflows that are common in C++ are trending down, not so much because we’ve gotten better as developers at reducing those issues but because C++ is becoming less prevalent.”
PHP remains one of the most popular scripting languages for web application development, but Eng says the higher number of vulnerabilities in PHP code is because the language provides so many unsafe primitives and a lot of ways to do things wrong.
“.NET was one of the first ones to make it a little harder to shoot yourself in the foot,” explains Eng.
“You have safer defaults around a lot of the APIs and you see it’s a lot harder to make a cross-site scripting mistake or a SQL injection mistake in .NET than it is in PHP, where it will be default – unless you happen to be using one of these more modern frameworks that might provide more protections for you – there’s just a lot of ways you can mess up.”
“Even if you were to go and fix all the vulnerabilities you’ve coded yourself, you still have a pretty wide variety of third-party libraries,” says Eng.
“Patching is really not as good as you would hope it would be. The trend is that developers download the latest version of the library at the time they need it and then they never update it again, unless something functionality-wise breaks.”
How should engineering and product teams keep the hassle and cost of patching key applications down? Eng’s advice is to stay up to date and be aware of how much tech or security debt has built up in an application over time. At some point, the app will need to be fixed or patched, and that includes language updates and patches to key libraries.
“If I’m version on 4.5 and version 4.6 comes out, I can apply that patch with very little chance of anything breaking functionality-wise. No open-source library is coming to make a major change to the library in a minor version. Now if you’re on version 2 and then you have to upgrade to version 4.6, there’s gonna be a lot of pain,” says Eng.
“Any time there’s a vulnerability in one of these packages, you inherit that risk. And it’s not just security risk,” says Eng.
“It disappears off GitHub and suddenly two-thirds of the internet breaks because they were depending on this four-line library to determine whether a number was left-padded with zeros.”