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