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.

Comments

normalized?

[Anonymous Coward]

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.

Re:normalized?

[Anonymous Coward]

Not really. PHP has been shit from day one. Security wasn't a concern, hammering out data driven sites was priority #1, #2 and #3. It's a hack upon a hack.

That said, PHP isn't the problem, it's those using it aren't real programmers. They're invariable self-taught kids or admins. Sanitising input doesn't matter to them. Give a pro the same tool set, and you'll get a better product. But that's not what companies want, they want X on page Y up and running two days ago.

Re:normalized?

[Anonymous Coward]

They're invariable self-taught kids or admins. Sanitising input doesn't matter to them.

You really should be more careful with the generalizations.

This one of yours, for example, is provably false.

(It's invariably , by the way, but that's beside the point.)

Re:normalized?

[Anonymous Coward]

Wasn't it listed in bugs/MB? That is normalized.

Re: normalized?

[Anonymous Coward]

all the "comfort" features of php actually contribute to insecurity.

pascal and ada are way more robust.

Self-fulfilling prophecy?

[mindmaster064]

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!

Re:Self-fulfilling prophecy?

[Anonymous Coward]

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.

That argument doesn't work when the measurement is in bugs per megabyte.

This is bug density, not total bugs.

Re:Self-fulfilling prophecy?

[ranton]

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.

That argument doesn't work when the measurement is in bugs per megabyte.

This is bug density, not total bugs.

He said apparent bugs, not total bugs or even bug density. His contention was the most used languages will have the most people identifying security holes. Similar to how the most used operating systems will have the most people writing viruses for them. Just because one application has the most identified bugs doesn't mean another application doesn't have far more that are simply not identified.

I don't agree with the argument, since I think there is a threshold where a language is popular enough to have people combing it for vulnerabilities. C, Java, C#, Javascript, etc. have all passed that threshold.

Re:Self-fulfilling prophecy?

[paulpach]

There is more to it than simply being popular. Consider a case where you want to output data that the user posted in a form. The obvious way to do it in PHP is this:

Hi <?php echo $_POST['name']; ?>.

In fact up until a few years back, the php tutorial had code like this.

This is vulnerable code, the values posted may contain javascript, and the browser would execute it happily. If you are displaying content that other people posted, then a malicious user can easily exploit this code to hijack other users sessions. This is known as XSS (Cross site scripting), and it is one of the most common vulnerabilities in PHP code.

The secure way is this:

Hi <?php echo htmlspecialchars($_POST['name']); ?>.

A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else. For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value. In the name of convenience PHP is plagued by questionable design decisions like this. register_globals was on by default up until php 4.2, it is incredibly easy to write sql injection vulnerabilities in php if you are not paying attention, etc.

Re:Self-fulfilling prophecy?

[tepples]

For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value.

Which would make it that much harder to use PHP to output a Content-type other than text/html or types matching application/*+xml.

Re:Self-fulfilling prophecy?

[budgenator]

The secure way is this:

Hi <?php echo htmlspecialchars($_POST['name']); ?>.

A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else.

Could you give that example in C, C is normally considered a good language.

Re:Self-fulfilling prophecy?

[hey!]

While I strongly agree with the argument that PHP's large target footprint has something to do with its reputation for insecurity, I can't help but wonder whether the architectural similarities of typical PHP, ColdFusion and ASP.NET have something to do with the tendencies of some programmers to produce vulnerable code with them. If you squint, they all have a strong family resemblance to each other: you mix language-specific procedural markup with HTML, which is processed on a server and returned as plain HTML to the browser.

Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things so they show students the simplest way of producing a particular result -- not the way that a proficient programmer should produce that result. The message is "look at how easy it is to make a dynamic website with X!" The details of what you need to do to do things like sanitizing input really clutter that message up; especially in the case of these template-y languages where one of the chief selling points is that they're incremental on top of the HTML you need to know anyway.

It's interesting to contrast something like these systems to JSP, which can be used in exactly the same way except that programmers are taught early on that this "model 1" approach is for wimps who can't handle MVC. Java web apps tend to be grossly over-architected; PHP web apps -- at least the ones I've looked at -- tend to be under-architected, with lots of code replicated across many files which should be centralized in some kind of library. That's the second reason I can think why PHP apps might tend to be insecure: under-designed systems mean you have more places where you have to implement some design policy, or where a "temporary" bit of code that does something like build a SQL query from unchecked user input might slip through into production code. It's not the fault of the language per se; it's programmers reproducing the simplest way they were taught to do something over and over again rather than taking the time to refactor their work so that maintaining and securing it is a manageable task.

The third reason I can think of is that these kinds of systems are so easy for someone who doesn't know what he's doing to tweak in the field. I've done it myself; if you have a basic knowledge of HTML, have ever used a programming language, and know how to use "grep" you can find the bit of PHP that produces a particular output and tweak it to your liking without being a PHP programmer. That means that code that ships secure might not remain so in the field.

Anyhow, I don't know enough about PHP per se to say whether it is inherently insecure in some way, but what I've seen leads me to think that some of the problems at least may be an unwanted side effect of ease of use and learning. There's a world of difference between a PHP system generated by a skilled and conscientious programmer and someone who knows a little HTML and picks up a little PHP to add to that. Fortunately this kind of hacked-up HTML website is looking increasingly archaic these days; if you look at RESTful PHP code it looks pretty much like RESTful interfaces done in any other scripting language. It doesn't have the sprawl I tend to associate with PHP web apps.

Re:Self-fulfilling prophecy?

[Troy Roberts]

Well, that would be true, except the bug density was generated from static analysis, not people looking for bugs.

Re: Self-fulfilling prophecy?

[Anonymous Coward]

Which is why you have default settings and a flag to change default behaviour.

Most people use it to output raw text or HTML
What would be insanely easier is making a command that let you specify it directly rather than having 2 commands, and default to raw text if nothing is provided.

PHP is way too sloppy with syntax which has bred a whole generation of awful developers.
To even consider these people developers is an insult.
These people, at the best of times, take some Stackoverflow wanks broken, buggy and wide-open code and paste it straight in to their sites.
PHP is the reason this happens.
There is no other language out there with as horribly broken syntax and security as PHP.
It needs to be fucking fixed already, without backwards compatibility and/or forced (suggested) code translator tool from the actual PHP team to get rid of these problems.

It is worse than ActiveX is now. At least Microsoft had the decency to kill it. (Even though a trivial fix was sandboxing and whitelist, which I had on top of mines at the time.)

Re: Self-fulfilling prophecy?

[tepples]

What would be insanely easier is making a command that let you specify it directly rather than having 2 commands

I wonder how hard that would be to implement in terms of PHP output buffering.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

Shouldn't that be:

Hi <?php echo htmlspecialchars_real($_POST['name']); ?>?

*ducks*

Re:Self-fulfilling prophecy?

[Jamu]

Something like this?

out << "Hi" << HTML::Text{post['name']};

Re:Self-fulfilling prophecy?

[Jamu]

Oops. That's actually C++.

Re:Self-fulfilling prophecy?

[drinkypoo]

Note that I'm not saying PHP is inherently insecure, but I can think of three reasons why this approach might tend to encourage insecure practices. The first is the way programmers, particularly novice programmers, tend to be introduced to such systems. This is a pet peeve of mine; instructors try to sell students on how easy it is to do things

I can't speak for anyone else, but I can say that I got into developing webpages way before I knew anything about "proper" programming practice because it was easy. I was banging out CGI scripts in bourne script before I even knew how to do a good job of it, let alone why you wouldn't want to do it. The server wound up getting exploited through a remote hole in Apache long before any of my scripts could be a problem. Besides, they all ran as a relatively unprivileged user. Now I just use a CMS, and keep up with updates.

Re:Self-fulfilling prophecy?

[Dan East]

There's no actual security issue there. How can one client POST something and the response from that request go to a completely different client? They can't. And if the user's client machine is compromised to inject javascript in a post, well, um, what is the point of sending it to the server to have it send it straight back?

Re:Self-fulfilling prophecy?

[Anonymous Coward]

I disagree "A language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else".

Using pointer can be unsafe as well, but it is very good if you are using it right.
Simple has their own advantage, as it can be tuned for better performance.

Re:Self-fulfilling prophecy?

[hey!]

The server wound up getting exploited through a remote hole in Apache long before any of my scripts could be a problem. Besides, they all ran as a relatively unprivileged user.

Well, in the early days that would likely have been the case; the vulnerabilities in the Apache server would have presented a better-known target than your code, people weren't in the habit of keeping up with security updates, and automated tools for attacking website specific code didn't exist yet. Today if you did that then flaws in your code would be much more likely to be the cause.

I'm sure you know that the fact that your code runs unprivileged doesn't really protect you or your users, especially these days, but it's worth pointing that out to others. Yes, it does remove certain vulnerabilities, but it doesn't stop things like SQL injection or cross-site scripting or request forgery.

Re:Self-fulfilling prophecy?

[zarr]

The same argument goes for static analysers. They are likely to be better, more thorough, for more common languages.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

XSS against a POST form is quite easy to do. So an attacker can still affect the target victim client.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

Well, PHP is a lot more concise than Java, for example, so the number of bugs per MB would be greater. What you need is bugs per class or user function--something like that.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

Who are these programmers that can write an application but don't understand global variables and their potential impact? Attempting to "fix" tools to be less dangerous for morons doesn't actually reduce the risk half as much as it increases moronic use. I mean just look at all the super high quality java code out there with all its type safety, garbage collection, and pedantics.

Leave PHP like it is. Keep register_globals on. Darwinism meet web design.

Re:Self-fulfilling prophecy?

[paulpach]

There's no actual security issue there. How can one client POST something and the response from that request go to a completely different client? They can't. And if the user's client machine is compromised to inject javascript in a post, well, um, what is the point of sending it to the server to have it send it straight back?

You are right, there is no actual security issue in this constrained example because one would not attack himself, it is just a bug that cannot be exploited. But you can easily see where I was going. When you are displaying content entered by a different user (it would not be in the $_POST variable) that is when it would turn into a security issue. This happens very often.

Re:Self-fulfilling prophecy?

[PyramidOfDoom]

While I agree with the kernel of your post - that safe behaviour should be opt-out rather than opt-in - unfortunately I disagree that it's even remotely practical to do this properly in the cesspool of standards and programming languages used in modern web development.

Don't get me wrong; I know frameworks like Ruby on Rails make html escaping opt-out rather than opt-in and this is a good thing. It's just that XSS isn't just about HTML. There's different escaping rules for:

• Contents of a DOM Text Node (< needs to be changed to &lt)
• Contents of a HTML attribute (" needs to be changed to &quot;)
• Contents of a src/href HTML attribute (as above, but also needs URI encoding)
• Contents of a Javascript string (" to \" or ' to \' depending on how the string was opened, plus line breaks need to be stripped and you need to handle the new string template stuff in the newer ECMA standards)
• Contents of a Style tag (one, many or all of the above depending on where in the CSS its going)

(And that's not even starting on things all the inline XML formats you can have in XHTML, SVG and other things I know next to nothing about)

On top of all this, all these contexts can nest within each other, so you need to apply all of the appropriate escaping in the correct order or it doesn't work.

So a call to your particular framework's equivalent of htmlspecialcharacters just doesn't cut it, unfortunately. The only way I can see to handle all this securely and automatically is to actually parse your templates and keep track of each context that is entered/exited and apply appropriate, nested escaping rules. This is awful and slow.

Even if you took a heavy handed approach like above to fixing this, you'd STILL be screwed because web browsers attempt to "fix" broken HTML and CSS. So they can do (and in the case of IE have done) stupid things like turn a backtick (`) or a left single quote (‘) into a normal single quote (').

Re:Self-fulfilling prophecy?

[dgatwood]

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.

That argument doesn't work when the measurement is in bugs per megabyte.

Actually, it does, and the reason is somewhat subtle: There are only so many good programmers out there. As a language becomes more popular, the demand for programmers who know that language increases faster than the supply of good programmers who know that language. The more popular the language, the higher the percentage of programmers writing code in that language who don't know what they are doing.

Re:Self-fulfilling prophecy?

[dgatwood]

A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else. For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value.

Oh, [expletive deleted], no. That ranks right up there with PHP's magic quotes feature, which caused far more security holes than it fixed, because the behavior wasn't under the programmer's direct control, short of disabling it outright. PHP has no way to know whether you are outputting HTML intentionally, so it cannot know whether it should quote it or not. It also cannot determine whether content came from a user, because it could have been stored in a database in the meantime. Thus, any such automated modification of content is likely to break things as often as it fixes them, if not more often.

What PHP should have is tainted content tracking, and a warning or error if you try to emit unsanitized content without either escaping it or flagging it as known-safe, whether that content came from the user or from a database. And the same thing should happen when using variables that came from the user or from disk as part of a SQL query string. And so on.

The advantages to that design are that A. the developer must explicitly decide how to correctly sanitize the content based on context, which means that the developer is forced to learn about the security implications and seriously consider them, B. it works for more than just HTML output, and is potentially extensible to arbitrary output formats through arbitrary protocols, and C. the code either works or it doesn't; there's no opportunity for the code to work for 99 users and fail for the 100th user solely because that user happens to have an ampersand in his or her username or whatever.

Security cannot be automatic. Any attempts to do so invariably fail spectacularly. It must be designed as you're writing code. Things like static analyzers and tainting are good tools for helping you catch potential problems, but cannot reasonably be expected to fix those problems without programmer input on a case-by-case basis.

Re:Self-fulfilling prophecy?

[dgatwood]

Not if you properly check the referrer. But that's another discussion.

This can be an issue with POST requests, but it is far more likely with GET requests, where somebody on a random third-party server can create an ordinary link that then causes things to happen for the user while logged in to your website.

Re:Self-fulfilling prophecy?

[dgatwood]

So a call to your particular framework's equivalent of htmlspecialcharacters just doesn't cut it, unfortunately. The only way I can see to handle all this securely and automatically is to actually parse your templates and keep track of each context that is entered/exited and apply appropriate, nested escaping rules. This is awful and slow.

Still not good enough if you have code that emits HTML using print statements. It would have to parse the output on its way to the browser. That's just another reason why the idea of automatically "fixing" the content borders on insanity. Much better to spew errors if you pass the data to the client without running any of those quoting methods or explicitly mark it as safe in some other way. That way, the programmer is forced to decide how it should be handled on a case-by-case basis, and code that already does the right thing requires minimal changes (calling one function to mark tainted strings as clean in spots where you really do mean to output the content without quoting).

Re:Self-fulfilling prophecy?

[phantomfive]

instructors try to sell students on how easy it is to do things so they show students the simplest way of producing a particular result -- not the way that a proficient programmer should produce that result.

That's kind of true.....it took me a couple years as a programmer to figure out how to write decent C, and several more to figure out how to make things easy to write in C. Sometimes I wish it were easier for people to learn.

Re:Self-fulfilling prophecy?

[dinfinity]

No. That is dreadful code either way.
The right answer for output in any serious application is to use a template engine: https://en.wikipedia.org/wiki/...
The right answer for input is validation of user input ASAP and sanitization on database entry.

A good language should be designed in such a way that the simple way is the safe way, and make you be more explicit if you want something else.

Don't be silly. If you don't know what the fuck you are doing, you shouldn't be programming as you will find a way to fuck up regardless of the language.
echo does exactly what it should do.
Reading a variable from the POST array does exactly what it should do.
Not understanding how HTML works and 'not paying attention' is not an excuse for not properly escaping values.

But please, enlighten everybody what you consider a 'good language' and how it prevents this problem.

Re:Self-fulfilling prophecy?

[Perky_Goth]

There's many bad decisions you can point at in PHP, but something that every first web tutorial for every language (probably) started with isn't one.

Re:Self-fulfilling prophecy?

[hcs_$reboot]

I see where you're going. C would be something like

puts ( sanitize_string ( get_POST ( "name" )));

Since a good langage comes with good libraries.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

A POST request can be triggered by a different site. That different site can be controlled by a different entity. If your name contains code then responding with code to a request may even be a legitimate thing.

Re:Self-fulfilling prophecy?

[spauldo]

I don't program much in C, and felt like doing something different, so I gave it a shot. Here's some quick code.

Constructive comments will be considered. Otherwise, include your own version or I'll just view you as a troll.

#include <stdio.h>
#include <stdlib.h>
#include <err.h>
#include <unistd.h>
#include <string.h>

struct NV_List {
char *name;
char *value;
struct NV_List *next;
};

char *get_value(char *name, struct NV_List *pairs);

void free_NV_List(struct NV_List *list);

int
main(int argv, char *argc[])
{
static char *buf = NULL;
char *postdata;
char *name = NULL;
char *value = NULL;
int nr;
size_t offset = sizeof(char);
size_t bufsize = 128 * sizeof(char);
struct NV_List *postvars = NULL;
struct NV_List **nextpair;

postdata = strdup("");

if ((buf = malloc(bufsize)) == NULL) {
err(-1, "malloc");
}

while ((nr = read(STDIN_FILENO, buf, bufsize)) != -1 && nr != 0) {
offset += nr * sizeof(char);
if ((postdata = realloc(postdata, offset)) == NULL) {
err(-1, "realloc");
}

strncat(postdata, buf, nr);
}

free(buf);

nextpair = &postvars;
name = strtok(postdata, "=");

while (name != NULL) {
*nextpair = malloc(sizeof(struct NV_List));
(*nextpair)->name = strdup(name);
(*nextpair)->value = strdup(strtok(NULL, "&"));
nextpair = &((*nextpair)->next);

name = strtok(NULL, "=");
}

nextpair = NULL;

printf("Content-type: text/plain\r\n\r\n");
printf("Hi ");

if ((value = get_value("name", postvars))!= NULL) {
printf("%s", value);
}

printf(".");

free(postdata);
free_NV_List(postvars);
}

char *
get_value(char *name, struct NV_List *pairs)
{
while(pairs != NULL) {
if (! strcmp(pairs->name, name)) {
return pairs->value;
}

pairs = pairs->next;
}

Re:Self-fulfilling prophecy?

[spauldo]

Oh, I forgot to mention that's the "unsafe" version without htmlspecialchars().

If you want that as well, you'd have to filter the string. Exercise for the reader?

Re:Self-fulfilling prophecy?

[PyramidOfDoom]

Still not good enough if you have code that emits HTML using print statements. It would have to parse the output on its way to the browser. That's just another reason why the idea of automatically "fixing" the content borders on insanity.

The only way I can see to handle all this securely and automatically is to actually parse your templates and keep track of each context...

There is a reason I specified templates there. Templates act as a way to separate your output into stuff that is safe (stuff you wrote) which doesn't need escaping, and stuff that's come from somewhere else that does need escaping. The templates are effectively doing the same job as binding values in an SQL query; separating the stream into things that should be escaped and things that should not be escaped.

No amount of escaping, automated or otherwise, is going to be able to save you in the situation you proposed, because you have definitely safe content mixed in with potentially unsafe content. Deciding what parts of the stream should/should not be escaped is effectively a halting problem. However, if what parts need escaping is specified via something like templates (where it's actually harder to do what you're suggesting than use them as intended) then you change the problem into "How should I escape these bits"? The use of templates effectively makes this separation into an opt-out process rather than an opt-in one.

The argument I was trying to make with my straw man example above is that the question of how to actually escape them correctly, in an opt-out kind of way, while possible, is needlessly complicated and cannot be done elegantly or without considerable performance degradation. And this is just a natural result of how we have lots of languages with different escaping rules that can all nest within each other.

Much better to spew errors if you pass the data to the client without running any of those quoting methods or explicitly mark it as safe in some other way. That way, the programmer is forced to decide how it should be handled on a case-by-case basis, and code that already does the right thing requires minimal changes (calling one function to mark tainted strings as clean in spots where you really do mean to output the content without quoting).

I think doing this in your framework is every bit as ugly as the insanity I suggested and actually supports my argument. I can only think of two ways to do this in popular server-side languages:

• A lot of very ugly and slow reflection (and TBH, I'm not entirely sure about this one)
• Implementing your own types and forbidding use of your language's standard library and built in types (how would your framework copy information regarding tainted-ness of a value from one to another if you created it using a standard library substring function that only understand the standard string objects/scalars?).

It could be done pretty cleanly as a static analysis tool. It's just that if it was a static analysis tool it wouldn't actually fix the problem as it wouldn't be able to catch all cases (because halting problem). It would certainly be a very useful heuristic and lower the overall number of XSS vulnerabilities in peoples applications, but it wouldn't actually make them impossible in the same way as binding values to a query makes SQL Injection impossible.

TLDR: We are doomed to have to be eternally vigilant about XSS. Frameworks that have opt-out XSS protection only handle the common case which means we still have to worry about the uncommon cases because correctly handling those is too painful.

Re:Self-fulfilling prophecy?

[PyramidOfDoom]

Dammit, forgot to mention a point.

I was going to also say that your approach also doesn't really fix "how do I escape this?" and just foists the responsibility on the developer. Sooner or later every developer is going to have a bad day and get it wrong. The developer might fix the HTML Injection, but didn't realise the value is passed to an attribute like onclick and needs to be escaped for Javascript as well.

Re:Self-fulfilling prophecy?

[BasilBrush]

Meaningless statistics. The "security bugs" are tests for specific coding constructs - lint like tests - which vary per language. The figures don't even have the same headers per language. A higher number of "security bugs" in a language may mean they simply test for more, or the language allows testing for more.

The whole thing is a slashvertisement for the tool. The "report" mentioned is only available by giving the company personal details.

Marketing, not news or analysis.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

"A good language should be designed in such a way that the simple way is the safe way"

So you designed a solution that is neither simple nor safe? Did you not see the point of the exercise?

A simple, safe solution would be to output to an "HTML object" that automatically skips or translates unsafe characters.

Re:Self-fulfilling prophecy?

[spauldo]

Did you not see the point of the exercise?

I wasn't doing your exercise, I was just doing an implementation of the PHP code (the earlier one without the htmlspecialchars() call) for shits and giggles.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

But PHP hate! Must hate hate hate! How can we effectively hate if we can't come up with arbitrary and bad examples of stuff that was never a security issue in the first place?!

Re:Self-fulfilling prophecy?

[budgenator]

That was the point of my snarky reply, he was saying php is an poor language because it's echo function can spit out character strings that can be executed as code by a web browser. So I requested a code example in C, a language generally considered Good, knowing that the task would be exceedingly difficult. I've written a rather complex application in PHP that I use for work, but there is no way I would ever place it on an internet facing computer because I know I don't have the skills to secure it in that environment. If PHP was changed so echo and print required a special flag to allow the output htmlspecialchars() it would break everything, imagine trying to tell Zuckerburg he's going to have to rewrite Facebook!

Re:Self-fulfilling prophecy?

[Anonymous Coward]

If PHP was changed so echo and print required a special flag to allow the output htmlspecialchars() it would break everything

Just call it 'real_htmlspecialchars()'

Re:Self-fulfilling prophecy?

[Anonymous Coward]

> the values posted may contain javascript, and the browser would execute it happily.

You can already add arbitrary JavaScript to a page and your browser will execute it happily.

Re:Self-fulfilling prophecy?

[Anonymous Coward]

A bigger issue in that comic is why the end user application is connecting to the database with an account that has enough rights to drop tables.

Re: Self-fulfilling prophecy?

[MemeRot]

Asp.net mvc html encodes by default and you have to specify if you don't want that. But this is a web development framework, not a language. Similarly there are web frameworks in java you can use that will give you different security than raw java

Re:Self-fulfilling prophecy?

[Anonymous Coward]

Sorry, no, it has everything to do with PHP. You're speaking like someone without the slightest clue about developing secure web applications.

The problem is that much of PHP's framework and language design (and tutorials) is vulnerable by default, and you have to go out of your way to fix that.

Other languages like Java and C# put an emphasis on being secure by default, and you have to therefore go out your way to be vulnerable more often.

That simple fact is a key reason why PHP is, and will be the most vulnerable. Furthermore, you state that PHP is the most common language, amongst whom exactly? Amongst most simple blogs and personal websites sure, but anything requiring actual security like big eCommerce sites, basically anything financial, or high profile targets like Amazon, Microsoft, Google et. al most certainly don't use PHP. This is in large part for the reasons stated above - when you want security you don't pick a language that both is, and encourages insecure by default, yet that's exactly what PHP is.

If you don't understand this, then it merely highlights yourself as the sort of person that writes vulnerable PHP software. Some of us however have to have our code undergo security audits, we have to undergo static analysis as part of our development lifecycle, with dynamic testing picked up in the audits. Some of us know how to write secure software because we have to, and we don't ever do so by choosing PHP, because we're professionals, not amateurs spouting drivel declaring it's not PHP's fault on Slashdot even when it clearly is.

Apps, it had to be apps

[Anonymous Coward]

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.

Re:Apps, it had to be apps

[gweihir]

If fully agree. The problem is incompetent and semi-competent people "quickly kludging new functionality into fairly simple web pages".

Re:Apps, it had to be apps

[Archangel Michael]

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.

Don't blame the result on the language, unless the language itself is the problem. SQL injections are not a programming language issue. It is a problem with the coders.

Re:Apps, it had to be apps

[bigman2003]

Dammit...I've been defending ColdFusion on Slashdot for about 12 years (see username). The last 5 years or so have been very quiet as people just assumed CF was gone. Or more to the point, the 'my language is better than your language' people had moved on.

I've been writing in CF for about 17 years. Yes, even today I use it...and I use it all day long. This is not just "quickly kludging new functionality into fairly simple web pages", it's a matter of creating entire line of business apps.

Guess what? People love the apps. They also love the fact that I can create them so quickly. And they love the fact that whenever they ask for something new I say, "Sure, I can do whatever you need." That's what 17 years of experience gives you- I can churn out high quality code very quickly. I still need to defend CF every time I say, "I'm a programmer" because they always want to know what language I use. Because their nephew is learning Swift and that's cool...etc. etc.

What's my point? I think that too many people in tech are enamored with the new/shiny and jump from technology to technology without spending enough time on the QUALITY of what they are creating. I have CF code that I wrote 16 years ago that is still running, and still serving up millions of pages per month. My new code is pretty damn rock-solid, and I know how to write things in a way that is very easily maintained and updated. Because I've been doing it for a long time...

PHP is now in the same spot as ColdFusion, in the sense that it's no longer the cool thing to do, but there is a crapload of experience out there. In my opinion a good experienced programmer is worth 8 'language of the day' programmers no matter what language they are using.

I've been on my latest project for about 18 months. It will take another 6 months before I'm 'done' to the point where I've completed all of the initial goals - this was the assumed timeline at the beginning...again, I've done this for a while, I can estimate a timeline pretty well. The project is being used every day and has already replaced the older system but there are few more milestones to hit.

But the most important part of the project is that everything is clean. The database has been re-worked extensively as I've had more and more experience with how the data is used. When this project is re-written in the future, it will be much easier because the data will make sense. The last programmers just threw more technologies at the project to solve problems, rather than fixing what was broken. (A nice Javascript data interface can't really replace clean data...no matter how much pagination and filtering your fancy table has) I see that a lot with younger programmers. By far this is the most important part of the project and is not language specific. "Does this entire thing make sense? Have you done the tough work instead of a million work arounds?" That to me is far more important than working on a language that has yet to see version 3. (No magic to version 3, just looking at the maturity of the language)

I wish more people in the industry were concerned about quality, rather than the new and shiny. Not a single user has said, "Oh this sucks because it is written in ColdFusion". Instead they say, "Oh my god, this is exactly what we wanted...and you are so fast!"

I am so tired of people doing one or two projects in a language, then moving on to the next new and shiny- while bashing on CF because it's old. Goddamit, I'll be cleaning your messes up in the future and there is a good chance the pages will have a .cfm extension even if it's not cool.

It's like thinking you are a good photographer because you've got the latest camera. Superficially it's nice, but you still have no idea what you're doing.

Re:Apps, it had to be apps

[Anonymous Coward]

If you want to use a camera/photographer metaphor; using cold fusion is like using a camera where you have to guess whether or not it's focused. Sure you can make it work, and even make it work quickly with enough experience. But why not get a camera that just works and tells you whether or not it's focused, which is what 99% of the photographers out there use. Sure there are times when you want a soft focus, and some photographers even prefer it, but that's the exception more than the rule.

Re:Apps, it had to be apps

[mikael]

"What's my point? I think that too many people in tech are enamored with the new/shiny and jump from technology to technology without spending enough time on the QUALITY of what they are creating"

There are those people who just like to work on blue-sky projects where everything is new and there is no "legacy code". So they are the first to learn the latest skills, design basic systems, then move onto the next project. Everyone else has to clean up after them.

Re:Apps, it had to be apps

[dgatwood]

SQL injections are not a programming language issue. It is a problem with the coders.

That would be true if they had designed the API perfectly security-wise from day one. The reality, however, is that the initial MySQL APIs were pretty bad. In addition to the mysql_escape_string problem (fundamentally broken for some multibyte character encodings), PHP didn't support parameterized queries (as far as I know) until PDO and MySQLi were added in PHP 5 (2004). So basically, for any code written before 2004, SQL injections are, in fact, a programming language issue.

Unfortunately, most code doesn't get rewritten unless it is known to be broken, which means there's an awful lot of code out there that predates PHP 5 that is still in active use, security holes and all. So SQL injections, on the whole, are a combination of a programming language issue and a maintenance issue. PHP 7 is finally forcing people to clean up that crap by dropping the old API. However, it should have been deprecated in 2004, and it should have required someone to modify php.ini if they wanted to keep using that old API after about 2005 or 2006, to force people to update their code.

Re:Apps, it had to be apps

[Anonymous Coward]

You forgot "get off my lawn!"

Re: Apps, it had to be apps

[MemeRot]

My issues with this article:
*ASP is called dead, but the inputs for the article are all from 2013-now
*MB isn't clarified. From the numbers I think they're comparing compiled apps MB against scripting apps MB, where one is either native code or intermediate, and the other is plain text files. They briefly mention there are problems with "problems power KLOC", but they don't mention what those problems are.
* JavaScript apps have almost no security flaws, but .net, php, etc have XSS vulnerabilities - no they don't, only JavaScript is XSS. Counting the flaws in emitted js code as php or asp is weird

Re:Apps, it had to be apps

[Xest]

The article talks about Classic ASP, which shouldn't be conflated with ASP.NET. ASP most definitely is basically extinct, no one is using it for new projects and it's barely even being used for legacy stuff. The fact they even found anything worth testing is a miracle in itself and it's not surprising it's vulnerable as any code base using it likely pre-dates many now commonly known security vulnerabilities. The same is true of Coldfusion, the same is however not true of PHP which is still being used to actively develop new projects and maintain existing ones on a widespread basis.

Neither Coldfusion nor Classic ASP are in the top 3 languages for kludging together new functionality - languages like Ruby, Python, C#, Java, and probably even Perl undoubtedly have far larger userbases nowadays. This is why the summary used the language it did - maybe extinct is technically wrong if code still exists for it, but "almost extinct" would be perfectly adequate.

Whew!

[scunc]

Good thing I'm still using Perl!

Re:Whew!

[Anonymous Coward]

sed/awk FTW!

And that's surprising ... how?

[Opportunist]

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.

Re:And that's surprising ... how?

[Anonymous Coward]

Well, actually - if security doesn't enter the picture, there are no security bugs.
It works as designed.

Re:And that's surprising ... how?

[Anonymous Coward]

No it's not surprising.

It is however something you can point to when your company is using PHP (and cargo cult programmers). "Hey look!, that thing I've been saying for years that we need to switch from PHP is true! It's not just my opinion.". It might be a way for a company to save face and justify switching to a better language, and generally a more skilled set of developers.

Re:And that's surprising ... how?

[xxxJonBoyxxx]

>> ColdFusion always smelled

Let me stop you right there. No, seriously, that pretty much sums it up.

Re:And that's surprising ... how?

[Anonymous Coward]

ASP is not a language, it's a framework.

The more you know

Re:And that's surprising ... how?

[PPH]

And iOS and Android are platforms, not languages.

Flawed study is flawed.

Re:And that's surprising ... how?

[drinkypoo]

I don't know of anyone who seriously learned programming and didn't give ASP a wide berth.

It's worth noting that ASP isn't even a programming language. It's not a language at all; it's a set of conventions for integrating arbitrary scripting languages into your webserver. Out of the box you can use either vbscript or jscript, and you can also add other languages like perl. And then you can mix them all in a single document. The holes "caused by ASP" were just holes in IIS or in one of the script engines.

I once worked for a company which did websites for bands, and one of the big projects was a music-selling website for Creative called MuVo and powered by AMG. Ultimately they scrapped it, and used nothing but the name (which they applied first to a crappy mp3 player, then to some speakers and whatnot... and then terminated.) The site was implemented on windows, using IIS and ASP, but entirely in jscript so as to avoid the frequent holes in the vbscript engine. Its performance was quite competitive, too. The whole mess ran on just about ten thousand dollars' worth of hardware... probably more with the PIX licenses.

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

ColdFusion was early. When it was invented, the competition was mostly shell and perl scripts. PHP was invented at the same time, but it took a little while to be taken seriously, for good or ill. ColdFusion had marketing behind it, so it was taken seriously right away... unfortunately.

Obviously the other competition was Netscape's webserver, which was also a server-side javascript implementation. Sadly, that's the only one of these things I have absolutely no experience with. I say sadly, because I think it's probably the most interesting of all of these products. If it had been open sourced early on, the web would probably be powered by a lot more javascript today.

What's a "programming language"?

[david.emery]

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?

Re:What's a "programming language"?

[Anonymous Coward]

really?

Re:What's a "programming language"?

[Tx]

I was about to post exactly this; since when are Android, iOS or .net programming languages? And yeah, measuring flaws per MB of source code - surely there are pretty large differences in source code "density" (i.e. how many characters of source code it takes to get a job done) between the things which actually are programming languages, so that's not really a valid measurement IMO.

Re:What's a "programming language"?

[tjarrett]

I'm an author of this report, so thought I'd offer some feedback.

First, the iOS applications that Veracode scans are written in Objective C (and probably some C or C++). And the Android apps are written in Java. (Yes, you can write iOS and Android apps using portability frameworks like PhoneGap; we separate those findings out into a separate category.) We used iOS and Android as shorthand so that (a) readers would more readily make the connection with what ObjectiveC meant, and (b) we could separate Java used in Android, which has a distinctive risk landscape, from Java used in other applications.

Second, we choose to report on application prevalence, or the number of applications showing at least one of the vulnerability, rather than number of vulnerability occurrences. The application prevalence metric is more meaningful when talking about the overall risk of a large number of applications. There is value in the vulnerability prevalence metric, when it comes to planning remediation effort, but for this study we focused on the former.

Third, we do report average flaw density metrics in the appendix of the study, along with a discussion of some of the limitations of this metric. I suggest reviewing the actual study (it's only about 20 pages) and then posting any additional questions.

Thanks for the questions and keep them coming.

Re:What's a "programming language"?

[Rei]

They use labels like "Objective C (iOS)", which the article is just shortening to "iOS". Also they report errors as "number of errors per megabyte of source code".

Wish they'd broken down C and C++, they're very different languages in terms of how people typically develop them (non-automated vs. automated memory management). Instead they grouped them together and called them just "C++".

Sad that injection bugs are still so prevalent. 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. Maybe something like that would finally get people to start using proper parameter substitution...

Re:What's a "programming language"?

[aaaaaaargh!]

It must be great for Ada, though, because it so incredibly verbose.

Also, just changing your C programs from K&R to GNU indentation style will make them more secure!

Re:What's a "programming language"?

[Anonymous Coward]

iOS is presumably objective C or swift. They have a few bugs less than C++, but the difference is so minor that I would say they could be identical when you take statistical inaccuracy into account. That alone makes me think of objective C.

And wouldn't it be even more useful to know which languages generate the least number of bugs, per line of code?

Some languages can write the same thing in way less lines than others, making it a poor comparison. Measuring the filesize of the source code has the same problem, perhaps even worse. Looking at compiled filesize could be a better option, but java and scripts breaks that comparison.

It's actually pretty hard to figure out how to make a valid comparison, which answers the question "which language should I choose to make the least number of bugs while coding this specific feature?". Oh and yeah, knowing the languages with the least number of bugs would be quite useful too.

Re:What's a "programming language"?

[david.emery]

The normal metric for languages like Ada, Pascal and yes C or C++ (those should not be considered the same language!) is "statement" as defined by the grammar, and usually simplified by counting "semicolons". If you figure out how to add preprocessor/header files, you'll probably see that for equivalent applications, the statement count between C and Ada is about the same. That's based on my real-world experience working with both languages over the last 30 years, I have no idea if the parent poster has much real experience in Ada (I kinda doubt it.)

There are some things that are very concise in C or C++. There are also some things that are very concise in Ada (imagine how many hundreds of lines of C and threads packages you need to code to get the equivalent of Ada tasking rendezvous.)

True story: as part of an experiment we implemented part of TCP (in particular, the timeout provisions associated with NAK) in both Ada95 and C. It took me 5 lines of Ada95 (Asynchronous Transfer of Control) to do what the other developer (who had experience coding protocols) did in 300 lines of C. His code had a bug in it, too.

Re:What's a "programming language"?

[Anonymous Coward]

Doesn't Perl's "taint mode" do something like this? Looks like Ruby does it too: https://en.wikipedia.org/wiki/Taint_checking

Re:What's a "programming language"?

[Z00L00K]

Just realize that a null pointer dereference isn't necessarily a security issue, it's a potential security issue and it's a potential stability issue.

If the application just bombs when you encounter it and returns a server error page once in a while then it's not a big deal, but if someone can feed the pointer data through a crafted request it's a different matter.

Just use Valgrind and Splint and you will shoot most of the blatant errors. But there are still the area of not so obvious errors that are harder to catch. A common one is to have a login page that's protected but then it calls on web pages that don't check if you are logged in or not, and if not every page do such a check then you may have a solution where you have a gate into your compound but no (or a very low) fence.

Re:What's a "programming language"?

[Anonymous Coward]

ADA is a very good language for things that have to be right. C is a very good language for things that have to be sort of fast. C++ is a good language for things that don't have to be right, and pick your language for shit that should sort of work some of the time. Fortunately, the compiler developers have already written the assembler for almost everything that has to be very fast.

Re:What's a "programming language"?

[careysub]

Thanks for dropping in with the clarifications!

Re:What's a "programming language"?

[aaaaaaargh!]

I have no idea if the parent poster has much real experience in Ada (I kinda doubt it.)

I have (sort of), because I have chosen Ada a long time ago as my main implementation language for things that need to be fast. But I'm only programming as a hobby and was joking. Anyway, I didn't want to imply that Ada is more verbose than C. They are both insanely verbose.

Re:What's a "programming language"?

[T.E.D.]

Third, we do report average flaw density metrics in the appendix of the study, along with a discussion of some of the limitations of this metric. I suggest reviewing the actual study (it's only about 20 pages) and then posting any additional questions.

I might. Got a link? There's no link to it that I could find either here or in any of the links on this story.

Re:What's a "programming language"?

[david.emery]

APL is probably the least verbose language ever. Not used much, these days: https://en.wikipedia.org/wiki/... In this context, APL would have a lot going for it. However, understandability is probably none of those....

Re:What's a "programming language"?

[phantomfive]

ok, here's a question.......

Since Android is written in Java and C++, why (in your opinion) did Android get such a low bug count compared to Java and C++?

Re:What's a "programming language"?

[Anonymous Coward]

I agree. The primary reason why I chose Ada was not speed but rather that it allows me to quickly figure out what the source code is doing years later. Wouldn't say that about C, though.

Re:What's a "programming language"?

[DahGhostfacedFiddlah]

Sad that injection bugs are still so prevalent

Am I the only one who finds it strange that we still do DB access via SQL? How did it become normal to string together code for one language using another? Imagine every time we had to do math, it was via a weird language whose interface was entirely eval()-type operations.

Re:What's a "programming language"?

[Anonymous Coward]

> Anyway, I didn't want to imply that Ada is more verbose than C. They are both insanely verbose.

If C is verbose, I'd like to know what you think is concise!

Maybe 'verbose' is not the word you really want? I would say C is terse.. Verbosity usually means using more words than you need to express meaning, and C has very few keywords compared to most other languages.

Re:What's a "programming language"?

[Anonymous Coward]

Here's another question:

If you can buy nuts in a bag, how come the volume of the nuts is less than the volume of the bag?

Re:What's a "programming language"?

[lgw]

Doesn't Perl's "taint mode" do something like this? Looks like Ruby does it too: https://en.wikipedia.org/wiki/...

Rei's idea is more clever: tainted should be the default. A special, limited, "clean string" class would be used as the argument to anything that executes a command. I like it.

While we're wishing, I want a language where "const" and "not allowed to be null" were the default, and "mutable" and "nullable" required special syntax.

Re: What's a "programming language"?

[Anonymous Coward]

valgrind will only find heinous security risks if you can feed all possible input classes into you code. fuzzing may be able to do that.

generally speaking, c is evil and so is c style c++.

the phone company created it to make computers hackable. c throws infomatics into the age before fortran.

Re:What's a "programming language"?

[dgatwood]

Perl's taint mode, unfortunately, excludes arguments to "print" when checking for taintedness. That might be good enough for command-line tools, but when you're looking for security bugs in server code, those are precisely the places where you most want to check. And it bafflingly untaints content pulled from a regexp match, which is also very bad, and equally bafflingly, does not do so if your locale is something other than POSIX.

So yes, Perl's taint mode does what is described above. However, preventing you from passing user-generated data as a command-line argument, while useful, is woefully insufficient as a security tool for CGI purposes.

Not sure about Ruby's taint mode.

Re:What's a "programming language"?

[AHuxley]

What happened with Ada after all that defence spending and standardization?
Was it a rush to other languages from the lower levels ie home PC use in the 1980's -early 1990's that pushed other ideas and options up into academia or via games, cpu hardware options, costs? What kept the good ideas found in Ada over the decades from making it to the faster, more memory ready computer over the years? Thanks :)

Re:What's a "programming language"?

[spauldo]

It's been a while since I was in the Air Force, and I was a 3C0X1, not an X2, so I wasn't a programmer myself. That said, I can give a pretty good guess.

The military had a push for "COTS" (commercial, off-the-shelf) systems back in the late '90s. That meant buying software rather than building it yourself. It was a lot cheaper that way. The internet had become a big thing, and desktops were all over the place. Outsourcing and contracting increased dramatically.

Ada doesn't make sense in that environment. Sure, if you're building a closed, mission-critical system where lives hang in the balance, then a language like Ada is probably your best bet. For most tasks, it doesn't.

Besides, Ada never saw much use outside the government. That meant your only source for Ada programmers was ex-government or -military people. With the big push toward outsourcing, I imagine Ada programmers were hard to find. Government contractors would fight the Ada requirement tooth and nail - and many of those have congresscritters in their pockets.

If anyone knows better, let me know. I'm curious too.

Re:What's a "programming language"?

[david.emery]

I think that's a fair summary. The Military got into a huge case of "commercial industry is better" (despite evidence to the contrary for large software intensive systems.) The Ada compiler vendors charged high prices to their captive market, discouraging commercial use with the bar to entry being too high. C, on the other hand, had $99 PC compilers (or cheaper) and it was easier to learn the basics (but it takes at least as much time to become competent in C as in Ada, particularly when you take into account learning all the idioms and conventions on the one hand, and the things to -not do- on the other hand.)

There has been (and still is) pockets of Ada usage in transportation (air traffic control, avionics, train control) where the safety of large software systems is a driving consideration. The primary viable Ada compiler is open source, see http://www.adacore.com/

Availability of Ada programmers is not the issue (although it's often used as an excuse.) My back-of-the-envelope calculation is there are at least 100k people in the US with Ada training. The problem is that most of them are making much more money doing C (in part because Ada provided a good foundation for reasoning about software systems, making them better-than-average C programmers.) Case-in-point: My friend who was making $100+/hr doing C, and never got an offer for more than about $55/hr for Ada. That being said, he often does prototyping in Ada, and then if necessary recodes the application into C or Java.

DoD got in many respects what it wanted, a 'universal language' with low entry cost, lots of cheap programmers, and commercial tools, from C. Unfortunately, they also got the 'throw low cost bodies at it' culture that produces so much crappy software.

Re:What's a "programming language"?

[Rei]

It is a good point. And with any sort of programming language that supports lambda-style functions it's no more difficult to write inline callbacks (for example, as WHERE clauses) that a database library could use when parsing through its database than it is to write an SQL statement. For example in C++ it could be like:

db.select({{"A.foo", "B.bar"}).from("widget1", "A").from("widget2, "B").where([](db::condition& c){ return c["A.baz"] == c["B.baz"]; }).order_by("A.foo");

That would of course let you implement basic queries in a standard SQL style but without any actual execution of strings. But you could extend it to far greater capabilities - for example, selecting direct into STL structures. You could even make the tables themselves look like STL objects:

for (auto& row : db["widget1"])
{
      if (row.baz == 3)
    {
          foobar = row.foo + row.bar;
          db["foobars"].emplace(foobar, row.baz);
    }
}

And so on. I've not spent enough time investigating what options are out there at present for such a database, but I see no obvious impediments to such a system. Heck, it's not even a database so much as an interface - you could wrap such an interface class around any extant SQL database if you wanted.
   

Re:What's a "programming language"?

[spauldo]

Thanks for the insight. I was curious.

I knew a couple X2s when I was in - both promoted to the point where they hadn't done any actual code in years - and they gave me a positive impression of Ada, but I've never used it myself.

Maybe I'll give it a shot one of these days.

Apples and Oranges

[Anonymous Coward]

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.

Reason for this

[xxxJonBoyxxx]

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.

Meaningless conclusion.

[BVis]

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.

Re:Meaningless conclusion.

[phantomfive]

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.

Seriously man? You don't think the researchers thought of that? If you had even clicked on the article, you would know that they did.

In any case, here is the full list:

Classic ASP - with 1,686 flaws/MB (1,112 critical flaws/MB)
ColdFusion - with 262 flaws/MB (227 critical flaws/MB)
PHP - with 184 flaws/MB (47 critical flaws/MB)
Java - with 51 flaws/MB (5.2 critical flaws/MB)
.NET - with 32 flaws/MB (9.7 critical flaws/MB)
C++ - with 26 flaws/MB (8.8 critical flaws/MB)
iOS - with 23 flaws/MB (0.9 critical flaws/MB)
Android - with 11 flaws/MB (0.4 critical flaws/MB)
JavaScript - with 8 flaws/MB (0.09 critical flaws/MB)

Re:Meaningless conclusion.

[Anonymous Coward]

You said:

[...] 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. [...]

From the article:

[...] The report used a unique metric, Flaw Density per MB, meaning the number of security issues discovered in each MB of source code [...]

Conclusion: You're pretty much whats wrong with commenting on the web: (a) you didn't read the first part of the first paragraph of TFA, let alone the rest, and (b) you assumed everyone else - apparently especially people who go the the effort to study stuff - is incredibly stupid, and failed to brainstorm metrics for even five minutes before investing weeks or months in a full study.

Re:Meaningless conclusion.

[jabuzz]

But how many of these critical flaws are SQL injection flaws? As has been observed elsewhere every dam PHP howto seems to be keen on using dynamic SQL queries rather than using stored procedures that more or less kill SQL injection issues stone dead (that is unless you start using dynamic SQL in your stored procedure).

What would be interesting is to see the SQL injection flaws removed from these figures.

Re:Meaningless conclusion.

[Anonymous Coward]

> PHP - with 184 flaws/MB (47 critical flaws/MB)

And that shows why those old white people, that are almost always Republicans, love that PHP garbage and constantly shove it down our throats. Just look at that stupid site where grandparents try to spy on their grandchildren named Facebook. They shove PHP down our throats and require you to use PHP in order to use the site. That is what PHP is all about. It is about old people spying.

Re: Meaningless conclusion.

[Anonymous Coward]

And if it wasn't for the cost of software bugs, we could feed every child in this country. NIST estimated that bugs cost us $59.5 billion last year. That is 0.6% of the GDP! With that amount of money, we could increase WIC by ten fold.

Re:Meaningless conclusion.

[phantomfive]

But how many of these critical flaws are SQL injection flaws?

If only there were an article you could read that had this information. Then you could read it and avoid making ignorant questions.

As the article points out, code injection and XSS faults are much more common in PHP than SQL injection flaws.
Of course, it doesn't mean that PHP is the worst language......for example, it could be that the worst programmers most often use PHP. More research is needed.

Re: Meaningless conclusion.

[Anonymous Coward]

Old programmers love PHP, and they're almost always white and upper middle class so you just know most of them are one of those Republicans.

Re: Meaningless conclusion.

[Anonymous Coward]

And it's the old programmers that don't know how to program. They're too lazy to learn how to do things the right way.

Re: Meaningless conclusion.

[Anonymous Coward]

And the Reoublican-ruled media will never report on that.

Re: Meaningless conclusion.

[Anonymous Coward]

Old people don't even try to write good code. You know how those people are.

Re:Meaningless conclusion.

[BVis]

php isn't garbage, lots of code that's written in php is garbage.

Re:Meaningless conclusion.

[BVis]

Or, I'm sick of people bashing php for things that aren't structural/language issues.

Re:Meaningless conclusion.

[Anonymous Coward]

If you knew anything about PHP, you would know there is no such thing as php. Why lie about it? Trying to distract from the fact that a bunch of old white people have created something that is destroying the Internet? Go away troll. You have ruined the Internet.

Re:Meaningless conclusion.

[serviscope_minor]

Interesting that Java and C++ have more flaws per MB than Android, given android apps are usually written in Java and sometimes with C++ mixed in. This implies more about the average Android coder vs the average Java coder than it does about the languages.

Re:Meaningless conclusion.

[phantomfive]

Yeah, I was wondering about that too. It might have something to do with the automated tests they use?

Re:Meaningless conclusion.

[serviscope_minor]

Dunno.

Possibly in the case of C++, there's much less of the horrendous pre-modern stuff (though the android devs, bless their little hearts, tried to make that the case with C++), simply because people have had access to much more modern versions of the languages and compilers than the "average" java and C++ code out there that's been long lived.

Re:Meaningless conclusion.

[phantomfive]

simply because people have had access to much more modern versions of the languages and compilers than the "average" java and C++ code out there that's been long lived.

Maybe. I expect to see more bugs out of the modern Java stuff, when people have threads and enclosures with mutable variables.

Actually, maybe the reason is because in Android code you don't see many threads (the android app has a 'threading' model by default), whereas in Java server code you tend to see many threads? The article doesn't really clarify.......in both Java and Android the biggest cause of bugs is listed as "Code Quality."

In the C++ world, the #2 cause of bugs is buffer overflows, and yeah, modern C++ should mostly fix that. The #1 cause of bugs in C++ is error handling, which is understandable since every project in C++ has its own method for handling errors.........

Re: Meaningless conclusion.

[Anonymous Coward]

havent had a serious intoxication for a long time, eh ?

get yourself a bottle of schnaps to get rid of the stupid.

nobody forces you to use facebook.

i blast commies and i run my personal rpi server because those cloud services steal intellectual property.

Re:Meaningless conclusion.

[jrumney]

Or the differences in standard libraries, programming tools and complexity of typical applications.

Re:Meaningless conclusion.

[serviscope_minor]

Maybe. I expect to see more bugs out of the modern Java stuff, when people have threads and enclosures with mutable variables.

Weren't threads always there? Anyway, the generics had cut down on a lot of the horrendous casting mush that used to go on to just use a container. I think that will have cut down a lot. They've also been slowly replacing badly designed libraries with ones that are safer and easier to use (not perfect of course---and the old standard libraries still remain).

The article doesn't really clarify.......in both Java and Android the biggest cause of bugs is listed as "Code Quality."

I don't have the faintest idea how to interpret that!

Re:Meaningless conclusion.

[phantomfive]

Weren't threads always there?

Yes, and always causing bugs. "If you add a thread, you add a bug."

Anyway, the generics had cut down on a lot of the horrendous casting mush that used to go on to just use a container. I think that will have cut down a lot.

Here's an interesting one to me.......logically, what you say makes sense, that casting is a potential source of bugs. In practice, I've never accidentally cast something to the wrong thing (and had it go to production). Is that a type of bug you've seen from time to time? I'm genuinely curious.

PHP is Fine

[Anonymous Coward]

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.

Re:PHP is Fine

[TWX]

The problem is the users, PHP is so ridiculously easy to write it leads to people making horrible insecure "awesome" webpages.

I'll let you in on a little secret, the problem is always the users, regardless of technology. That's why some disciplines have separate security tracks from their development or administration tracks, because the concepts run completely contrary to each other. Development is there to provide access. Security is there to prevent access. At some point the two need to come to a compromise, but trying to get developers to do security is about as useful as trying to get security professionals to do development.

Re:PHP is Fine

[gweihir]

Indeed. PHP coders suck (on average).

However, a language that makes it too easy to write code will always have this problem. I tend to not blame the language for that, but the causality is there.

Re:PHP is Fine

[Anonymous Coward]

Languages don't make bugs. Programmers make bugs.

Re:This is why you should use APPS!

[Anonymous Coward]

Apps are for cows, you insensitive clod, are you a cow? I for one welcome our Natalie Portman nude overlords. More at 11.

Wondering how they measure this

[subanark]

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.

Re:Wondering how they measure this

[tjarrett]

Good questions, and I suggest downloading the report to confirm your answers. We won't bite.

We report data in this study largely obtained from binary static analysis, run in Veracode's centralized environment where we can tune our engines for low false positive rates.

JavaScript is at the bottom probably because at the time the data was pulled for this study (six quarters from Q4 2013 to Q1 2015), we only supported JavaScript in mobile application use. We have since added support for JavaScript in the web context, specifically with support for JQuery and Node.js, and expect the picture for JavaScript vulnerabilities to change when we do the next report. That's one reason we didn't include JavaScript in our high level conclusions for the report..

Why ignore the ones that had more than 80% of bugs

[tompaulco]

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.

In other news...

[Anonymous Coward]

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.

The problem is not the language, it is the coders

[gweihir]

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.

Re:Are all ten of them Java?

[tompaulco]

Just wondering.

Java is the 4th highest, with about 2% of the flaws found being Java. I'm really shocked that Java shows up higher on the list than Javascript. If ever there was a language where people copy and paste somebodiy's working code and try to mangle it to work for their own purposes with no understanding of the actual language or security thereof, it is Javascript.

Web APPS in what language?

[tepples]

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?

Re: Web APPS in what language?

[Anonymous Coward]

I don't see how Taylor Swift can solve this problem

Re: Web APPS in what language?

[tepples]

I don't see how Taylor Swift can solve this problem

Ask the headline writer for El Reg.

Managed languages

[johannesg]

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.

Re:Managed languages

[Anonymous Coward]

I think you can write stuff vulnerable to SQL injection in all these languages. Its not the languages that are what is at issue here.

Its the people writing in those languages. When 25% of web developers are using PHP and creating so many security issues, its the PHP programmers that are the issue. PHP might be able to be changed to reduce the amount (like .NET as you claim does) and it might have some effect (again as .NET does). So are .NET programmers better or does .NET do a better job of letting someone write secure code? This survey doesn't answer it, but it does allow the question to be asked where it wouldn't have been asked before.

Re:Managed languages

[Anonymous Coward]

Someone should create a language called "C/C++" to turn everyone who put that on their resume into liars.

Re:Managed languages

[medv4380]

If you think the report has such bad things to day about Managed Languages it really depends on how you read it. Java ends up looking like it's just under PHP, but if you look at the Critical Flaws portion it's actually much better than C++. Heck, Javascript is the best overall, but it's easy to see why Javascript is so pervasive that it needs a fairly solid sandbox, or everyone's hit with the exploit. Which is why Java exploits are so bad it doesn't matter that Java has fewer critical exploits when the Java plugin ends up with the exploit everyone with it installed gets hit.

Re:Managed languages

[jrumney]

I really don't think it would make a difference to split them out. As someone else pointed out above, it is not the languages, it is the developers they attract. Classic ASP/Cold fusion - think people who jumped on the Web 1.0 bandwagon pre 2000, and have never updated their skills. PHP - again, it is an easy language to pick up and write dynamic web pages, so a lot of beginners. C and C++ are really only accessible to skilled coders, and their well known potential for major screwups that aren't even possible in higher level languages means that C and C++ developers are very conscious of security issues.

Re:Managed languages

[Anonymous Coward]

Very secure code can be written in C.

You just need to take the time to learn all the exploits and avoid them.

Writing a masterpiece is not going to be easy but it sure as shit can be done.

Re:Managed languages

[Headrick]

It's (mostly) not about managed pointers and garbage collection. Most attack vectors arise from mishandling/mistrusting external inputs.

javax.servlet != android

[tepples]

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.

Re:Why ignore the ones that had more than 80% of b

[Jason Levine]

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.)

But of course: "WebDummy" tools lead the pack

[Anonymous Coward]

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

Re:The problem is not the language, it is the code

[Jason Levine]

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.

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?"

Re:Are all ten of them Java?

[Anonymous Coward]

The days of copying and pasting JavaScript and hoping that it works are long gone (perhaps 10 years).

Wait a minute.

[Sevalecan]

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!

Let the hate flow through you

[Anonymous Coward]

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.......

Re:Let the hate flow through you

[Anonymous Coward]

...turned Tom Cruise gay!!...

...turned...

I've got some bad news for you anon

Re:Are all ten of them Java?

[Z00L00K]

None of them are Java.

What everyone must be aware of is that the security issues that exists with Java have primarily been related to the plugin in web browsers, where attackers could gain access to the client machines through specially written applets. Server side Java has rarely been the problem, and most of the server side Java problems have been due to badly written applications not the language itself.

My personal experience is that using a language that requires compiling vastly decreases the amount of possible bugs if all errors and warnings are resolved. But when you take a language like PHP then you have two inherent faults, the first is that it's not a compiling language so you will get the errors at runtime, the second is that you get a mixed code where you get a mix of HTML and PHP. The second problem is also present in ASP, ColdFusion and JSP (Java Server Pages), which accounts for the top 4 on the Softpedia list.

However anyone coding Java and not turning on a majority of warning options in tools like Eclipse, using tools like FindBugs and using Generics is risking to produce code with unnecessary bugs and memory leaks. Use all the resources that are available to you to catch problems early, that will save you headache in the future. Same goes for other programming languages as well, like C and Splint. There are also Lint of C++, but my experience so far is that there are shortcomings there. C# also have a few tools available to help the programmer find bugs, but my experience is that they aren't as good as FindBugs.

Languages like C and C++ suffers from additional shortcomings inherent by the languages themselves like pointers that can wander outside intended memory areas, and in those cases the tools like Valgrind are great. But C and C++ are also good from the perspective that it's easy to write extremely efficient code. Even though large systems are written in C and C++ it's not something I'd really recommend for anyone starting from scratch these days. Instead use languages that don't have built-in weakness when it comes to pointers and use C or C++ for specialized functionality where it's hard to use C#, Java, Fortran, Cobol, Compiling Basic etc.

And for Python fans: It's as I see it a semi-compiling language, with the advantage that it's easy to write code in it, but with some shortcomings from classic interpreting Basic - it's hard to manage a large system written in that language.

Bug for bug compat w/o conspicuous deprecation

[tepples]

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.

Re:Bug for bug compat w/o conspicuous deprecation

[Anonymous Coward]

The big pink box at the top of the page marking it as deprecated, plus the warnings in the error log when running in dev mode, plus dropping it in php7. I'm not sure what more can be done to discourage using the deprecated code.

Re:Bug for bug compat w/o conspicuous deprecation

[gweihir]

Nothing more can be done. Stupid people will do stupid things, even when warned repeatedly. Excessive warnings may even be counter-productive, because all those Dunning-Kruger sufferers out there will assume that this large and well-visible warning most certainly is a warning only for stupid people and hence cannot apply to _them_.

One compile-time warning (for interpreted languages: a developer flag or the like), one warning in the documentation and that is enough. More warnings will not get more people to understand what is going on.

Re:Bug for bug compat w/o conspicuous deprecation

[tepples]

The big pink box at the top of the page marking it as deprecated

Good point

plus the warnings in the error log when running in dev mode

Can "dev mode" and production mode be used on the same server? And/or can logs from dev mode or production mode be sent to different log files for different shared hosting customers? If not, then it isn't suitable for use with shared hosting. In addition, a lot of developers may not be running exactly the same version of PHP, and a developer may conflate "dev mode" behaviors with differences between the version of PHP for Windows running on his dev box and the version of PHP for Linux running on the production server.

Re:Bug for bug compat w/o conspicuous deprecation

[CrashNBrn]

Of course. You can even have PHP4 and 5 installed and usable. I imagine many will be doing that with PHP7 to begin with.
You also don't need to make "server-wide" enforced settings for PHP. Each server-client can have custom PHP.ini's.

Re:Bug for bug compat w/o conspicuous deprecation

[Anonymous Coward]

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.

Good point. If only they would implement something like:

<?php
error_reporting(E_ALL);
.
.

You could even put that in a config file (say 'config.inc.php') and use require_once('config.inc.php'); as the 2nd line of every program.

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.

Yeah, they could fix that by implementing something like mysqli_real_escape_string($mysqli_link, $value).

/sarcasm

Re:Bug for bug compat w/o conspicuous deprecation

[dgatwood]

I'm not sure what more can be done to discourage using the deprecated code.

Make those warnings become errors in production mode unless you explicitly set a flag to allow dangerous APIs in your php.ini file.

There's substantial relevant work in ISO

[david.emery]

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?)

More complex than the headline.

[Junta]

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.

Re:Are all ten of them Java?

[Z00L00K]

The report only concerns security bugs, not all bugs. Most security issues with JavaScript are likely to have been hammered out now.

But JavaScript do fail from time to time on web pages, especially if there's a web page that do something that was permitted in an earlier version but not permitted any longer due to a security issue with that functionality. Another headache with JavaScript that most programmers today have rectified is browser differences.

Some browsers have taken in functionality from competing browsers to ensure compatibility so some issues with JavaScript have been resolved that way as well.

Java libraries - they are good, but also a curse since you can't ensure that you get everything right with the library functions in all cases. Experienced programmers may have their own library of JavaScript functions to use when they make their web stuff.

Well duh

[GodelEscherBlecch]

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?

Re:Are all ten of them Java?

[Z00L00K]

A correction, none of the top three are Java.

Our developers make even more

[jfdavis668]

We have more issues with the bugs our developers write than the ones inherited from the programming language.

Re: Are all ten of them Java?

[GodelEscherBlecch]

When you start saying 'java Web plugin' instead of 'java' maybe you will sound less like an ignorant idiot and more like an idiot who just says irrelevant shit everybody already knows.

Query adaptation

[tepples]

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.

Re: Query adaptation

[Anonymous Coward]

you hand a vector of columns from client to server. and the server will check for existence of columns in a whitelist of columns for this particular query.

dynamic query generation canbe done securely and is often required ( e.g. variable list of clauses).

just dont use quick and dirty techniques.

Languages make bugs easier

[tepples]

Languages make it easier or harder for programmers to inadvertently make bugs.

Re:Languages make bugs easier

[gweihir]

These bugs are mostly irrelevant. The ones that matter is where the programmer did not understand the code he/she wrote. And that is a problem before the keyboard.

Re:Languages make bugs easier

[tepples]

These bugs are mostly irrelevant. The ones that matter is where the programmer did not understand the code he/she wrote.

Languages make it easier or harder for a programmer to reason about the behavior of the code he/she wrote.

Re:Languages make bugs easier

[gweihir]

Not really. In the end, you are programming a machine through an interface. If the language makes that significantly harder or easier for you, then maybe you should not be doing this in the first place.

Re:Languages make bugs easier

[tepples]

Interfaces have become too large for a human being to keep in his short-term memory. So if it's acceptable for an interface to make it too easy for a human being to accidentally produce insecure code, then perhaps you're right that human beings in general "should not be doing this in the first place."

Re:Languages make bugs easier

[UnknownSoldier]

Dam straight !

The lack of static typing in Javascript, or PHP are why they are shit languages. It is like people learnt absolutely _nothing_ from all the bad programming habits of BASIC in the 80's. When you need to use hacks like

"use strict";

that is proof the language was designed by someone who didn't have a fucking clue about making the language easier to catch bugs.

Delaying error checking until run-time is stupid. You wan to "fail fast" to catch dumb mistakes as early as possible.

The WebStorm IDE / editor has a good static analysis called "inspection". Having to rely on third party "lint" tools to catch simple variable misspelling is dumb.

Re: Languages make bugs easier

[Anonymous Coward]

what a load of american. c and php are clearly making informatics less secure.

full of shitty features which on average create wholly unecessary security risks. exactly as some powerful people want it to be. see mr camerons utterings.

Re:Are all ten of them Java?

[Anonymous Coward]

You are dreaming. I see copypasta (especially from SO) all the time.

Re:Are all ten of them Java?

[DrXym]

I expect that languages that allow (nay encourage) embedding SQL straight into the web template are the ones most vulnerable to attack.

Java web apps would typically split the presentation, logic and storage from each other and the storage would be via Hibernate / OpenJPA. These impls would tend to be robust and prevent most forms of injection attack.

But are they indexed?

[tepples]

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?

Re:But are they indexed?

[Anonymous Coward]

Seach in a (relational/sql) database used to store data is really not a good idea, 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). In other words, if your application's search functional includes using sql to perform a search, you're doing it wrong (or have a trivial application or search needs).

There are several options to separate search from storage cleanly in java. Hibernate Search, Spring Data, libraries for SOLR, ElasticSearch, etc.

captcha: suitability (hah!)

Re:Are all ten of them Java?

[njnnja]

That brings up a great idea for a new language. It could have the syntax of any language that you want to start with, but the compiler ensures that copied code Just Works(tm). 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.

Veracode Results

[Anonymous Coward]

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.

Full Stack (Overflow) Developers

[tepples]

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".

Re:Full Stack (Overflow) Developers

[njnnja]

Nice link. But how can one deny the beauty of this new language?

Example: Hello world
stack overflow java hello world

Example: Print Fibonacci numbers
python generate fibonacci numbers
python how to print a list

Example: Normalize a vector to length 1
c++ callback function fill array with values
c++ array out of bounds error
c++ how to install boost
c++ smart pointer initialize array with zeros
c++ normalize multidimensional vector
c++ how to install gsl
c++ convert array to gsl vector
c++ how to end function and return value
c++ how to compile to a shared library

Re: Full Stack (Overflow) Developers

[Anonymous Coward]

COBOL?

Re: Full Stack (Overflow) Developers

[WorBlux]

I think the COBOL stuff that is out there is pretty well nailed down, being in maintenance more for 30 years or so will do that. I would also imagine the mainframe archetecture mitigates some of the vulnerabilities. Either that or nobody is masochist enough to profile and categorize COBOL bugs.

Re: Full Stack (Overflow) Developers

[njnnja]

cobol can't find bug
cobol integration cloud services
cobol migration java
cobol migration java -aarp

*ducks*

Re:Why ignore the ones that had more than 80% of b

[xxxJonBoyxxx]

>> 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?

Correlation vs causation

[frnic]

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.

Re:The problem is not the language, it is the code

[xxxJonBoyxxx]

>> 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.

Re:Are all ten of them Java?

[Z00L00K]

I agree, and having SQL inside the source of scripting language also opens a different can of worms - the possibility that an attacker can download the scripts and understand the database model and through that craft targeted attacks.

OK, so what do I do now

[lightperson]

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).

Re:Are all ten of them Java?

[jimbolauski]

1)Exploit google's algorithm to make my functions for print, find, sort,... top on search listings
2)Direct users to my website supported by page view adds
3)Profit

Re:Are all ten of them Java?

[neurojab]

>If ever there was a language where people copy and paste somebodiy's working code and try to mangle it to work for their own purposes with no understanding of the actual language or security thereof, it is Javascript.

In the majority of web applications the client is given limited scope by the server. Clients can't be given full trust because anyone can create their own malicious client. Security bugs are therefore on the server. Today most javascript is still client side. Yes, node.js has been making inroads, but it is far from the most popular server side language. I predict that if node does eclipse java in popularity, it will also beat java in server side security bugs. Perhaps by a wide margin, since I've also seen a lot of client side programmers work on server code in node. If you're used to being on the untrusted side of things and then suddenly have to make secure code, you're bound to make mistakes.

Re:The problem is not the language, it is the code

[Anonymous Coward]

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.

Old Coder

[Anonymous Coward]

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.

Re: Are all ten of them Java?

[Anonymous Coward]

He's too busy writing SQL injection vulnerabilities in php to actually know the difference between Java and "Java Web Plugin".

Obviously PHP

[Anonymous Coward]

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.

Re:The problem is not the language, it is the code

[V for Vendetta]

Why not go one step further, do "the right thing" and use ADO Prepared Statements?

Re:Are all ten of them Java?

[allcoolnameswheretak]

Java actually compares favorably against C# and C++ when you rank it based on the number if critical flaws:

1. Classic ASP - with 1,686 flaws/MB (1,112 critical flaws/MB)
2. ColdFusion - with 262 flaws/MB (227 critical flaws/MB)
3. PHP - with 184 flaws/MB (47 critical flaws/MB)
4. .NET - with 32 flaws/MB (9.7 critical flaws/MB)
5. C++ - with 26 flaws/MB (8.8 critical flaws/MB)
6. Java - with 51 flaws/MB (5.2 critical flaws/MB)
7. iOS - with 23 flaws/MB (0.9 critical flaws/MB)
8. Android - with 11 flaws/MB (0.4 critical flaws/MB)
9. JavaScript - with 8 flaws/MB (0.09 critical flaws/MB)

I think there is something wrong with their test method, skewing the JavaScript results.

PHP is the worst (but not really)

[corychristison]

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.

Re:Are all ten of them Java?

[tjarrett]

An important clarification: as the report states, during the period from which this data was drawn, Veracode only supported analyzing mobile JavaScript applications (mobile applications built using cross-platform JavaScript based frameworks like Titanium and PhoneGap). Since this period we've added support for analyzing both JavaScript in the web client (e.g. JQuery based applications) and on the server (Node.js based applications), so the results should be interestingly different next time around. But this limited JavaScript support is a reason that we didn't seek to draw any broad conclusions based on the language in this study.

Measurement bias

[Anonymous Coward]

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.

Re:The problem is not the language, it is the code

[Jason Levine]

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.

Re:Are all ten of them Java?

[darkain]

I looked at the article and didn't see a definition of "MB" anywhere. Are they talking flaws per megabyte of code? If that's the case, then yeah, PHP and ASP are going to be a fuckton higher than C++/Java, because they don't require all the boilerplate code of classes. Yeah, classes are available, but so is a simple 1-liner "hello world".

However, totally agreed that their testing methods are bullshit in one way or another when it comes to Javascript. 86% of PHP apps have XSS exploits? Wouldn't this be JavaScript at fault on the client side, not PHP on the server side? It looks like they're bundling tons of code under a single "language" based solely upon only the primary language used. Which means the only REAL "JavaScript" test they're running is probably Node.js applications.

Re:Are all ten of them Java?

[Anonymous Coward]

On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

Passages from the Life of a Philosopher (1864), ch. 5 "Difference Engine No. 1"

Incorrect Blame

[Anonymous Coward]

Programming languages do not spawn bugs.

Programmers spawn bugs.

Re:Are all ten of them Java?

[RavenLrD20k]

This is off-topic, but I've the Karma to burn. Every time I see your signature, I cringe from the formula proving the exact opposite of the statement you're trying to make... My OCD just got the better of me today. If the error was deliberate, I congratulate you on a successful troll.

// Declarations
Knowledge = Power AS K = P;
Time = Money AS t = M;
Work AS W

//Solve for M
P=W/t;
K=W/M; //The substitution of K for P and M for t
KW = M;
therefore: Money is equal to Knowledge multiplied by Work.

Re:Are all ten of them Java?

[lgw]

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.

The first joke I saw about this was Stack Sort (take the first SO search result for sorting, apply that to the list, loop down the results until it's sorted). This has of course been implemented.

Since it's been implemented, you could do a meta version - search for "stack sort implementation", and run that code!

PHP and security vulnerabilities

[Anonymous Coward]

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.

Re:Are all ten of them Java?

[Anonymous Coward]

^This^ Javascript is still by and large a client-side scripting "language." In general, it doesn't do much heavy lifting on the server side or interaction with the DB.

Re:Are all ten of them Java?

[edsousa]

Humm, what?

K = W / M Multiplying both sides by M
K M = W M / M

Simplifying
K M = W

Dividing by K
K M / K = W/K

Simplifying
M = W/K

Re:Are all ten of them Java?

[Anonymous Coward]

K=W/M; //The substitution of K for P and M for t
KW = M;

No it isn't. If K = W/M then M = W/K. A division on one side becomes a multiplication on the other.

Re:Are all ten of them Java?

[PitaBred]

Except now node.js exists, and all kinds of people are doing things with it that JavaScript is horribly ill-suited to be doing...

INDEX(somecol), INDEX(othercol)

[tepples]

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.

Re:INDEX(somecol), INDEX(othercol)

[Anonymous Coward]

Column indexes are not meant for application level searching. They are meant to speed up relational operations, such as table joins.

Using indexes for application level searching is at best a use of the functionality that a novice developer (like we have all been) would rely on. But like I said, if your search needs and/or application are simple enough, it can be OK, but also opens up a huge can of worms, such as SQL injection defects. It comes down to using the right tool for the right job.

Re:Are all ten of them Java?

[GodelEscherBlecch]

Let's not forget also that the tooling involved in these surveys is not magic. I have monthly SCA audits and at least 60% of the 'critical' issues it finds are pure nonsense. Things like indirection, polymorphism, chains of data custody, what is/not a public API are not well understood by the scan engine. If I make 10 classes that pass/access a variable, and only the first one has a public API and is ever called by anything other than the one before it, the SCA will tell me that I have 9 classes that are not doing proper null / boundary value / SQL injection / etc. checking.

The time that I have spent fixing actual potential issues found by SCA is dwarfed by the amount of time I have spent learning its heuristics just so that I can write the code in a way that obfuscates the 'issue' so I can skip the argument with our security 'experts'.

Re:Are all ten of them Java?

[PRMan]

There is definitely something wrong if it is saying that buffer-overflow-happy c++ is better for security than other more-modern languages. Almost all the pwn2own stuff is c-based.

Re:Are all ten of them Java?

[Locke2005]

Java is sandboxed, it's not supposed to have any security bugs. Of course, experience shows that's just a marketing lie, but I'd expect languages using a built-in virtual machine instead of compiling to machine code to be somewhat more secure.

Not so fast

[Anonymous Coward]

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...

ColdFusion Might Be Niche

[Anonymous Coward]

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.

Re:Are all ten of them Java?

[GodelEscherBlecch]

I think what it is really saying is that nobody in their right mind makes a web front end, socket handler or other probable attack surface from scratch in C++ unless the application legitimately requires the (ever decreasing) amount of additional performance it confers, and thus it has a smaller showing in this list.

Re:Are all ten of them Java?

[dgatwood]

No, nothing is wrong. On the average, security of code written in a language can be approximated by the formula S = P * L * (100 - D), where P is the quality of the programmers, L is the quality of the language, and D is the percentage of code that works with SQL databases. For example:

• C++ is a potentially problematic language because of C, but most people don't use lots of C string/buffer manipulation, so it isn't affected nearly as much as you might think. And the people who program in C++ tend to be pretty decent programmers. And nobody uses C++ for working with SQL databases, within a small margin of error. So you have a large number times a small number times a large number, hence medium security.
• PHP is a language that isn't too different from C and C++ except that it lacks the pointer bits. This should make it safer. However, PHP was a "popular language" for many years, and during that time, a lot of people who weren't very good programmers wrote a lot of code. So the sheer volume of low-quality programmers made it a bigger security target. And nearly all PHP code interacts with SQL databases, within a small margin of error. So you have a small number times a small number times by a small number, hence low security.

Re:Are all ten of them Java?

[Anonymous Coward]

I expect that languages that allow (nay encourage) embedding SQL straight into the web template are the ones most vulnerable to attack.

If you're talking about PHP, this is not the case and has not been the case for at least ten years.

Re:Are all ten of them Java?

[DrXym]

That would be in the "not the case except in TFA's main conclusions" sense of the word.

Security issue for Internet

[jellomizer]

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
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 .NET - Newer Language for making Web Apps Used widely by a lot of Jr. Programmers of the 2000'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

What's Best Web Platform then?

[Akamaiben]

There are a lot of comments about the problems, but what is the best solution for a web serving platform?

Of course first, its domain specific. So in my example, I started a Classic ASP site in 2000. Converting to .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.

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?

Re:The problem is not the language, it is the code

[Anonymous Coward]

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.

Flaws per MB?

[Tony Isaac]

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."

Re:The problem is not the language, it is the code

[Outtascope]

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.

Intranets (Re:Self-fulfilling prophecy?)

[Tablizer]

I can't help but wonder whether the architectural similarities of typical PHP, ColdFusion and ASP.NET have something to do with the tendencies of some programmers to produce vulnerable code with them

They are, or at least were, often used for intranet projects, where security may be a smaller concern. Intranet habits are perhaps spilling over.

Just bring back...

[Puppet Master]

BASIC! :)

A quarter of what?

[afranke]

which recently announced it runs a quarter of the Internet

Nop. It may run a quarter of the Web, but not of the Internet.

Re:Are all ten of them Java?

[delt0r]

Its about use. The most used tend to have the most problems. But that is probably also a little unfair. Who the hell used applets in the last 10 years? My guess is a lot of those bugs are applet related.

Re:Are all ten of them Java?

[delt0r]

It is fairly easy to prove that a sandbox can't be proven to be secure either. There are lots of ideas and stuff. But unless you can prove bug free, you can't prove secure. And you can't prove bug free.

Re:The problem is not the language, it is the code

[Anonymous Coward]

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

Re:Are all ten of them Java?

[jimbolauski]

You must make a lot of money.

K=W/M You are correct here
K*M=W*M/M multiplied both sides by M
K*M=W simplified M/M
M*K/K=W/K divide both sides by K
M=W/K simplify K/K