The Security of Popular Programming Languages 189
An anonymous reader writes "Deciding which programming language to use is often based on considerations such as what the development team is most familiar with, what will generate code the fastest, or simply what will get the job done. How secure the language might be is simply an afterthought, which is usually too late. A new WhiteHat Security report approaches application security not from the standpoint of what risks exist on sites and applications once they have been pushed into production, but rather by examining how the languages themselves perform in the field. In doing so, we hope to elevate security considerations and deepen those conversations earlier in the decision process, which will ultimately lead to more secure websites and applications."
Wonder how Ada 2012 would fare... (Score:5, Interesting)
I wonder how Ada 2012 would do in this test, although I don't know of any websites that use this language for a backend.
Re: (Score:2)
Re: (Score:2)
bahaha your back end is insufficiently exposed.
Re: (Score:2)
Re: (Score:2)
Why not?
Re: (Score:2)
Well, for one thing, Ada compilers do not run on the same range of platforms C compilers do (I'm sorry to say).
Uh, you are conflating "general purpose" with "platform availability". C runs in far more platforms than, say, Java, but, from professional experience as a C/C++ and Java programmer, I would not call C more of a general purpose language in the same way I would do so with Java.
Re: (Score:2)
Well, for one thing, Ada compilers do not run on the same range of platforms C compilers do (I'm sorry to say).
Uh, you are conflating "general purpose" with "platform availability". C runs in far more platforms than, say, Java, but, from professional experience as a C/C++ and Java programmer, I would not call C more of a general purpose language in the same way I would do so with Java.
Replying to myself since we have no way to edit our previous posts - I would add that languages of the BASIC and XBase families (in particular VB and FoxPro) are/were more general purpose than either C/C++ or Java despite running in more restricted sets of hardware platforms.
Re: (Score:2)
Perhaps you need to define what you mean by "more general purpose". I tend to consider C the most general purpose of languages, because it *isn't* specialized to some task. It's true that , e.g., FoxPro was better at interfacing to the FoxPro database, but that's NOT being general purpose, that's being special purpose.
OTOH (to get back on thread) I don't consider C a very secure language BECAUSE it is lacking in specializations. This means you need to keep creating, e.g., hash tables from scratch, and ev
Re: (Score:2)
http://www.freshports.org/lang... [freshports.org]
And here are the testsuite results: http://www.dragonlace.net/gnat... [dragonlace.net]
The only test it fails are the stack-check tests, and that is because gcc doesn't support it yet (a patch was produced but it's not be accepted ye
Re: (Score:2)
That's right, I need to run my webserver from my microwave.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
To be fair, the context was openssl. Is that going to be realistically run on 8-bit bare metal?
It's generally not too hard get GNAT running on any platform that gcc runs on, but 8-bit would be pretty challenging I think.
Re: (Score:2)
No, but using Ada or another Wirth style language would be a good idea to write some of the critical security libraries in.
Of course, we would have to make sure they are written in such a way to make them callable from C or other languages without too much hassle.
Most modern Wirth-style languages posses syntax-level compiler directives to specify the calling convention. Heck, most modern languages either have such a capability, or an intermediary wrapper or stub generator to do that type of bridging. </itisasolvedproblem>
Re: (Score:3)
It's hardly a solved problem. There are approaches that can be made to work, but that's not the same thing. The current approaches are all clumsy, and often that's a charitable description. It's usually doable. Saying anything beyond that is fulsom praise.
OTOH, because different languages have different basic derived structures, it's often not clear exactly what the best approach would be, even when one is considering things carefully. For one purpose the best I've been able to come up with is marshall
Re: (Score:2)
Have you thought about XML?
(If you're not sure whether I'm joking that makes two of us)
Re: (Score:2)
the best I've been able to come up with is marshalling everything into a byte array, and then separating it back out. Doable, but hardly what I'd call "a solved problem"
COBOL: solving problems since 1959!
Re: (Score:2)
rubbish. I can get it to do merging of sorted payroll data and, erm.. and.. and... yeah ok.
ASP? (Score:5, Insightful)
Do they mean Classic ASP? They list .NET separately so I don't think they mean ASP.NET, but they also don't include ASP in their list of "legacy" languages. I also seriously doubt 16% of companies are still using Classic ASP.
ASP isn't even a language, it's a framework. You can write a Classic ASP app in vbscript or javascript. You can write ASP.NET in any .NET supported language. Then there is ASP.NET MVC.
If they can't get their list of tested "languages" straight, I doubt the rest of the article.
Re: (Score:2)
There are also non-ASP.Net MVC frameworks based on .NET, like NancyFX, so the .NET category seems to very very wide. At a guess I'm going to assume the same for Java, as its really the same situation.
Re: (Score:3)
Don't mistake my comment for blind support for Microsoft. But, when a study fails simply acknowledge this very basic fact about the Microsoft ecosystem, it's numbers really don't mean much.
Re: (Score:2)
Classic ASP doesn't run on .NET, it was pre-.NET.
Re: (Score:2)
They list .NET separately so I don't think they mean ASP.NET, but they also don't include ASP in their list of "legacy" languages.
That's right, according to them ASP and Java are new, and PHP is legacy.
Confusing (Score:4, Insightful)
I'm not even sure what the article meant by ASP vs .NET ? Surely they aren't talking classic ASP? I doubt anybody is 'starting new projects in classic ASP -- so what is ASP? and how is it not .NET ?
The rest of the article doesn't make a lot of sense to me either.
Depends on who uses them (Score:5, Interesting)
Re:Depends on who uses them (Score:5, Funny)
That can't be, My choice language has been told to be the most secure ever.
So
Input $Login
Input $Password
Let $LoginID= SQLQuery("SELECT LoginID from Logins where Login = '" $Login "' and Password = '" $Password "'
I am can rest comfortably knowing that I am perfectly secure.
Re:Depends on who uses them (Score:5, Insightful)
If you read TFA, you will find out quickly that the headline (both from this site and on TFA) is seriously misleading! What TFA is talking about is doing statistic on 30k websites, and determine what language/frame work they used to implement. Then check on each of them for vulnerability attack, such as SQL injection, XSS, etc. So, the language itself has NOTHING to do with the security, but it is the implementation of the site itself! The article itself is not well written either... Too many quotes from many people in copy-and-paste style. Then the author tries to thrown in numbers (i.e. percentage of this and that) to make it look like it is that useful... NOT!
TLDR? Below is what TFA is actually about...
WhiteHat researchers examined the vulnerability assessment results of the more than 30,000 websites to measure how the underlying programming languages and frameworks perform in the field. With that information, the report yields key findings around which languages are most prone to which classes of attack, for how often and how long as well as a determination as to whether or not popular modern languages and frameworks yield similar results in production websites
Re: (Score:2)
What would be really secure would be a language that actively tried to stop you from doing stupid things like requiring that database queries be parameterized. D
Re: (Score:2)
I thought about that a bit. It's easy to remove all but the functions intended to be used parameterized, but that doesn't prevent you from doing something stupid, it just doesn't invite you to be stupid. There is certainly something to be said for that.
The solution for the second part would be a bit heavy weight and never really satisfactory. For example:
"SELECT info from STUFF where id=$uid;"
Pretty much anyone would agree that uid should be parameterized. However, what about:
"SELECT $field from $table
Re: (Score:2)
It may be cliche, but how secure a language is depends on who is using it.
Well, this might be one of those times where "correlation is not causation" is appropriate. What I mean by this is that while the skill of the user certainly matters, so does the quality of the tool. "It's a poor workman who blames his tools" is a warning against poor workmen, not a carte blanche for shitty tools.
So of course, a tool can both help you and hinder you doing what you need to. It's no accident that you see top sportsmen obsessing over their equipment. Or why people don't clamour for manual gear
Re: (Score:2)
Translation: I don't understand dynamic typing, therefore, it's bad and PHP is bad.
(Just a guess, but I'll bet he still thinks Python, Perl, Lisp, etc. are okay. There often isn't much thinking involved when repeating memes and talking points.)
Re: (Score:2)
"Early 2000 called ... yadda yadda ..."
Seriously - you're either a terrible programmer, a troll, or both.
Mean number of vulnerabilities is a good metric? (Score:4, Insightful)
One bug that allows silent remote code execution on the WAN side and another bug that is a privilege escalation possibility on the LAN can not be treated as one bug each, right? This is not limited to just security vulnerabilities alone. Many software company top managers insist on looking at bug counts, sometimes sorted into 5 priority/severity levels or so.
It gets worse in the planning and progress monitoring. They use fancy tools like rallydev.com or something, but they allow each team to define its own story points. The Bangalore team uses 1 story point = 1 engineer week. The Boston team uses 1 story point = 1 engineer day. The Bangkok team uses engineer hour. And the top management gets the report, "This SAGA feature story was estimated to take 3264 story points, and it is 2376 points complete". Complete b.s. that is.
We pay ridiculously high salaries for the top management, and instead of expecting them to put in the time, energy and effort commensurate with that kind of pay, to make valuable judgement, hard decisions, step on people's toes, tell it like it is, and paint an accurate picture of the state of the company, we let them shirk their responsibilities.
The language being the problem? Seriously? (Score:2)
Yes, of course the security of your language (as well as the rest of your environment) matters. But what's way more important is what kind of devs you have. No matter how secure anything is, if the person supposed to use it does not know about its security pitfalls, do you think that's increasing the security?
Security is by definition the minimum of the security your technology offers and the security your personnel offers. The minimum. Not the average. The same applies to OSs, too. You can have the most se
Not a useful paper (Score:5, Insightful)
In the wake of Heartbleed, one might think that this would be talking about array bounds checking or buffer overflow mitigation. No. It is talking about web site frameworks.
examined the vulnerability assessment results of the more than 30,000 websites
First of all: this is not measuring the security of the programming language. This is measuring the security of the OS infrastructure and toolchains. Notice C/C++ is not on the list, since it is hardly ever used for creating web sites.
There was no significant difference between languages in examining the highest averages of vulnerabilities per slot.
What the heck is a slot?
Any summary where Perl scores the best must be deeply questioned. I doubt this is an apples-to-apples comparison. Surely these Perl sites are not doing nearly as much as the sites written in other languages.
Re: (Score:2)
.
Another possibility is in GUI programming there is a such thing as a slot, which is essentially a callback routine associated with an interface control. However applying that definition to an error count metric is troubling since there is no
It's not just the language, but the implementation (Score:4, Insightful)
If the language specification doesn't expressly say what happen when things "outside the design" happen, then different implementations may work differently.
For example:
If the language design spec says
"If an array index is out of bounds, exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program,"
that may seem very specific, but if how to "exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program," isn't specified by someone (usually the operating system), then it may not be specific enough. if different operating systems specify how to do this differently, then expected "under the hood" behavior will not necessarily be consistent across operating systems.
For example, does "exit the program" mean simply returning control to the caller, or does it mean explicitly returning any resources that were previously granted to the program by the operating system first? Or is that optional? If it's optional as far as the operating system is concerned, does the language provide a compile- or run-time switch to force such a cleanup? Does returning memory to the operating system guarantee that the OS will sanitize the memory, and if not, does the language guarantee it? If the language doesn't guarantee it, does the language provide a compile- or runtime switch so the program will sanitize memory prior to returning it to the operating system?
These differences in language implementations and even differences in how operating systems handle the starting and stopping of processes can lead to differences in what the code actually does. Usually these differences are unimportant but sometimes they are very important.
FLAME WAR! (Score:2)
FLAME ON! PURGE THE INFIDELS IN THE HOLY FIRE!
But before we really get into it, this isn't really a measurement of the language somuchas how people use the language. For example: while VB6 was an abomination, VB.NET really isn't all that bad. But since the people who use VB.NET are the amateur noobs who make stupid mistakes. Hey, we all started somewhere. But it means I really wouldn't trust a project that's written in VB.NET for certain tasks.
These are sociological factors. Politics. Culture. And they matt
Re: (Score:2)
The example you give is a decent one, because there's an easy comparison point: C#. VB.net and C#, aside for unsafe block, inline event handlers, XML literals, VB6 compability assemblies and a few other minor things, are exactly the same. They compile to the exact same bytecode, byte for byte, if you write the same thing in both.
Yet VB.net devs are paid less, VB.net code is almost universally worse, VB.net companies are generally garbage, even though the 2 language are almost exactly the same, because of a
Completely missing the point (Score:2)
They shouldn't be looking at the number of bugs in the implementation of the language. They should be looking at the bugginess (or not) of the code written in it. That's the important thing.
Re: (Score:3)
The problem with that is that many programming languages have "features" that programmers misuse resulting in security holes (especially in PHP).
If a language makes it difficult to do things safely, it's reasonable to blame the language.
Re: (Score:2)
Yes... That's my point. This is exactly what they should be testing for - does the language allow you to do dumb things, or does it moan at the first sign of something that could be insecure? This is what they should have tested. Not whether the implementations were any good.
More Important Is Ease of Writing Secure Programs (Score:3)
Ur/Web [impredicative.com] is an interesting language with a type system designed to reject vulnerable web programs as ill-typed. The compiler itself is written in a safe language — Standard ML, and there is a proof of language correctness [impredicative.com] included.
The whole approach is wrong (Score:5, Insightful)
The security level of a piece of code with good security is 95% coder competence and 5% language, i.e. language is irrelevant. One thing though is that language can add to the security problems if it has insecure tun-rime implementation errors.
One reason most security-critical software is written in C is that there, the coder gets full control. A good coder with skills in secure coding will do fine with C. A coder that does not understand software security will to badly in any language, but in C he/she might not even produce anything that works, which will be an advantage. Also in C, it will be far more obvious if somebody is clueless, which makes review easier.
But "language is important for code security" is even more wrong than "language is important for code reliability". Language is important for code performance though, but only in the sense that it can kill it. Good language choice can also make a good coder more productive (a bad coder has negative productivity, so it hardly matters...). This nonsense about the language being capable of fixing problems with the people using is comes from "management" types that are unable to handle people that are individuals. These utterly incompetent "managers" can be found in many large companies and they believe that in IT, individuals do not matter. Typically these "managers" are not engineers and have no clue what a good engineer can do but a bad one cannot. They also believe that engineering productivity can be measured in hours spent or that all coders are equal and just implement specifications, so outsourcing is a good idea.
Re: (Score:2)
I conclude from this and the list of security vulnerabilities in real life that there is no such thing as "a good coder with skills in secure coding."
Or at least no such thing as a project that only employs or accepts contributions from such programmers.
Re: (Score:2)
You could probably find a few drawing decent salaries in less public areas, but certainly it's a skill that the tech world in general has no appreciation for at all. And even though I hate it I can understand why - if you have two companies developing a similar product, one does it quick and cheap, the other takes the time to do it right - the first one will 'own the market' before the second can get th
Re: (Score:3)
Sure, and memory management, and program correctness, and just about any other achievable program property is 95% coder competence and 5% language by this argument. Except the coders that can guarantee 100% that said property is achieved make up 0.001% of the coder population, which means the vast majority of importance falls on the language to prevent memory leaks, out of bounds err
APL (Score:2)
Not a single security exploit reported in over 50 years.
Re: (Score:2)
Re: (Score:2)
Large systems are still being done in APL.
The Swedish medical journal system TakeCare is one example. It handles practically all journals in the greater Stockholm area. It has sure had its slew of security problems, although I don't think that those could be attributed so much to the language as to sloppy sysadmins.
But hey... a few years ago I thought that nobody would use Erlang for anything significant, until it became a popular language for web services.
ISO study on programming language vulnerability (Score:2)
http://www.crosstalkonline.org... [crosstalkonline.org]
And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)
How does a language remediate anything? (Score:2)
I don't understand this:
Perl remediates 85% of all Cross-Site Scripting vulnerabilities, the highest rate among all languages but only 18% of SQL Injection.
There is no Perl language support to remediate cross site scripting. That's all done by the developer and/or framework he's using, so I don't see how it's useful to say that Perl remediates 85% of XSS vulnerabilities when the language itself has no idea what XSS is or how to remediate it.
I'm also having trouble reconciling this statement:
Perl has an observed rate of 67% Cross-Site Scripting vulnerabilities, over 17% more than any other language.
So Perl re mediates 85% of XSS vulnerabilities -- the highest rate of any language, yet it has a 17% higher rate of XSS vulnerabilities?
This study w
Re: (Score:2)
It is actually possible for the language to prevent certain classes of vulnerabilities. See Ur/Web [impredicative.com]. That's not what Perl is doing, but...
For the life of me.... (Score:2)
This is a non-finding.
We've already been through this (Score:2)
A pretty comprehensive study was done that showed regardless of the language selected, the programs written by developers with the most experience in that language were the the ones with the least security bugs, regardless of traits of the language like attack surfaces or complexity.
It's short and sweet. A developer's experience with the specific language or framework an application is written in is a better indicator of application security than the language or framework an application is written in.
SQL and amalgamations (Score:2)
SQL and amalgamations of languages (e.g., JavaScript generated by PHP) not on the list. XSS attacks involve such "mutt" software.
IMHO, the more code the more opportunities to exploit things. Terse languages to the rescue? Write it all in Haskell, Lisp or something. You'll attract talented developers and the attackers will be like... "Oh crap, we have to analyze that???".
No silver bullets of course. Something has to be able to read/write sensitive information at some point. Something has to determine u
The real cause of Heartbleed (Score:2)
Languages and application security? (Score:2)
How about designing a language that can't read/write past a previously allocated buffer in memory.
Just use C or ASM (Score:2)
Fine. Lets see a better language (Score:2)
If you don't like C++ (and who does?) or C, what DO you suggest as a systems programming language?
Rule 1: If it runs under a VM, it's out
Rule 2: If it requires a garbage collector, it's out.
Rule 3: COBOL and FORTRAN are out too.
Re: (Score:2)
I use bash because it's inherently more secure (Score:2)
what bash?
yes sure. just stay away from eval
I'm currently checking if other constructs from bash are prone to execution or information disclosure. Came across 'declare' which may have an issue.
Of course, SQL injections are possible, because SQL is not bash.
More generally... (Score:2)
its pretty much the case that programming languages in which it is harder to make bugs are also harder to make security problems. Because security problems are just a special case of bugs. So all the things we know about writing better languages are important for security. Unfortunately, language technology has always been under-appreciated. People will just use what is popular, which often times is just C or Java and so forth.
Re:python?! (Score:5, Funny)
It's the hip and cool language. If you owned vinyl records and were a vegan, like me, you would know that. But then again, I don't even *OWN* a TV and I was into that band way before they became all commercial. So I can't expect the rest of you to understand.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
what about html? that fad will never die.
Re: (Score:2)
Re:Subtle attack against C/C++ (Score:4, Insightful)
C++ makes a lot of things easier, but under the hood it is still essentially C with an expanded library and fancy pre-processor (I know modern compliers do not actually preprocess C++ into C and then compile), thu all the same problems are still there and mostly are mitigated by using libraries that wrap things up in a safer way.
Re: (Score:3)
At the end of the day, all programming languages are about abstracting things. If you are testing the intrinsic security of a programming language, you are in essence testing how successful the language's built-in data types, built-in functions, APIs, standard libraries, etc. are at mitigating risk factors, which is all about abstraction.
A language's intrinsic security is only as good as its abstractions.
Re: (Score:2)
From the start, the design of C emphasized speed and efficiency over all else. "Trust the programmer" was one of the mottoes. If the programmers are doing something weird, assume they know what they're doing, and maybe print a warning, but allow it. C was, by design, weakly typed, and minimalist, especially when it comes to checking for errors because such checks take time.
Often, we've seen efforts to improve C's safety that were eventually sidelined because they were a performance hit. The iostream l
Re: (Score:2)
I remember a saying when I was learning programming;-
With C it is easy to shoot yourself in the foot, with C++ it is a lot harder, but when you do shoot yourself in the foot you take your entire leg off.
Pity you never bothered to find out who said it or in what context...
Re: (Score:2)
No, C++ is a separate language from C, and far more expressive. It never was a preprocessor for C; Cfront was a genuine compiler that used C as the target machine, and fairly soon became inadequate for compiling C++.
If you think it's basically C with more libraries and a fancy pre-processor, you're using it wrong.
Re: (Score:2)
Sorry pal, Cfront was a preprocessor in the same vein as Oracles PRO*C. If calling it a compiler makes you feel better about using it then all well and good - but it wasn't. A lot of code went straight through it unchanged, it only processed the specifically C++ parts.
Re: (Score:2)
and far more expressive
Such silly nonsense.
Re:Subtle attack against C/C++ (Score:5, Funny)
Hey, some of us find manual memory management sexually fulfilling, you insensitive clod!
Re: (Score:2)
Yes, it is indeed lucky for us that the competent OS developers know their stuff, and they don't listen to people like yourself who have no idea why C is better for the Linux kernel (or any kernel, really). I hate to break it to you, but you aren't smarter than the top Linux developers. You simply aren't. Stop confusing yourself into thinking you know more than they do. It is pathetic to
Re: (Score:2)
FWIW, Linux started way back when C++ was nonstandard (1990?) and didn't have many advantages over C for kernel development. At that time, C was definitely the right choice, and making it a mixture of C and C++ isn't real attractive. Nowadays, I'd recommend C++, as it can do pretty much everything C can and more besides, and standards-conforming compilers can be found everywhere (pity about Visual C++).
Re: (Score:2)
Newsflash - when you're writing a kernel you want to know exactly what is being created during compilation, when memory will be allocated and how is going to be laid out during runtime and when it gets free'd up. ie - it HAS to be explicit otherwise your OS is going to end up in a mess. What you don't want is a load of C++ implicit code and memory allocation happening when you need tight control of both.
Now get back to application programming and leave the OS coding to people who know what they're talking a
Re: (Score:2)
std::containers don't need to store their size as a separate variable
C strings don't either. It's the protocol that said "hey, rather than null terminating strings, let's put a length byte like Turbo Pascal never went out of style!"
The fun thing is that that design decision has lead to an entire CLASS of SSL bugs (in all stacks, not just openSSL) eg invalid certs validating because of a null byte in the Common Name. And heartbleed was just one more in that heap.
Re: (Score:2, Insightful)
C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8. And the absurd part of it is that they could easily do a good job. Utf8 is just a byte array with various routines to interpret the code. Glibc does a reasonable job for a C library...not ideal, but reasonable.
All the array needs is a way to address a chunk by character # rather than by byte #, a way to copy of a character or a slice of chars, and a way to determine the general character classification of any ch
Re: (Score:3)
> C++ (and do a lesser extent C) lose support because of their extremely poor support for utf8.
That's because for most programming, UTF8 is not worthy of support. It's inconsistently used, it arbitrarily increases the of individual. It would be much safer used as only binary strings, not as actual characters which must be parsed and reformatted among different environments. The advent and popularity of UTF8 with its confusing and ill defined management of case and formally POSIX compliant operations such
Re: (Score:2)
If you need to do things like that, then just use UTF-32. Memory is cheap. Scanning a byte array counting characters of arbitrary length is expensive, and there are no cheap shortcuts that don't involve taking as much memory as your UTF-32 representation would have used in the first place, which require far more complicated and prone to error algorithms to handle it all.
Re: (Score:3)
UTF8 is great for storing data in files, but ... working with strings in memory? Insanity will follow.
Re: (Score:2)
Modern C++ is a lot more coherent than you suggest. Its main problem is the initial compatibility with C, and attempting to be compatible with bad decisions made along the way (long has to be 32-bit, so we need "long long"?). I have no idea why you think binary literals are all that much more useful than octal or hex. Macros aren't type-safe, but C++ templates are. Name mangling is an implementation detail, and there's lots of variation between compiler output that isn't name mangling. Standardizing i
Re: (Score:2)
"I have no idea why you think binary literals are all that much more useful than octal or hex"
Binary literals are extremely useful when you're dealing with bits in specific places in a byte/word/etc. Its a lot clearer to read and a lot easier to write than trying to encode and decode into hex or oct.
"Standardizing it would accomplish very little, and there's no need for the runtime to know the mangled name."
Oh really? Just how do you think dlopen() finds the functions in a .so shared object file (.dll in wi
Re: (Score:2)
Could be; I don't have much experience in low-level programming using higher-level languages.
Binary literals would be nice, yes, but I don't see that as a big deal. I find hex literals almost as easy to read, and easier to type correctly. YMMV, of course, but I'd expect proficiency and ease with hex literals to increase over time.
C++ doesn't have a halfway standardized ABI, unlike C. Name mangling is just part of it. There's a lot of other compatibility issues. This is a problem with the language
Re: (Score:2)
I think 1996 just called and wants it's Usenet flamewar back.
Re: (Score:3)
php is not the worst because they measured completely the wrong thing. They measured how many bugs they found in the implementation of the language, not how many bugs a programmer using that language would introduce that the language would not catch for them.
Re: (Score:2)
Yes... and as I said, this is completely missing the point. Holes in language implementations can be fixed as they come up. Bugs that are caused because of bad language design, and lack of the language helping the developer hold all the necessary concepts in their head at once, those can not trivially be fixed like language implementation errors. Not only that, but they'll be several orders of magnitude more common.
An example. A language with a decent type system can completely eliminate SQL injection a
Re: (Score:3)
This sounds great and all that, but that's a very unreasonable statement. Consider C. I don't know a single person who would say that C is secure or that security wasn't built in from the get-go. The same can be said of C++. But those languages offer different benefits (speed and control both come to mind). It's a trade off, to be sure. But sometimes, you have to use a language that isn't secure "from the get-go" to build an application that needs security. We don't
Re: (Score:3)
C++, properly written, is much more secure than C. It includes memory management, type-safe I/O, and well-behaved library containers.
Re: (Score:2)
Let's try it the other way:
C, properly written, is much more secure than C++.
Huh, it still works. I guess that's what happens when you use a ridiculous qualifier like "properly written".
Re: (Score:3)
Except that I gave reasons why C++ is superior in security to C. It's easier to write secure code in C++ than in C. Both are difficult to write well, but well-written C++ code is going to be more secure than well-written C code.
Re: (Score:2)
WhiteHat researchers examined the vulnerability assessment results of the more than 30,000 websites to measure how the underlying programming languages and frameworks perform in the field
It's a small sample size if you said that they were all enterprise web applications I would expect that .Net and Java usage would be even higher.
Re: (Score:3, Insightful)
Re: (Score:2)
They came out around the same time, but their popularity as a web development language was separated by quite a few years. PHP was everywhere a few years before JSP and Servlets started powering bank websites all over the place.
Re: (Score:2)
Re: (Score:3)
I VOLUNTEER AS TRIBUTE ... but not for ColdFusion, ew.
Re: (Score:3)
People are still writing code vulnerable to SQL injection attacks?
Yes, they are. It doesn't help when lots of online tutorials give crappy information, like saying to use mysql_real_escape_string in PHP instead of a proper parameterized query. (Using the escape function is better than nothing, but it's not foolproof and is needlessly convoluted.)
This tutorial [w3schools.com], which ranks first on Google when I search for 'php sql', uses the escape method and does not mention parameterized queries at all. (The correct me