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.

Comments
The Programming Languages That Spawn The Most Software Vulnerabilities
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.


News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3493
PUBLISHED: 2021-04-17
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivile...
CVE-2021-3492
PUBLISHED: 2021-04-17
Shiftfs, an out-of-tree stacking file system included in Ubuntu Linux kernels, did not properly handle faults occurring during copy_from_user() correctly. These could lead to either a double-free situation or memory not being freed at all. An attacker could use this to cause a denial of service (ker...
CVE-2020-2509
PUBLISHED: 2021-04-17
A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS 4.5.2.1566 Build 20210202 and later Q...
CVE-2020-36195
PUBLISHED: 2021-04-17
An SQL injection vulnerability has been reported to affect QNAP NAS running Multimedia Console or the Media Streaming add-on. If exploited, the vulnerability allows remote attackers to obtain application information. QNAP has already fixed this vulnerability in the following versions of Multimedia C...
CVE-2021-29445
PUBLISHED: 2021-04-16
jose-node-esm-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...