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.

The Programming Languages That Spawn The Most Software Vulnerabilities
Newest First  |  Oldest First  |  Threaded View
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.
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. :-)
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.
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
Kelly Jackson Higgins,
User Rank: Strategist
12/4/2015 | 9:11:03 AM
Re: Link Broken
The link is now working--thanks!
User Rank: Apprentice
12/4/2015 | 8:17:02 AM
Link Broken
The link to the actual report is broken.
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.)
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.
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.

I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
How Data Breaches Affect the Enterprise
Data breaches continue to cause negative outcomes for companies worldwide. However, many organizations report that major impacts have declined significantly compared with a year ago, suggesting that many have gotten better at containing breach fallout. Download Dark Reading's Report "How Data Breaches Affect the Enterprise" to delve more into this timely topic.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-11-27
janus-gateway is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
PUBLISHED: 2021-11-26
This affects all versions of package html-to-csv. When there is a formula embedded in a HTML page, it gets accepted without any validation and the same would be pushed while converting it into a CSV file. Through this a malicious actor can embed or generate a malicious link or execute commands via C...
PUBLISHED: 2021-11-26
@joeattardi/emoji-button is a Vanilla JavaScript emoji picker component. In affected versions there are two vectors for XSS attacks: a URL for a custom emoji, and an i18n string. In both of these cases, a value can be crafted such that it can insert a `script` tag into the page and execute malicious...
PUBLISHED: 2021-11-26
Backstage is an open platform for building developer portals. In affected versions the auth-backend plugin allows a malicious actor to trick another user into visiting a vulnerable URL that executes an XSS attack. This attack can potentially allow the attacker to exfiltrate access tokens or other se...
PUBLISHED: 2021-11-26
There is a Potential Zip Slip Vulnerability and OS Command Injection Vulnerability on the management system of baserCMS. Users with permissions to upload files may upload crafted zip files which may execute arbitrary commands on the host operating system. This is a vulnerability that needs to be add...