Report: PHP, C++, Java, and .NET Applications are the Most Frequently Flawed (techrepublic.com)
92
Application-security company Veracode "has released the 11th volume of its annual State of Software Security report, and its findings reveal that flawed applications are the norm, open-source libraries are increasingly untrustworthy, and it's taking a long time to patch problems," reports TechRepublic.
The top three security flaws — like last year — are still information leakage, cryptographic issues, and CRLF injection: The report found a full 76% of apps contained flaws, and 24% of apps have flaws considered highly severe. Some 70% of apps are inheriting security flaws from their open-source libraries, but it's important to note that only 30% of apps have more security bugs in their open-source libraries than in code written in-house, suggesting that it isn't solely open-source projects that are to blame... In terms of how bugs are being resolved, Veracode found that 73% of the bugs it found as part of the report were patched, which is a big improvement over previous years, when that number was in the mid-50% range. Despite that good sign, it's still taking an average of six months to close half of discovered flaws...
Veracode also released a heatmap of the worst bugs in the most popular languages. Interestingly enough, the language with the least use of open-source libraries is also the one with the most bugs: PHP.
Looking at the heatmap, it's easy to spot which of the five popular languages included has the worst security. Following PHP is C++, then Java, .Net, JavaScript, and Python. The latter two are, doing considerably better than the competition, with the worst flaws in each only being found in roughly 30% of apps. Compared to PHP with 74.6% of its apps vulnerable to cross-site scripting, JavaScript and Python are security powerhouses.
The top three security flaws — like last year — are still information leakage, cryptographic issues, and CRLF injection: The report found a full 76% of apps contained flaws, and 24% of apps have flaws considered highly severe. Some 70% of apps are inheriting security flaws from their open-source libraries, but it's important to note that only 30% of apps have more security bugs in their open-source libraries than in code written in-house, suggesting that it isn't solely open-source projects that are to blame... In terms of how bugs are being resolved, Veracode found that 73% of the bugs it found as part of the report were patched, which is a big improvement over previous years, when that number was in the mid-50% range. Despite that good sign, it's still taking an average of six months to close half of discovered flaws...
Veracode also released a heatmap of the worst bugs in the most popular languages. Interestingly enough, the language with the least use of open-source libraries is also the one with the most bugs: PHP.
Looking at the heatmap, it's easy to spot which of the five popular languages included has the worst security. Following PHP is C++, then Java, .Net, JavaScript, and Python. The latter two are, doing considerably better than the competition, with the worst flaws in each only being found in roughly 30% of apps. Compared to PHP with 74.6% of its apps vulnerable to cross-site scripting, JavaScript and Python are security powerhouses.
Re: (Score:2)
It's time to kill AC posting for good
They're are logged-in users (Score:2)
AC posting for good
AC Posting *has already* been killed.
What you see are regular users, who log-in, but then check the "post anonymously" check box under their posts.
(I don't know if internally slashcode keeps a link between those posts and the original poster, so negative comments could affect karma even if the user account isn't publicly displayed).
Also, one off the forte of /. has been that they do NOT censor and even technically designed slashcode this way. Post can be down-modded into oblivion but they'll always continue
Re: (Score:2)
Nah. No need. One very simple troll filter would solve about 90% of the problems:
plaintext = substitute(text, /<[^>]*>//) // no more than half tags. /\W+/); /usr/share/dict/words)) { validwords++; }
assert(plaintext.length > text.length / 2)
words = split(plaintext,
validwords = 0
for (int i = 0 ; i < words.count; i++) {
. . if (words[i] in $(cat
}
assert(validwords > words / 2)
To be fair, I would probably have to pad this post for it to pass that test because of the code snippet, but
Tool is not job (Score:5, Insightful)
I thinks its very easy to create these vulnerabilities in python or js. To me security is mostly discipline and behaviour. Maybe PHP has a lower barrier of entry so âoeamateursâ tend to gravitate towards PHP? Im sure smart and experienced developers can make secure apps in any language
Re:Tool is not job (Score:4, Insightful)
I don't know what you call a "developer". Sure, smart and experienced programmers can write secure code in any language. However, there are very few actual programmers these days. The world is full of "coders" and other cut-n-paste wannabe's that have no bloody clue what they are doing.
Re: (Score:2)
I don't know what you call a "developer". Sure, smart and experienced programmers can write secure code in any language. However, there are very few actual programmers these days. The world is full of "coders" and other cut-n-paste wannabe's that have no bloody clue what they are doing.
And people who do that can easily create a security vulnerability in any language. With the exception of C++, which exposes pointers directly, there's nothing particularly unique to any of these languages security-wise. So really, all this tells us is that there's a lot more code in those languages that was written by those inexperienced coders at a time when the available example code gave people bad advice (e.g. using non-parameterized MySQL calls).
Re: Tool is not job (Score:3)
Thank you. I was looking for a place to post amongst the wall of tools posting trolly ascii things....
I was just going to day, hmmmm, the four languages most prone to imperfect software also happen to be 4 of the most popular languages? Shocker! :)
Re: (Score:2)
I don't know what you call a "developer". Sure, smart and experienced programmers can write secure code in any language. However, there are very few actual programmers these days. The world is full of "coders" and other cut-n-paste wannabe's that have no bloody clue what they are doing.
Very true. When I tell people I have done real work in > 10 languages and have done smaller tings in 30 or so, they cannot believe it. And I am not even a real programmer, I do that mainly on the side. The typical "programmer" these days is a 1-trick pony that does not even understand that one language they can somewhat write code in.
Re: (Score:2)
There are more programmers today than there ever have been, however applications are generally far more complicated than they have ever been. Further, many vulnerabilities we deal with today are a direct result of programmers in the past not giving the slightest consideration to security.
If you want to see people who don't have a clue roll back the clock a couple decades when the only requirement for the job was that you "knew computers".
Re: (Score:2)
however applications are generally far more complicated than they have ever been.
That doesn't excuse things like not understanding how databases work in the language in which one programs. I'm looking at you, Java coders.
Re: (Score:2)
PHP's big problem is that there are tons of legacy code out there that haven't been updated in decades. Many of them were written with old APIs before parameterized queries were a thing.
Most Python code is newer. Most old JavaScript is on the client-side. On the server-side, most node.js code is newer.
Re:Tool is not job (Score:5, Insightful)
Security by "just don't make mistakes" will never work. What you need is layers, defence in depth. Then even amateur code is okay because the damage it can do is limited.
Re: (Score:1)
It's the basis on which the mobile app ecosystem works. Limited permissions, sandboxes. That's why most mobile malware tries to trick the user into giving up the wanted information, there just aren't an endless stream of zero day root exploits appearing like there were back in the day.
Re: Tool is not job (Score:4, Insightful)
No application, either desktop or mobile, needs to use a web server. The CRLF attack is specific to the web.
There's more to the internet (and networking in general) than http/https and web servers and JavaScript and cookies.
Re: (Score:1)
The CRLF attack is laughable -- clearly thought up by an self-proclaimed authority who has no fucking clue what they are talking about.
Though perhaps this sort of stupidity is aimed directly as the sort of stupid ignoramuses who think this is a thing.
Re: (Score:1)
Your so-called "mobile app ecosystem" is inherently insecure by design. There is no meaningful way to limit privilege. On top of this, the whole thing is designed by the unwashed for use by the unwashed to make money for the unwashed. In other words it is a vast conspiracy by the stupid to take advantage of the stupid.
The only prudent course of action is to stay far far far away from such crap.
Re: (Score:2)
Then even amateur code is okay because the damage it can do is limited.
This doesn't work. Any developer who is writing useful code has the ability to write a software vulnerability.
The answer is to avoid making mistakes, and defence in depth. It doesn't matter how many layers you have if they are filled with holes by incompetent developers.
Re: (Score:2)
Very much so. Defense in dept only works if the code is well-written and mostly secure in the first place. Redundancy of this type only works if you have a low number of defects and a sound design in the first place.
If you have a significant number of vulnerabilities or a bad architecture, it becomes worse than regular code, because the mechanisms added for defense will add vulnerabilities themselves.
In all of engineering, the only thing that can replace insight, skill and experience is more insight, skill
Re: (Score:2)
I have to strongly disagree. First, security by "know what you are doing" does work with competent people (of which there are few). It does work because they will automatically do defense in depth. At the same time, defense in dept does not help a lot with incompetent coders. Defense in dept needs people that know what they are doing to be effective. When the first module in your carefully privilege-separated code already can gain root, you have lost.
Re: (Score:2)
What you need is layers, defence in depth. Then even amateur code is okay because the damage it can do is limited.
Multiple layers of insecure code is just as insecure. An analogy is six one foot deep walls each with a large section made up of styrofoam bricks. It looks good and is defense in depth but once someone knows about the styrofoam bricks, one knows to look for more deeper in.
Re: (Score:2)
I have to disagree. It takes discipline between all the layers and layer writers and reviewers. You can't just wrap your way to security and let one level be lackadaisical expecting the other layers to magically catch and prevent all problems. Careful abstraction layering helps, but is only part of the total solution, which also includes "don't make mistakes".
It takes a multi-pronged approach, not "just do X and everything will b
PHP is perfectly safe, even for n00bs ... (Score:5, Insightful)
... if used for the stuff PHP was specifically built for: Filling web documents with logic.
Things always go sideways when the inner platform effect kicks in and inexperienced or badly educated webdevs try to do something smart while under pressure and are expected to perform miracles on a shoestring budget. This is most likely in classic web projects where PHP is used and what PHP was built for.
WordPress is a perfect example. Bizarre archtecture, built by n00bs, run by n00bs, used by n00bs. Yet it is still the most secure system out there. 250 Million installations and counting. The last critical exploit had 8000 sites infected until it was patched. That sounds like much until you realize that that's something like 0.0002% of the entire active installbase. I seriously doubt any "super safe" Java or Scala thing would have a better track record at the same scale.
Everything is procedural. And that's actually really great. Introduce a bug and even the dimest of people will notice, because your entire website throws a 500. Bugs show immediately, Imagine having a bug that requires a debugging proxy to even surface. Or a system that, unlike PHP, requires babysitting an appserver 24/7 (I'm looking at you Node and Java). Yeah, they may be safer in theory, but I'd rather have a system that has 250 million active installs and a epic army of people maintaining it.
And yes, if someone doing PHP for a living tries to do Auth/Auth and safe session management without knowing the basics or what to watch out for, things get unsafe very fast. And that situation happens more in PHP because PHP has more n00bs because PHP is easier to get into. But that's not a bad thing, if handled correctly.
My 2 cents.
Re: (Score:3)
Wanna make it better? (Score:5, Insightful)
open-source libraries are increasingly untrustworthy
Most open-source libraries are coded by nice guys on their own time, and most of the multi-billion companies that build their products on top of them and profit hugely from them are plain freeloaders.
Have security and reliability demands? Do it yourself or pay the authors, you fucking cheapstakes.
Re: (Score:2)
Most open-source libraries are coded by nice guys on their own time, and most of the multi-billion companies that build their products on top of them and profit hugely from them are plain freeloaders.
I think both of the above claims are false.
First, "most open source libraries are coded by nice guys on their own time". There are a few like this, but the vast majority are primarily written by people who are paid to work on them, mostly by big corporations.
Second, "most of the multi-billion [dollar] companies that build their profits on them [...] are plain freeloaders". Again, I suppose there are some like this, but all of the major corporations I can think of that build their businesses on open sou
Re: (Score:2)
There are a few like this, but the vast majority are primarily written by people who are paid to work on them, mostly by big corporations.
I would like to see some credible evidence of this.
So the company that Shouts Flaws Flaws Flaws (Score:2)
I know security is an issue I deal with it every day and I am just a developer.
But this is just marketing drivel from a marketing companies marketing dweebs.
Nothing to see here folks. Your time is best spent elsewhere.
Re: (Score:1)
Yup, the number 2 "security flaw" for Java is "Code Quality". Which by their own description isn't a security flaw /facepalm.
Their code scanning also doesn't take into account what this code is used for. If I use a random number generator to generate some random dice throws, I don't care if that's secure or not. Same with scripts that are intended to run locally and not on the public web.
Doesn't match my personal experience (Score:1)
Re: (Score:2)
Make a typo? You'll discover it when your application crashes, if you're lucky.
% pip install pylint
Re: (Score:2)
Or pyflakes. pylint does catch more errors, but it is slow and has too many false positives. pyflakes is fast and does well at catching typos.
My recommendation is to always run pyflakes locally before committing anything, and check what pylint -E says on occasion, maybe run it on a CI server.
Re: (Score:2)
Or pyflakes. pylint does catch more errors, but it is slow and has too many false positives. pyflakes is fast and does well at catching typos.
My recommendation is to always run pyflakes locally before committing anything, and check what pylint -E says on occasion, maybe run it on a CI server.
Or you could, you know, use a language with a compiler. As a bonus, your code will run much faster. Python is a sysadmin/system automation language that is only used because academics outside of CS couldn't afford devs (the extra tuition goes to new buildings and administrators, not to teaching or research) so they get the student sysadmins to teach them to program/help them with their modelling code. This created an academic user base of non-CS programmers who continue to hammer in that screw. Its a PE
Re:Doesn't match my personal experience (Score:5, Insightful)
I find it harder to write a Python application that is free of bugs. Make a typo? You'll discover it when your application crashes, if you're lucky.
Out of interest have you tried adding "static" typing. You need an external typechecker, i.e. mypy. Basically you can write actual python with static annotations (it's part of the syntax now), but you need to run it with a typechecker since the interpreter won't actually do anything with the annotations.
It's not a panacea by any means (and interaction with packages is imperfect for sure), but it does get rid of a lot of pointless and annoying bugs. Also it helps document the code because when you have:
some_var = some_library.some_function();
versus
List[Tuple[String,Int]] some_var = some_library.some_function();
the latter is much easier to figure out when you come to the code.
My recommendation now is to write all new code with static types unless there's a good reason not to, e.g. you need to support old interpreters. You can have static checkers running on your CI server or testing infrastructure.
I'm not being evangelical about it. It's still a bit wretched. For example in the line above, if that library doesn't have type checking, the assignment is unchecked, and will not throw an error if the library returns something different. The type checker from that point on assume the type of some_var so if you try to treat it not as a list it will fail. So there are still major gaps, but it's half way to being good, and catches a lot of bugs, just not all.
Re: (Score:2)
Currently I'm using an IDE (PyCharm); it doesn't catch all mistakes, but it boosted my Python productivity quite a bit.
Re: (Score:2)
I find it harder to write a Python application that is free of bugs. Make a typo? You'll discover it when your application crashes, if you're lucky.
You should discover it when your automated tests fail, not when your application crashes. If you're not writing thorough tests along with your code, you're not writing code that is free of bugs[*], regardless of the language. Dynamically-typed languages make the need for thorough testing a little more acute, and I prefer static typing myself, but the number of bugs you write really shouldn't be much different. The process changes a bit, is all.
[*] It should be kept firmly in mind that you can never write
Re: (Score:1)
Besides, weak typing is just one of the pitfalls of which you must be wary when coding in Python. Shall we talk, for instance, about global variables that become local if you begin writing to them, somewhere within the body of a large function?
Overall, the design of Python tends to disregard complexity, and deliberately so, because that is a desire
Most Used Equals Most Flaws (Score:2)
Since it is all made by humans it will all have flaws.
Since these applications are created by the most used languages, they have the most flaws.
Re: (Score:2)
Since these applications are created by the most used languages, they have the most flaws.
Did you overlook that they are counting security flaws per application?
The most used languages have more high-quality libraries, and the more work you can farm out to a high-quality library, the less opportunity you have to add bugs of your own.
Re: (Score:2)
Maybe I should have stated explicitly that the more popular the language/application the bigger chance of less experienced folks adding bugs or calling bugs from libraries that maybe aren't fully vetted. Similar to a parked car that looks fine til you try to start it. No clue who might have messed with it.
Re: (Score:2)
.NET? Which language (Score:2)
Re: (Score:2, Funny)
Re: (Score:1)
Developers pick .NET because that's where the demand and money is. Which platform pays more? There are niche languages/platforms that pay more, but specializing in them limits your geographical range, as is typical with over-specializing.
(This is not a reply about the quality of .NET nor .NET developers.)
Re: (Score:2)
In the UK .Net programmers are actually absurdly well paid. No idea why. Perhaps they already have to much .Net legacy code and struggle to find people brave enough to cope with that?
Re: (Score:3)
There must be a huge difference wether code is written in a scripting language or F#.
On .NET? Unlikely. With .NET you get all the language features you want as long as your favourite color is black...I mean, as long as your desired language features are those of C# or easily translated to them.
Re: (Score:2)
C#, still no typedef, still no #include, still no way to export type aliases from one library to another, and so on.
You will find that everything lacking in C# is this same kind of trinity of "go fuck yourself, we are still following our starting religion"
Its good on paper. The theory goes that you wont need typedefs or includes or typed aliases because everything is an exportable symbol. The idea is that a library can replace all the functionality of he
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That is not how it works.
There is a standard library, all languages can call in, the CLR. And there is a common bytecode.
F# or Python or what ever is not translated to C# "features", it is compiled to bytecode.
Re: (Score:2)
Re: (Score:2)
The bytecode not, but you simply wrap the function in a class ... and use a lambda. And if it is complicated, you keep state in the object representating the continuation.
Java is doing it like that and the .Net VM is extremely similar to the JVM.
Re: (Score:2)
Results are about the code scanning tool (Score:5, Interesting)
They programmed their code scanning tool to find things which occur most commonly in PHP. Then C++, Java, etc. The real variability is what their tool detects as a security flaw. Some flaws are easy to detect via static analysis. Some are very hard.
Or take a crypto library and declare a bunch of functions in it "bad" and not to be used. Unsafe parameter passing or they used old easily broken ciphers, etc. A language where that library is commonly used now gets a bunch of "Cryptographic Issues" security flaws. But do the exact same thing in a different language with a different library and it doesn't get counted, because their scanner doesn't know about that library.
Java? (Score:2)
Re: (Score:3)
In the report though Error Handling, Untrusted Initialization and Buffer Management errors are at 0% for Java though, while they're at 60, 20 and 50% for C++.
The other errors where Java scores high are far less exploitable. The CRLF attack especially seems to me to be highly unlikely to be possible in any modern Java framework. I suspect it is misdetected, especially since there is no reason why Java would stand out in that regard, while all the others (including its close cousin C#) donot.
Re: (Score:2)
CRLF Injection! (Score:2)
Re: (Score:2)
Prof Wikipedia says it's another name for HTTP response splitting [wikipedia.org]. An HTTP response consists of a header and a body, separated by two CRLF sequences. The header consists of fields separated by single CRLF sequences. In HTTP response splitting, the attacker tricks the web server into printing a field that has two CRLFs embedded in it, so that the browser will treat whatever follows them as the body, not the header.
For this to work, the web server or web application usually has to have a bug where it echoes b
Re: (Score:2)
OWASP losts this as well: https://owasp.org/www-communit... [owasp.org]
Re: (Score:2)
Re: (Score:2)
Yeah, I wondered if that was what it meant. It would make more sense - a few years ago, we had to add anti-CSRF tokens to all the pages in our application, and write a couple of server-side classes to generate them and validate them. We've never had to worry about CRLF injection. I assume (!) that the web server we're running on takes care of preventing that.
Re: (Score:2)
The Aztec gift to Europe: Syphilis. The Microsoft gift to humanity: CRLF.
Newflash: Most popular software toolkits ... (Score:2)
... are most popular!
Also get used by the largest amount of critical projects and attract the largest amount of developers to build their first mission-critical project.
I'm sorry, but no Nobel Prize for that insight.
The project Iâ(TM)m currently on is very secu (Score:2)
It isnâ(TM)t run over public networks, and has no per user settings. So âoesecurityâ isnâ(TM)t really a metric that applies to it.
Buggy as all hell though. Itâ(TM)s a Windows c++ program that started out 25 years ago as a C program running on MS/DOS. Itâ(TM)s grown kind of like a fungus, that is to say, organically, without real design as such. Most of the crash bugs are well known and documented, and usually involve null pointers or buffer overflows.
And I suspect thatâ(TM
Human Error is the root cause (Score:2)
It's all about human error, introducing bugs and security flaws. Large code bases plus complex languages means the developers might not have their heads wrapped around all the things they need to know. Coding secure C++ is difficult and it gives developers the absolute freedom to shoot themselves in the foot. Rust is a new C++ language with robust compiler that catches most of these mistakes and it's highly opinionated forcing the developer to comply with it's demands before it produces a binary. This h
Er (Score:1)
Application level security .. (Score:1)
PHP the worst by far. (Score:2)
PHP is way, way out in front [veracode.com] in terms of exploitable holes. I sincerely hope that this is not news to anybody, and that if you are a PHP programmer who thinks that they are a god genius like nearly every PHP programmer does, that you will soon step into an open manhole and die painfully in the dark.
Re: (Score:2)
Writing secure php db inserts, for example, takes 10 lines of code vs 1. Most examples are of the one line variety. Lots of inexperienced cut and past type people and you end up with problems. Insecure examples get voted up on the help sites all the time.
Re: (Score:2)
Fresh from the self contradiction department: "competent PHP professional".
Re: (Score:1)
The problem ... (Score:1)
Re: (Score:1)
This is a bogus claim (Score:2)