Slashdot Mirror
The Top Programming Languages That Spawn the Most Security Bugs (softpedia.com)
An anonymous reader writes: Veracode has put together a report after static analysis of over 200,000 apps, and its results show that Classic ASP, ColdFusion, and PHP generated the most security bugs in scanned applications. Ignoring the first two, which are almost extinct languages, PHP, used for Drupal, Joomla, and WordPress (which recently announced it runs a quarter of the Internet) is the programming language with the most security woes.
Just wondering.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
The Internet is a lot bigger now, so you'd expect more discovered PHP bugs than ColdFusion bugs.
Coming up next, there are more operating systems written in C than Fortran, so you will find more root privilege escalations in C than Fortran.
It's pretty obvious the most common language is going to have the most apparent bugs and the most security woes because it is the one that is most used to solve the majority of problems. It also will be the most likely for hacker and bad people to be using as well as working to exploit as it is the language that they are most familiar with. Every language is going to have security issues it's what happens with the running application when it faults that matters, and that is likely within the control of the developers even when the language and library authors are contributing to the issues. Really, the number one "cause for exploits" is trusting input that shouldn't be trusted -- and that's that same problem for nearly any language... It has nothing to do with PHP!
That's the bigger problem than the limits of an individual language. The mindset of gluing together little bits of existent code to add serious functionality to what was originally intended as a static information display. Odds are the budget for these projects is tiny and the testing budget is zero. That last detail is what really matters, no dedicated testing, no time allotted for testing beyond 'does it work when the boss tries.'
ASP, ColdFusion and PHP are only the top three because (despite two being "extinct" according to whoever wrote the summary) they are the top 3 languages for quickly kludging new functionality into fairly simple web pages.
Good thing I'm still using Perl!
Modern app appers know that only apps can app apps, so the Internet would be MUCH more secure if you used app apps instead of LUDDITE languages like PHP!
Apps!
Especially for PHP you will notice that it is the first, if not the only, language people pick up when dealing with scripting for web pages. ColdFusion always smelled a bit like a web designer tool to get some kinda-sorta interactivity into their designs rather than something a programmer would willingly pick up, and I don't know of anyone who seriously learned programming and didn't give ASP a wide berth.
So what you have there is three languages that are predominantly used by people who cannot program sensibly.
In other words, you are dealing with the usual woes of cargo cult programming and copy/paste code. Code and snippets, copied and gobbled up from whatever sources there are on the net, sample code and code Q&A pages that are slapped together and adjusted to fit the needs. Primary concern: It should work. Security? Doesn't even enter the picture. Not even as an afterthought.
That this results in security bugs is a given.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Are "iOS" or "Android" the same as "PHP" or "C++"? I didn't hand in my personal informatoin to get the full study, but the stuff shown on this story's link pegged my bs-meter. Also, I'd hope there's a discussion of 'number of occurrences,' finding 10 bugs, 8 of which are null pointer dereference, should be different from finding 10,000 bugs where 'only' 7,500 of them are null pointer dereference.
And wouldn't it be even more useful to know which languages generate the least number of bugs, per line of code?
Two of the items on the list, iOS and Android, are not programming languages. Why do they appear on a list of programming languages? When you combine "Java" with "Android", the total of 62 flaws still can't top PHP's "King of the Hill" status.
If this was from a dynamic scanning company, I would have suspected these results would occurred because that code often run in environments often configured to show web users raw error output, such as "your database call failed - here's what I tried so you can tune your SQL injection attempt appropriately."
[rant] In general, I've found that the utility of "dynamic" (or pentesting) web scanners has dropped precipitously lately as web apps have pushed their presentation out to Javascript apps (making it easier to probe a finite set of web services with standard testing and fuzzing tools) and almost all new environments are set to display terse "got error - now fuck off" messages to end users (if not just a redirect back to the app's home page) if a probe generates an error (that would have generated useful output 10 years ago). [/rant]
>> Ignoring the first two
This is a horrible assumption to make. I remember I looked at bringing Veracode in house specifically because I had a multi-million line legacy web app written in "classic ASP" that powered several hundred million dollars of annual purchases.
Fuck
Observation: Most people are right-handed.
Observation: Lots of people kill each other.
Conclusion: Right-handedness makes you kill people.
Something like 75%-80% of the web runs on php (Wordpress, for example.) Naturally if you examine a large number of sites, most of which run on php, you're going to see more security problems coming from sites that run on php.
Now I'm not saying php hasn't had language-based security problems in the past (and currently), but anyone who still thinks it's as porous as it was when version 4 was current needs to do their homework. Nowadays most of the issues come from stupid code, not the language itself. php's low barrier to entry attracts people who don't know how to write a more-secure web app in disproportionate numbers. See this for how to do it right.
Never underestimate the power of stupid people in large groups.
DISCLAIMER: I barely even read the summary.
The problem is the users, PHP is so ridiculously easy to write it leads to people making horrible insecure "awesome" webpages.
I assume they give the details on how this was done in their security report, which requires registering to download. From their wording they have a tool that scans for common security issues and report them. So where things ranks depends heavily on how accurate the tool is.
Of interesting note is that java is higher than .NET and C++ on flaws, but lower on the list of critical flaws
Javascript is at the bottom. My guess that is because you generally run javascript on the client, and good server architecture doesn't trust any javascript code.
Classic ASP has more than 80% of the bugs. Why just ignore it? It ought to be a dead language, but it isn't. I happen to know that there is active programming happening in Classic ASP even now, despite the bugs.
A finger is instead pointed squarely at PHP, which, with 25% of the applications represented on the internet, only represents less than 8% of the flaws. Not that I have any particular bias towards PHP, I don't even use it, but the finger needs to be pointed at where the trouble spots are, and Classic ASP tops the heap.
Yesterday, I did a good deed. I taught a guy how to use ADO Commands and Command Parameters instead of inline SQL. He was running the inline SQL through some filters to try to catch certain SQL commands in an attempt to defeat SQL injection. So maybe the flaws/MB in Classic ASP will go down by some tiny iota.
If you are not allowed to question your government then the government has answered your question.
Researchers cautioned people against carrying their smartphones in purses, handbags, or pants pockets, as studies have found that these are the most likely targets of pickpockets.
You can write secure code in any almost any language (unless the run-time system is insecure, see for example the history of Java), and you can write insecure code in any language (yes, even in Rust, Swift and Go and other newfangled but not really better hype-languages). The difference is not the language. The difference are the people doing architecture, design and implementation. If some languages have more security problems, that is primarily because these languages attract less competent coders.
Incidentally, absolute numbers are irrelevant. What we need is issues per application.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So what languages for apping web apps aren't Luddite? Now that Swift is free software, would it be worth it to tailor Swift for server-side use?
So much, then, for managed languages. I thought managed pointers and garbage collection were supposed to free us from all those ills, but evidentally not.
Shame that further down they perpetuate the myth of the C/C++ language. That language doesn't exist - it's either one or the other. In C you'd use raw memory pointers if you wanted to pass a buffer around, making it easy to access it beyond its boundaries. In C++ you'd pass a buffer object that knows its own size, and either dynamically resizes or at least throws an exception on an illegal access.
Because C and C++ have such vastly different approach to the same problem I'd love to see C and C++ split out.
Two of the items on the list, iOS and Android, are not programming languages. Why do they appear on a list of programming languages?
Because it's poorly named and should have been called a list of "platforms" more than languages. The opportunities to introduce defects using Java in the javax.servlet framework are very different from those using Java in the android framework. Likewise, the characteristics of bugs in C# and Visual Basic web apps should be fairly similar because both use the ASP.NET framework.
We have quite a few classic ASP applications running. They were coded over a decade ago when that was what you used to develop web applications on IIS. I'd love to port these to PHP or some other language, but it's a time intensive process (both rewriting the code and testing it to find the bugs that the rewriting process introduced) and we don't have the manpower to rewrite EVERYTHING.
Unfortunately, I've been directed that all new applications are to be written in Cold Fusion. So I'm moving from dead language to "I'm not dead yet. I feel happy." language. (I do PHP work on the side and am learning other languages like Python and Java to keep my skills up to data.)
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
See subject: Small wonder things are as f'd up as they are online, look @ who's leading the charge!
* The tools you use blow boys...
(This IS the "BIG WHY" of WHY I steer clear of that end of things IF I can help it... yes, there's "mitigation" measures you can take to stop things like SQLInjection (stored procs & bound variables + DB & OS security as well as code security) but when the language tools themselves have cracks in their foundations, this IS the result you get!))
APK
P.S.=> You guys MAY not LIKE what I write but it's harsh reality, & so is seeing nigh daily exploits of the 'products' produced by you all - if you don't LIKE it, well, then that's fine by me too - what isn't fine is the results you're all producing (which yes, is part your faults, but also the fault of the "new hotness" bs that's proving "OLD & BUSTED" right outta the gate + continuing to be so)... apk
Exactly this. Take classic ASP, for example. It's not the most recent language by any stretch of the imagination, but it's easy to check user input and escape it to prevent SQL injection attacks.
SQLQuery = "Select UserID where Name = '" & Replace(UserEnteredName, "'", "''") & "'"
The above will allow you to take the user entered name and put it into a SQL query without fear of little Bobby Tables wrecking havoc with your systems. Too many developers (across many languages) just write their code quickly and don't constantly keep thinking "how can this code be broken and how can I either prevent the breakage or gracefully recover?"
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
OK, so if I want to decrease my C++ vulnerability per MB of code metric, all I need to do is, depending on your definition of code, write a C++ program to produce large statically allocated arrays of garbage, or write a c++ program that... OH YES... FUNROLL LOOPS ON NOP INSTRUCTION..... I'm sure gcc will comply if I make that the only optimization, right?! Just increase the loop iterations to increase security! GENIUS!
Prepare for an incoming barrage of anti-php cranks impotently venting their spleen.
"php is the suckage!!1!"
"php is the worst thing since Adolf Hitler!"
"php murdered my entire family and posted the pictures on facebook!!!"
"php melted the icebergs and turned Tom Cruise gay!!"
"only fagz and copy-pasta lamers use php!!!"
"Rasmus Lerdorf is a commie!! never trust a commie!!"
. . .etc etc etc . . .
Meanwhile facebook continues to chug away (you may have heard of them) as do many of the other major php-powered sites on the internet. But never mind that, keep telling us how php is no good and awful and despicable and rotten and whacky and noobish and and and and and.......
Personally, I wouldn't consider functional bugs to bugs in the language, unless there is no way to accomplish a task without generating exploitable bugs.
The standard library has bugs. For example, one bug in PHP is the existence of mysql_escape_string, whose behavior is unlikely to match the quoting conventions set on the current connection except by coincidence. These bugs are kept for the sake of backward compatibility, even if they're exploitable by using an incorrect quoting convention for SQL injection.
But it is a bug to fail to discourage new code from using deprecated library functionality. Failure to conspicuously mark deprecated functionality as such in the manual, such as by changing the background styling, is a bug. Failure to log use of deprecated functions by default is a bug. Requiring the server operator to silence deprecation warnings server-wide just to run a particular legacy app is a bug. This means the server administrator or shared hosting customer needs the ability to suppress logging of particular deprecated functions used by particular legacy apps while continuing to log other deprecated functions and the same functions used in other apps.
ISO/IEC JTC1/SC22 has had a group looking at programming language vulnerabilities, including (a) how to define a 'vulnerability'; (b) how to assess languages against those definitions; (c) an assessment of languages (that have de-jure standards) for vulnerabilities, and related work. There is an introduction here http://www.open-std.org/jtc1/s... and the work is documented here: http://grouper.ieee.org/groups...
(Do you suppose the authors of this report are aware of the ISO work?)
Some examples where things are more to do with the context than the language.
For example, SQL injection very very high proportion of php code deals with a SQL database. However in other languages, this isn't quite as ubiquitous. The likelihood that a C++ application even touches SQL is far lower than a php application. Same for XSS (they referenced locally running iOS and Android applications, suggesting that not all code might even be dealing with scenarios where XSS is applicable).
There are a few things where language choice is a factor (buffer overflow, buffer management), but there's a lot of attempts to compare very different applications to each other and assume equivalence.
This is about problem domain where the language is popular more than it is about the language. It's an interesting commentary on the sorts of mistakes developers should be on the lookout for and perhaps motivation for language runtimes to think about things they might possible mitigate, but hard to say 'php is plain worse than objective c', which is what the report is saying.
XML is like violence. If it doesn't solve the problem, use more.
So they are all languages commonly used by novice dabblers to make Web front ends. Is the next report going to show that the sloppiest code is VB? Or that the most commonly pooped in garment is a diaper?
We have more issues with the bugs our developers write than the ones inherited from the programming language.
Kind of makes me wish that standards for different languages would refuse to accept normal strings as arguments to anything that "executes a statement" (SQL, shell commands, etc), and instead require a custom command-string type/class which does not allow straightforward concatenation (making developers explicitly have to convert types if they want to concatenate, maybe with a conversion function name like "useUntrustedString" or somesuch), with the error message if they try to concatenate without explicit conversion pointing out not just that concatenation is banned, but stating why it's banned.
Say you want to write a SELECT statement in SQL, but you want to give the app's user options for what information is included in a report. These options may cause the statement to refer to different columns in the heading, or a JOIN to different tables, or different columns used for summary (GROUP BY). For these kinds of query adaptation, you can't use a prepared statement because the PDO API allows substituting only literal scalar values (such as 3 or 'kitten') into a prepared statement, not table names, not column names, and definitely not entire JOIN clauses. What's the best practice to securely build queries at runtime like this in a language that bans concatenation of SQL strings? Encouraging useUntrustedString for things like this would just encourage users to use all useUntrustedString all the time.
Languages make it easier or harder for programmers to inadvertently make bugs.
Java web apps would typically split the presentation, logic and storage from each other and the storage would be via Hibernate / OpenJPA.
Do you also advocate separating storage from search? SQL can do both in one command. How does search work in Hibernate / OpenJPA? Does the application have to maintain all indexes itself?
Veracode returns so many false positives, you have to grind through their reports every time before you present the findings to the team for remediation. I experience this joy monthly, so I have no faith in their numbers at all.
Or even better, you don't even have to copy the code, you just need to type the google terms that result in the appropriate SO question as the first hit.
That'd bring new meaning to "full Stack developer".
>> I'd love to port these (classic ASP apps) to PHP or some other language...all new applications are to be written in Cold Fusion
Why not port to ASP.NET? I've done that conversion dozens of times now. And what kind of hell are you living in that Cold Fusion is even on table?
I don't see any proof of causation, only correlation and even that is not well documented since there is no attempt to correlate programmers to bugs, or application type to bug or industry, etc, etc, etc.
If MOST applications written by crappy programmers are done in a industry that normally attracts people that taught themselves to program yesterday and pays accordingly is there any surprise they might have a lot of security issues?
Wordpress is designed to be used by people that have no idea how to spell security (obviously some "real" programmers use Wordpress but MOST users and the target market are not).
I think this study is bogus.
>> above will allow you to take the user entered name and put it into a SQL query without fear of little Bobby Tables wrecking havoc with your systems
[FACEPALM/] That's not even "checking user input" (i.e., making sure the user submitted an expected response) - that's "mindless scrubbing of a single naughty character."
Please send me a couple of the URLs where your apps live and I'll just go get the rest of I want from there.
I have helped develop a low budget site using coldfusion, as an unpaid volunteer. There is a lot of M$SQL too. I'm neither a security expert or a Coldfusion expert. There are other developers who are more experienced, but there has never been a security audit. I would be interested in the tool(s) used in the study, to scan our site for security issues. Are those tools or similar tools easily available (remember - low budget).
This must be a troll.
Use proper parameterized queries, moron. There is no amount of escaping and concatenating that is going to make your queries guaranteed clean, forever, for all databases.
I'm an old coder and learned to take responsibility for my own mistakes and not blame the tools I used. Of course, in those days we actually understood how our tools worked and what they actually did for us. Today's programmers use modules and frameworks and other neat named tools without any real understanding of the underlying workings... just plug and play. Is it any surprise that a lot more bugs crop up. Even when you know what you're doing it's easy to make mistakes but when you don't really know what you're using it's pretty much guaranteed.
Given its immense popularity and how quickly/easily it is to deploy insanely fast, it makes sense for it spawn a large number of security bugs. I love PHP but if you don't know what you're doing (like 90% of "PHP devs") it can be dangerous.
Meanwhile, of the 3 "top 10 globally ranked" websites I found security exploits on, only one was written in PHP. But the exploits had nothing to do with the language, but with the inexperience of the developers.
Why not go one step further, do "the right thing" and use ADO Prepared Statements?
I say this as a long time PHP developer. I've fiddled with other scripting languages (Python, NodeJS, Java/Tomcat), and I just find they are not very well suited for a web environment, so I always come right back to PHP.
The problem is actually a few different things, not necessarily related to PHP itself:
- Outdated installations are everywhere
- Outdated and very poorly written Tutorials are even more prevalent
- Lack of general understanding of security is a problem not relevant to any programming language
Many of the security problems with PHP have been addressed long ago when the initial release of PHP 5 came out, and a few more since then.
When interfacing with a Database, developers are now using PDO or a mechanism provided by their framework (usually built on top of PDO). This in and of itself has completely eliminated SQL injection attacks. The problems still cropping up are legacy applications that haven't been updated. Many of these can partially be attributed to outdated PHP installations.
The majority of web hosts run cPanel. cPanel has been making big changes to their product. A few things they have done recently:
- Dropped support for old PHP versions (oldest supported is now PHP 5.4)
- Shifting to a binary package system (via yum repository) for PHP/Apache with safer default configs; previously it was up to the Admin to compile, install, and configure, also supports automatic updates
- Included a mechanism in Apache to configure/utilize multiple PHP versions on a per-user, per-directory basis
- Included support for Apache MPM-ITK; allows each virtualhost to be run as a specific UID:GID instead of all sites running under the same UID, greatly increasing per-account security so long as each accounts file permissions are secure.
Don't forget: this is not "languages that have the most bugs" it's "languages that have the most bug detectable with static analysis"
JavaScript MAY be low because it's harder to statically analyze.
Thanks for that link. I'm not sure how I didn't know that classic ASP had prepared statements. Of course, my preferred method would be to convert the entire application off of classic ASP, but this might be a good stop gap method.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
Programming languages do not spawn bugs.
Programmers spawn bugs.
It isn't the language, but how it is used. Most php developers do not use in the object-oriented manner that it was intended, so most php applications are a mish-mosh admixture of php, javascript, and html that are impossible to read, and very difficult to make secure.
unless you have a DBMS that includes robust search functionality (which really means having a separate store of the data, an index, that is optimized for search rather than relational integrity).
It's not full text, but SQL offers some automatic indexing functions. For example, it's trivial to index products by SKU, by price, by brand, by date added, by category, etc. In fact, when one object refers to an object in another table, these "foreign keys" are automatically indexed. The tradeoff is that indexes in the database are subject to slowdown to maintain consistency guarantees at all times.
I would say that is relatively accurate. Their premise, however, is very reaching and over generalized in my opinion. (Correlation vs Causation)
The languages themselves do not lend to more or less security/secure practices. There are paradigms and practices for everything, programming included. Statements like, "When I see a breach, one of the things that sticks out in my head is 'I'll bet that was a PHP site." are slighted. That's akin to saying someone who drinks Sanpellegrino must be a hipster and wear a scarf.
My counter point would be: A. Look at the sheer number of applications programmed in PHP versus other languages (PYPL, TIOBE). B. Look at the demographic of the people using the languages. PHP is easy to pick up, free to use, there are tons of resources, and it's widely supported.
This is similar to the, "We are finding more types of cancer in more people now than we did 50 years ago" idea. It reality, it's not that there is more today than before, but rather that we have more people and better technology.
I would also note that the company making the statement is not exactly objective as [software] application security is their business...
But it is nowhere near extinct. Adobe continues to support it and has new versions planned for future release - and there's an open source derivative of it by the name of Lucee.
Reaction to the name "Adobe" aside, there is a dedicated userbase for CF and new development within the platform is happening all the time. Whether or not those implementations are secure is largely up to the developers themselves.
This looks like that unsurprisingly that they are secuity issues in languages made for internet usage.
Classic ASP - Old Language for making Web Apps Used widely by a lot of Jr. Programmers of the 1990's .NET - Newer Language for making Web Apps Used widely by a lot of Jr. Programmers of the 2000's
ColdFusion - Old Language for making Web Apps Used widely by a lot of Jr. Programmers of the 1990's
PHP - Newer Language for making Web Apps Used widely by a lot of Jr. Programmers of the 2000's
Java - - Old Lanague for making Web Apps Used widely by a lot of Jr. Programmers of the 1990's
C++ - Lower Level language often used for teaching people how to code... A lot of room to create security issues.
iOS - OS not a language
Android - OS not a language
JavaScript - Newer Language for making Web Apps Used widely by a lot of Jr. Programmers of the 2000's
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
There are a lot of comments about the problems, but what is the best solution for a web serving platform?
.NET always seemed like more baggage and libraries to keep compatible with. Regardless of the reasons here I am 15 years later with hundreds of code files in mostly object oriented server side javascript. Clearly I need to get off ASP but no alternative ever seems tempting enough. PHP feels like a lateral step. NodeJS seems tempting. C# in .NET is a stable choice. Java seems older and being beat out by C#. Classic legacy system woes.
Of course first, its domain specific. So in my example, I started a Classic ASP site in 2000. Converting to
If you had a high volume website with hundreds of code files in object oriented classic ASP JScript (& MS SQL), what do you think would be the best platform to evolve to?
Congratulations on showing how DI attacks take place.
Always use parameterized statements; most places with coding standards don't even allow non-parameterized statements, in their codebase. If the language doesn't support support parameterized statements; use a mature language that supports them.
Some languages are much more concise than others. C++, being a lower-level language, generally requires more lines of code to implement any non-trivial task than other modern languages. The point is, I'm not sure what real significance there is to the metric "flaws per MB."
You are trolling right? There is just too much irony in that post for you to not be. If you aren't trolling, and you believe that is safe and sufficient anti-sql injection measures, then you might want to consider a different occupation.
They are, or at least were, often used for intranet projects, where security may be a smaller concern. Intranet habits are perhaps spilling over.
Table-ized A.I.
BASIC! :)
The day Microsoft creates a product that doesn't suck, it will be known as the Microsoft Vaccuum Cleaner!
which recently announced it runs a quarter of the Internet
Nop. It may run a quarter of the Web, but not of the Internet.
I'm not sure how I didn't know that classic ASP had prepared statements.
Strictly speaking, classic ASP didn't have prepared statements. Rather, ADO supported them with a uniform syntax that was translated for the target database engine, or implemented directly for non-DBMS data sources, such as Excel and a few DBMS data sources which didn't natively support parameterized queries. ADO prepared statements were accessible from anything that could utilize the COM server, including ASP pages, classic VB EXEs, jscript scripts, VBA, and so on.
- T