Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

12/3/2015
10:30 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

The Programming Languages That Spawn The Most Software Vulnerabilities

PHP, ASP Web scripting languages breed more vulnerabilities than Java, .NET programming platforms, Veracode's new state of software security report says.

The wave of WordPress and Drupal vulnerability warnings and patches over the past couple of years, as well as the never-ending discovery of SQL injection bugs in Web applications, can actually be traced back to their underlying scripting language -- PHP.

Some 86% of applications written in PHP contained at least one cross-site scripting (XSS) vulnerability and 56% came with at least one SQL injection bug, according to new research released today from Veracode, which studied applications written in the most pervasive programming languages -- PHP, Java, Microsoft Classic ASP, .NET, iOS, Android, C and C++, JavaScript, ColdFusion, Ruby, and COBOL. The data is based on its cloud-based scans and code analysis of more than 50,000 applications in the past 18 months.

Some 64% of applications written in Classic ASP and 62% of those written in ColdFusion had at least one SQL injection bug. Meantime, .NET and Java fare the best, with far fewer instances of security flaws in their applications: 29% of .NET apps and 21% of Java apps were found with at least one SQL injection bug.

Chris Wysopal, founder and CTO of Veracode, says PHP's problems are one of the reasons SQL injection -- one of the most abused yet easiest vulns to fix -- just won't die. "When I see a breach, one of the things that sticks out in my head is 'I'll bet that was a PHP site.'" Wysopal says. "What keeps some of these vulnerabilities alive and well is using languages that are harder to program securely.

"I had always suspected that scripting languages are worse. Now we have solid data to show we are getting twice the number of serious issues on those languages," he says.

It comes down to how these programming languages are designed, and their use. While Java and .NET have built-in functions to reduce the risk of buffer overflows, XSS, and SQL injection, PHP and ASP don't come as well-equipped and have fewer security APIs. According to Veracode's report, it traditionally has been difficult to write apps in PHP that "bind parameters in SQL queries," making it more prone to SQL injection flaws.

"It's harder to program in those languages [scripting languages]. There are not as many built-in functions," Wysopal says. "And .NET and Java programs are typically used by computer science graduates who learned those languages in school. A lot of the scripting languages like ColdFusion and ASP came out of the Web dev world, where you're designing websites and starting to learn coding, [and] to make sites more interactive."

These languages also fail the OWASP Top 10: four out of five apps written in PHP, Classic ASP, and ColdFusion failed at least one of the application security standard's benchmarks. Veracode points out that this has a big impact on the Net overall, as some 70% of content management systems on the Web are PHP-based WordPress, Drupal, and Joomla. So "organizations seeking to use these CMSes should carefully plan their deployments," Veracode said in its report.

"If I put on my attacker hat and want to break into a site, I'm going to find PHP sites," Wysopal says.

Developers are basically stuck with the language and platform their organization chooses. "It's not often that a developer gets to select that," he says. "They are kind of [limited] by the environment and language they need to build their applications on."

That's not to say they can't be better trained to write secure code. Veracode also studied vulnerability remediation rates, which showed a 30% improvement in vuln fixes in organizations that employ secure coding training for its developers.

Mobile

Veracode also found mobile applications in both Android and iOS contain rampant cryptographic weaknesses. There isn't much daylight between Android and iOS app crypto bugs, either:  some 87% of Android apps were found with the bugs, and 81% of iOS apps.

Wysopal says it came down to four issues: insufficient entropy or "randomness;" not checking SSL certificates; not encrypting sensitive information to disk; and using outdated crypto algorithms. "Developers are not understanding how to write crypto properly," he says.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
ryanwinchester
50%
50%
ryanwinchester,
User Rank: Apprentice
12/10/2015 | 11:09:07 AM
Re: Developers get to choose their languages often
I'm self-taught PHP developer and even I know to use prepared statements.

These days, the only people who are writing insecure PHP are the people who don't care to. The language is not what it used to be.
TerryB
50%
50%
TerryB,
User Rank: Ninja
12/4/2015 | 1:34:30 PM
Re: Developers get to choose their languages often
>>PHP is quite easy to develop secure applications in, you just need to know how to do it.

Based on this article, I'd say people as knowledgeable as you on PHP are in the minority. InfoWeek just had an article talking about hottest IT freelance jobs, PHP was at top of list. How many of these freelancers do you think know their stuff like you versus learned the language in a two year tech school (or self taught) because it was easier than learning Java?

PHP reminds me of RPG in the pre internet days, when COBOL ruled the world. RPG (Report Program Generator) was conceived to be a quick and dirty way to create reports on IBM servers, versus the verbose COBOL. But then people started writing complex CRUD apps with it, including entire ERP systems. You talk about some of the worst code you have seen (or tried to maintain) in your life.

PHP had similar origins. In the early days of HTTP apps, when security was an afterthought, it was intended to be a quick and dirty way of getting a CGI app created. Especially in UNIX world, which had no built in languages or databases. But then, as you say, people began building online banking/e-commerce sites with it, when security mechanisms were not even baked into the platform yet.

You'd like to think modern developers are all getting educated now on SQL injection and XSS exploits regardless of programming languages they use. But I suspect their focus is on producing working apps as they learn, not doing deep dives into the language features to verify they are secure.

I'll be honest, I use Sencha's Extjs and Touch now, though strictly for internal company use. But it never even occurred to me to research whether Extjs handled XSS, and how it did it. I did so after reading this article, even though in my use case I don't have to worry about XSS.

Always being a developer on IBM servers, I've always avoided using scripting languages like PHP and coding SQL statements for the database I/O. By using compiled programs and stored procedures at the backend, you completely eliminate the possibility of SQL injection, don't have to chase whether the "drivers" are protected against such exploits. The problem is, the UNIX world doesn't have such luxuries and the world wants to use cheap commodity servers and free databases with no integration with underlying o/s.

That makes things pretty tough on developers for those platforms. But glad to hear people like you that actually know what they are doing exist in PHP world. :-)
dawgbone
50%
50%
dawgbone,
User Rank: Apprentice
12/4/2015 | 11:26:27 AM
Re: Developers get to choose their languages often
Except of course languages like PHP have come a long way in terms of having fixed these issues. The problem lies in the fact that many of the resources that exist out in the world are a). Old and b). Badly written.

For instance, PHP fixed SQL injection issues long ago with the PDO driver and prepared statements. One of the very first google results for "PHP insert into database" returns a tutorial using the deprecated mysql driver (and flat insert statments with no talk of sanitization).

The one knock you can make on PHP in this is:

Why let people still use the mysql driver?

The good news is they finally have. It's now been completely removed in PHP7. The argument against removing it before was that while it took a lot of steps, it was possible to create secure applications using the mysql driver and breaking all of those wasn't a popular idea.

The biggest issue is that because there is so much content on the web on PHP, and a lot of it is massively out of date, we've had new programmers come in and create applications with security holes. PHP is quite easy to develop secure applications in, you just need to know how to do it.
kcisobderf
50%
50%
kcisobderf,
User Rank: Apprentice
12/4/2015 | 10:21:10 AM
Re: Developers get to choose their languages often
Not hobbyist, H1-B. I agree with the rest of it, though.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
12/4/2015 | 9:11:03 AM
Re: Link Broken
The link is now working--thanks!
RobThaBlob
50%
50%
RobThaBlob,
User Rank: Apprentice
12/4/2015 | 8:17:02 AM
Link Broken
The link to the actual report is broken.
ahetal
50%
50%
ahetal,
User Rank: Apprentice
12/4/2015 | 6:48:19 AM
Re: Developers get to choose their languages often
"PHP has shown no interest in revising aspects of their framework" - this is wrong in every sense. PHP is a language not a framework.

" they are designed to be used by the least-skilled programmers of all" - and this is applyed to all the languages that are listed as the most safe of them all.

the lower you get in the coding level, the less safe the language becomes.

to me, the less safe of them all would be assembly. 

you can do everything in assembly, thus, with more power comes more responsability.

most of the guys I know who work with those "not safe" languages either are not experienced enough to do it, or they don't have the time to do it as it should be done.
on the other side, if you use one of those "safe languages" "designed to be used by the least-skilled programmers of all", you don't have to worry about it.

 

problem is, almost nobody worries about it, no matter what language they work with.


and so we blame the language, not the poor coding. (fanboys love to do it.)
googlymoogly
100%
0%
googlymoogly,
User Rank: Apprentice
12/3/2015 | 1:35:10 PM
Re: Developers get to choose their languages often
ColdFusion has had the cfqueryparam tag for over a decade.   It makes databinding easy.  It makes addressing that aspect of sql injection easy.    For it to not be used says nothing about ColdFusion.  It does show that a lot of developers using it are off in their little bubble worlds and lacking essential technical skills.
ajones980
0%
100%
ajones980,
User Rank: Strategist
12/3/2015 | 1:19:10 PM
Developers get to choose their languages often
I'm not at all surprised by Veracode's findings - and the languages on the 'worst' list all have the same thing in common - they are designed to be used by the least-skilled programmers of all, and were initially targeted at hobbyist, or at least non-specialist, developers. They attract poorly-skilled developers and the results are predictable. But it's not just a marketing issue, it's also a question of how the language / framework owners react to security issues in their software. Classic ASP was written before Microsoft got religion about security - and was largely deprecated as a result of moving to a much more secure ASP.NET world. ColdFusion, I'm not familiar with, but hey, Adobe, right? Not the best reputation in town. PHP has shown no interest in revising aspects of their framework which make it difficult to securely develop.
I am surprised with the claim that developers don't get to choose the languages in which they develop - my experience is the polar opposite. Sure, they are initially hired to work with specific languages and frameworks that are already in use, but when a new project comes along, the first stage seems to be selection of the framework in which to develop it. And very often, those choices seem driven more by fashion / religion than by a comparison of the desired product's features and functionality and the framework's capabilities. Expect to see new unsecure PHP apps developed by the shovelful.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
'BootHole' Vulnerability Exposes Secure Boot Devices to Attack
Kelly Sheridan, Staff Editor, Dark Reading,  7/29/2020
Out-of-Date and Unsupported Cloud Workloads Continue as a Common Weakness
Robert Lemos, Contributing Writer,  7/28/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16271
PUBLISHED: 2020-08-03
The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 generates insufficiently random numbers, which allows remote attackers to read and modify data in the KeePass database via a WebSocket connection.
CVE-2020-16272
PUBLISHED: 2020-08-03
The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 is missing validation for a client-provided parameter, which allows remote attackers to read and modify data in the KeePass database via an A=0 WebSocket connection.
CVE-2020-8574
PUBLISHED: 2020-08-03
Active IQ Unified Manager for Linux versions prior to 9.6 ship with the Java Management Extension Remote Method Invocation (JMX RMI) service enabled allowing unauthorized code execution to local users.
CVE-2020-8575
PUBLISHED: 2020-08-03
Active IQ Unified Manager for VMware vSphere and Windows versions prior to 9.5 are susceptible to a vulnerability which allows administrative users to cause Denial of Service (DoS).
CVE-2020-12739
PUBLISHED: 2020-08-03
A vulnerability in the Fanuc i Series CNC (0i-MD and 0i Mate-MD) could allow an unauthenticated, remote attacker to cause an affected CNC to become inaccessible to other devices. The vulnerability is due to improper design or implementation of the Ethernet communication modules of the CNC. An attack...