Slashdot Mirror
The 25 Most Dangerous Programming Errors
Hugh Pickens writes "The Register reports that experts from some 30 organizations worldwide have compiled 2010's list of the 25 most dangerous programming errors along with a novel way to prevent them: by drafting contracts that hold developers responsible when bugs creep into applications. The 25 flaws are the cause of almost every major cyber attack in recent history, including the ones that recently struck Google and 33 other large companies, as well as breaches suffered by military systems and millions of small business and home users. The top 25 entries are prioritized using inputs from over 20 different organizations, who evaluated each weakness based on prevalence and importance. Interestingly enough the classic buffer overflow ranked 3rd in the list while Cross-site Scripting and SQL Injection are considered the 1-2 punch of security weaknesses in 2010. Security experts say business customers have the means to foster safer products by demanding that vendors follow common-sense safety measures such as verifying that all team members successfully clear a background investigation and be trained in secure programming techniques. 'As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,' the introduction to the list states and includes a draft contract with the terms customers should request to enable buyers of custom software to make code writers responsible for checking the code and for fixing security flaws before software is delivered."
I'll sign such a contract, but the project will take twice as long and my hourly rate will go up 300%.
People like to draw the comparison with civil engineering, where an engineer may be liable (even criminally) if, say, a bridge collapsed. But this isn't really the same thing. We're not talking about software that simply fails and causes damage. We're talking about software that fails when people deliberately attack it. This would be like holding a civil engineer responsible when a terrorist blows up a bridge -- he should have planned for a bomb being placed in just such-and-such location and made the bridge more resistant to attack.
The fault lies with two parties -- those who wrote the insecure code, and those who are attacking it. I'll start taking responsibility for my own software failures when the justice system starts tracking down these criminals and prosecuting them. Until then, I'll be damned if you're going to lay all the blame on me.
Holding a gun to somebody's head won't make them a better developer.
I don't understand why well-known and tested techniques can't be used to catch these bugs. There are many ways to help ensure code quality stays high, from good automated and manual testing to full-on code reviews. The problem is that most companies aren't willing to spend the money on them and most open source projects don't have the manpower to dedicate to testing and review.
TFA seems like it's just looking for somebody to blame when the axe falls. If your method of preventing bugs is to fire everybody that makes a programming mistake pretty soon you won't have any developers left.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
"Insisting on absolute safety is for people who don't have the balls to live in the real world."
- Mary Shafer, NASA Dryden Flight Research Center
some jackass circa january 1986
As much as we might like to think otherwise, software development is a business. And like all businesses the goal is to generate profit by increasing revenue and decreasing cost. As such an inherent bargain is struck between consumers and software shops as to proper ratio of cost to quality. High volume consumer applications get a lot of attention to quality though less to security. It's all a matter of threat assessment verse the cost of securing against such threats. Sure we all want perfect software where the software engineer is held accountable for every bug. But we also want software whose cost is comparable to a 20 dollar an hour sweet shop programmer. The software that results is really an economic compromise between the two. Running a space shuttle or saving patients lives? You probably are willing to shell out for the high cost software engineer. Putting up your hello kitty fan club blog? You might settle for something a little bit less... high class. I've been in this business for awhile now and as much as we like to wax poetic about quality we are still just trying to have our cake and eat it too. Better, faster, cheaper. Pick two.
In the case of XSS I'd say fix (X)HTML and the browsers. By default scripting should not work in the body of a page. Force a meta tag to enable it in the head part of the page or by end-user override if they really must have it. There is really no reason scripting needs to be included in the body of a web page. Trying to completely block scripting, especially in IE which just executes damn near anything, is a real pain and often ends up excluding valid data such as comments including source code. If someone uses an unsafe browser it's their problem.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
"As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you,"
And, as a consumer, you have the power to influence vendors to provide better employment and buying practices by letting them know that they are important to you.
Meanwhile, the vast majority of America continues to shop at Walmart whilst every competitor goes out of business.
"Does it get the job done? Now what's the cheapest I can get it for?" is most people's primary motivation.
Sellers, who listen to them saying, "I want security!" and deliver that, at the expense of greater cost, are then left wondering why the competitor who did just enough to avoid standing out on security but otherwise kept their product slightly cheaper is selling many times more copies.
So, yes, people can influence sellers with their actions. The problem is, it needs to be their actions, not their words. Even worse, they're already successfully doing just that - unfortunately, their actions are screaming something quite different to any words about, "Security is truly important to me."
Child molesters are really a special case; they have a mental disorder. However, even there the system is fucked. A guy who screws a 16-year-old girl when he's 18 is NOT a child molester. The only people who should be guilty of true child molestation are those who molest pro-pubescent children, like 12 and under. That's where you someone is truly sick in the head, because no normal man would ever be attracted to a pre-pubescent child. But lots of men will admit to being attracted to a 17-year-old girl. Lots of female movie stars aren't much older than this.
Actually, I have to say I can't blame the guy. There's some freaks on this site who think it's funny to "out" someone. Someone did it to me a while ago, calling me by my real name, even though there's no references I know of in my profile to my real identity. I have no idea how he did it. It's why I never say much specifically about my employment here, or if I say a little too much, I post anonymously, even though I hate doing that because it makes it impossible for me to read any responses.
So if Mr. Anonymous gives enough information about his crime, some freak could very well go to the trouble of spending a day digging through government websites to try to find his real identity and post it here.
It's probably not the particular statute, but rather the particular way that made the statute of limitations do weird things. When you multiply small chances, you get small numbers really quickly. And it might have been a local law he violated.
(P.S. If you're thinking "same person", just ask an admin to verify that my IP address is different.)
There's another problem here which we seem to be forgetting: The user.
Users continue to buy systems with inferior security -- every dollar spent on Windows is a dollar telling Microsoft that you're OK with them taking months to fix known security bugs, and Apple is no better. Maybe this "contract" would help, though it will kill Easter Eggs, among other things, and that makes me sad.
But even if you design the most secure system ever, it's useless if the users aren't educated about security. This was specifically a list of programming errors, but put it into perspective. There's really nothing I can do to keep people from reading your email, modifying it, or impersonating you entirely and undetectably in an email sent to someone else (which you'll never see), if you aren't willing to at least learn the basics of something like PGP. If you learn PGP and use it properly, and convince all your friends to do the same, and people still do nasty things to your email, that is the point it becomes the programmers' fault, but you have to meet them halfway.
Don't thank God, thank a doctor!
Really bad.
The problem is that 99% of us fellow programmers are full of sh*te and know next to nothing. How many programmers do know what a rainbow table is? How many know what use a salt is for? How many know that in most PKCS the public/private key pair is typically used to exchange a symmetric key and why is it so? The birthday paradox? How many know how a timing attack works?
If you think that's bad, I've got much more worrysome: most programmers simply do not understand at all how public/private crypto keys work. I remember scratching my head on this, last century, when I read about it. I simply couldn't understand it at first. "Why would it be slower without the private key?". I went on to write my own algo to crack weak keys. Just to "master" the topic. Who takes that pain?
Another monstrously huge problem is that you can't really be a good programmer unless you've also at least some sysadmin skills. Do you eat stateful firewall rules for breakfast? Or may you know jack shit about networking and you're writing your applications so that it becomes a pain for sysadmins to install/monitor and they've got to pierce holes everywhere for your swiss cheese app to run correctly?
Face it, there are so many security issues because most programmers are completely clueless when it comes to security.
You want to see how lame it is? Go look at the retarded answers voted +30 on stackoverflow.com on some subjects: I saw one accepted answer with 32 votes where the dude explaining what a salt was completely missing the point. Then there was a deluge of comments telling him he and all the people who voted this crap answer up where on heavy crack, yet the comment defending the bogus and stupid answer themselves kept being modded up too. Then of course if you get a bit too vocal in your own answer (who still gets some +votes because they're not all complete retards) because you're pissed off to read such misinformation you've got retards with lots of rep like Shog9 who're going to play the revisionists with your posts and for lots of these high reps are completely clueless too, they actually change the meaning of what you wrote, making it wrong (not on purpose, it's incompetence, not malice). And that "tragedy of commons" website of crap is where the "real programmers" hang out. Sad.
This is how bad the situation is: most programmers really have no fraking clue about security. Most programmer don't even know what a stateful firewall is.
Worst of them all: because XSS and SQL-injection are not hard to understand, they *think* they know it all about security when they know what these attacks are. Yet they are actually completely clueless for about 20 others issues of these 25 listed.
The bullshit answers "but the bad buy are attacking us" are no excuse for our incompetence and lack of knowledge.
Thank you for an enjoyable half hour wandering through your website. You're a total nutter, but it pleased me to see that my Internet Kook detectors are properly calibrated.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Having programmers imagine every way that their program may be attacked is impossible.
Fortunately, that's typically not required for software security. In a lot of cases, you can prove that for all inputs, the software does the intended thing.
For instance, if you know that the username variable will always be properly escaped, you don't care whether the user is called "bobby" or "bobby tables" (http://xkcd.com/327/).
It takes a lot of discipline, though, to always consider who the origin of a particular piece of data is, to decide (based on that) exactly what amount of trust to place in it, and how to handle semi- or untrusted data.
More to the point, the astronauts explicitly agreed to the risk. They knew what they were doing.
It's really not the same thing as bridge building at all. xD
I think that companies (management) should be held liable for poor quality of the software they produce. How each individual company distributes that liability internally is completely up to them. So whether you want to work for a company that holds its developers financially and legally liable is completely up to you. My guess is that that such companies would quickly go out of business.
I work in the telecommunications industry managing (first line - still a pawn) a sizable team of software designers. If one of my designers creates a security hole which is subsequently successfully hacked, it could mean that 911 services go down somewhere and someone unnecessarily dies. That being said, a bug in our software typically means that someone somewhere can't download their porn.
Here's how the process (for me) works:
1) Customer sees a need for new functionality and communicates that to the company
2) Request goes to Product Line Management and they get R&D involved for some preliminary time and cost estimates
3) PLM then squeezes the timeline and passes on the date to management
4) Management squeezes the timeline again and passes it back to the customer
5) Customer then requests a reduced cost and an even earlier delivery date
6) Management agrees to terms
7) R&D is stuck developing a release in 1/3 time it takes to develop properly
Also, the code base is millions of lines of disjointed code that are very difficult to manage effectively.
In order to devliver software under these conditions, we depend on heroics from our developers... they're definitely overworked, but not underpayed. We also have to cut corners by only performing specific targeted testing. In the end, our products have their fair share of bugs, and some of those bugs could be catastrophic. However, that's what the customer negotiated and paid for, so that's what they got!
Everyone of my designers would like to produce better software (not perfect - that's impossible). They're just not afforded that privilege by management and customers. So do I think software developers should held responsible? Hell no... they should learn from their mistakes, but holding them financially and legally responsible means it will take 10 times longer to develop software.
That is because the referenced article is about security (you cannot tell this from the title alone, but it is clear from the context in which the original appears.) It does not address design or semantic errors, so the 'chip & pin is broken' issue from yesterday would not be a candidate, and the chosen errors are weighted by frequency of occurrence. All in all, it is a pretty narrow scope for such a grandiose title.