Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Most Dangerous Programming Mistakes

Soulskill posted more than 2 years ago | from the it's-probably-fine,-we'll-test-it-live dept.

Programming 213

snydeq writes "Fatal Exception's Neil McAllister discusses the most dangerous programming mistakes, and what can be done to avoid them. 'Even more than input validation errors, this year's list is rife with application security blunders of all kinds. Some of them sound fairly esoteric, such as "inclusion of functionality from untrusted control sphere." But of all such errors, the highest-ranking one on the list is "missing authentication for critical function" — in other words, the attacker was able to gain access because there was no lock on the door to begin with,' McAllister writes. 'With the pace of Internet attacks accelerating, now is not the time to cut QA staff or skimp on testing and code review.'"

cancel ×

213 comments

Sorry! There are no comments related to the filter you selected.

Better link (5, Informative)

Chris Mattern (191822) | more than 2 years ago | (#36632870)

If you'd like to read what the mistakes *are*, instead of a fluff piece that amounts to "oh, they're so awful! And people make them all the time, too!", here's the actual original article: http://cwe.mitre.org/top25/index.html [mitre.org]

Re:Better link (5, Insightful)

frinkster (149158) | more than 2 years ago | (#36632916)

If you'd like to read what the mistakes *are*, instead of a fluff piece that amounts to "oh, they're so awful! And people make them all the time, too!", here's the actual original article: http://cwe.mitre.org/top25/index.html [mitre.org]

Is one of the mistakes "Not being able to click on a link"? I would check myself, but I can't click on the link.

Re:Better link (2)

fnj (64210) | more than 2 years ago | (#36632948)

Slashdot is busted as usual. Cut and paste.

Re:Better link (1)

countertrolling (1585477) | more than 2 years ago | (#36633048)

Right-click - Open Link in New Tab

Re:Better link (2)

sorak (246725) | more than 2 years ago | (#36633198)

For me, the slashdot break also breaks the context menu. As far as I can tell, the only way to follow a link is to reply, quote parent, and copy and paste from parent's HTML.

Re:Better link (0)

Anonymous Coward | more than 2 years ago | (#36633226)

Ditto, in Firefox 5 I get no context menu, although I do get a context menu with IE9. But it's not all links, the ones in the summary work fine.

Re:Better link (2)

Qzukk (229616) | more than 2 years ago | (#36633390)

I think they tried to fix the "clicking anywhere opens parent comment" bug by blocking you from clicking anywhere. Not the first time they broke slashdot this way. Expect things to go back to the old brokenness in about 2 weeks, I think that's how long it took them last time.

Re:Better link (1)

fast turtle (1118037) | more than 2 years ago | (#36633424)

Strange. I'm not seeing any problems on FF5 and Win7-64. Not sure what the problem is for everyone else.

Re:Better link (1)

Tx (96709) | more than 2 years ago | (#36633440)

You have javascript disabled, we don't.

Re:Better link (1)

Chris Mattern (191822) | more than 2 years ago | (#36633852)

Ah, that's why it's a link for me and not him. It's not good to force people to run javascript; I'll stop being lazy and make sure I use HTML links from now on.

Did you try double right-click? (3, Informative)

tepples (727027) | more than 2 years ago | (#36633232)

To work around Slashdot's brokenness, did you try double right-click, then open in new tab? It appears to work for me in Firefox 5.

Re:Did you try double right-click? (1)

djdanlib (732853) | more than 2 years ago | (#36633504)

What wizardry is this?!

Re:Did you try double right-click? (2)

cowboy76Spain (815442) | more than 2 years ago | (#36633700)

I got it.

Double left click, right click, left click, triple right click, A, A, B, A, Up, Up, Up and I can see almost see slashdot as any other forum!

Re:Did you try double right-click? (1)

CraftyJack (1031736) | more than 2 years ago | (#36633950)

Same here. double right click works.

Re:Did you try double right-click? (1)

FrootLoops (1817694) | more than 2 years ago | (#36634150)

A fast enough series of right clicks worked for me, though I think it took more than 2. The key seemed to be speed. It's gone now, but this happened to me a day or two ago.

Re:Better link (1)

satuon (1822492) | more than 2 years ago | (#36633942)

I was wondering about that, too. It started happening since yesterday or the day before yesterday I think. I click on a link and nothing happens, but 'Open in new tab/window' works well enough. Is this browser-specific? I use only Google Chrome, but what do those using IE or Firefox have to say?

Re:Better link (3, Insightful)

baKanale (830108) | more than 2 years ago | (#36633182)

Switch back to the Classic Discussion System.

Re:Better link (0)

Anonymous Coward | more than 2 years ago | (#36633450)

You can drag the links to the tab bar and it will open just fine. (FF4/5 at least)

Re:Better link (1)

the_humeister (922869) | more than 2 years ago | (#36632982)

No list is complete without Therac-25 [wikipedia.org]

Re:Better link (1)

Chris Mattern (191822) | more than 2 years ago | (#36633910)

It's a listing of generic errors for the past year, not specific disasters across history. Not "Therac-25" and "the AT&T switch network crash", but "SQL injections" and "buffer overflows".

Re:Better link (0)

Anonymous Coward | more than 2 years ago | (#36632990)

This is in fact a dupe from 2-3 months back.

Re:Better Better link (1)

Anonymous Coward | more than 2 years ago | (#36633122)

Why not go to a good source from actual devs [stackoverflow.com] ?

If an exploding ball of fire isn't dangerous, what is?

Re:Better link (3, Insightful)

tepples (727027) | more than 2 years ago | (#36633960)

Obviously, not all mitigations on the list [mitre.org] apply to all situations. Here are some examples where they wouldn't apply so easily:

Where possible, avoid implementing custom authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment.

This can prove cost prohibitive when the authentication capabilities provided by the surrounding operating system are marketed for use only by privileged employees, not by the public. Consider the case of an operating system that charges per user account. (Microsoft calls this the "client access license" model.) One might be tempted to use or create an authentication and authorization library that runs independently of the operating system's own auth facility, so that one needs to buy a system user account for only the web server, not for each member of the public who creates a user account on the web site.

For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders

Say I encrypt the keys that a web server uses to communicate with other web services, such as the key used to communicate with a payment processor. Now how do I store the key to decrypt those keys?

For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key.

So how do we prevent an attacker from attacking a system while it is still in "first login" mode?

Clearly specify which data or resources are valuable enough that they should be protected by encryption.

Firesheep shows that this includes users' passwords and cookies containing authenticated session tokens. But with StartSSL having suspended operations and Internet Explorer on Windows XP still not supporting Server Name Indication, how can hobbyist web developers get the certificate and dedicated IPv4 address needed to host an SSL site?

If possible, create isolated accounts with limited privileges that are only used for a single task.

Please see my comment above about the CAL pricing model.

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form.

If you've ever seen errors about a "form key" on Slashdot, Slashdot is doing exactly this.

Do not use the GET method for any request that triggers a state change.

Is a hit counter a state change?

Use a built-in path canonicalization function (such as realpath() in C)

According to this page [stackoverflow.com] : "The realpath() function is not described in the C Standard." It's available only in UNIX, not in Windows.

Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not.

Does this mean don't bounce messages to nonexistent users but instead treat them as delivered and discard them? That would provide a bad user experience for people attempting to contact these users.

Use code signing technologies such as Authenticode.

How does a hobbyist afford the certificate for Authenticode?

For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.

Writable I agree with, but readable I'm not so sure. If configuration files are readable only by the administrator, then how can the program act on the configuration file when a normal user runs it?

Use a CPU and operating system that offers

A hobbyist on shared hosting or a virtual private server may not be in control of the CPU and operating system on which his program runs.

Locking out a targeted account [after failed login attempts]

My grandma ran into her credit union's online banking web site's policy of three strikes and you have to wait from Friday night to Tuesday morning for a branch to be open again. The tone of her voice indicated that this is not a pleasant user experience.

Choose a language that is not subject to this flaw.

Good luck getting this language's runtime environment deployed to all your end users.

If a user has a locked-down client that does not support all the features used by your application, consider allowing that user some access

So I guess this rules out reliance on a visual CAPTCHA because some locked-down clients that I know of don't display images.

why am I not surprised sql injection is first? (2)

youn (1516637) | more than 2 years ago | (#36632906)

Hopefully the increased use of frameworks that write sql will decrease that problem

Re:why am I not surprised sql injection is first? (1)

bhcompy (1877290) | more than 2 years ago | (#36633020)

Or, move to PICK and never worry about it again.

Re:why am I not surprised sql injection is first? (0)

Anonymous Coward | more than 2 years ago | (#36633296)

What's with all those Minecraft posts? It's like COBOL, only with blocks ;)

Re:why am I not surprised sql injection is first? (1)

Anonymous Coward | more than 2 years ago | (#36633128)

Dear Web Developers:

SANITIZE YOUR FUCKING INPUTS.

Sincerely,

Anonymous Coward.

Re:why am I not surprised sql injection is first? (3, Insightful)

Joce640k (829181) | more than 2 years ago | (#36633354)

Dear Web Developers,

Stop using toy languages. A strongly typed language that only accepts type "SanitizedString" as an SQL function parameter will end this problem forever.

No, it really won't. (1)

SanityInAnarchy (655584) | more than 2 years ago | (#36633536)

The sort of developers who continue to make this mistake will make it even in that language -- how do you generate a SanitizedString?

The correct response is to make it easy to do right. A good ORM in pretty much any language should help with this -- there's plenty of support for parameterized SQL in Rails, but you can (and should) avoid even that problem entirely by not writing any SQL at all.

Strong typing might help, but even there, the solution is the same -- syntactic sugar on the Right Thing, syntactic vinegar on the Wrong Thing, and focus on making it easy to do right, rather than hard to do wrong, since people will find a way to do it wrong anyway.

Re:No, it really won't. (2)

Joce640k (829181) | more than 2 years ago | (#36633814)

how do you generate a SanitizedString?

Via the object constructor.

SanitizedString s = UserInput; or doSQL(SanitizedString(UserInput));

If you allow implicit constructors then this: SQLfunc(UserInput); will pass a secretly sanitized version of the string to the SQL function.

Point is: If you stick to using the provided SQL library then it's impossible to pass unsanitized strings to it, the program won't even compile. This sort of thing should really be the default by now except language designers are too busy figuring out ways to let programming noobs multiply strings by fractions.

Re:No, it really won't. (1)

Joce640k (829181) | more than 2 years ago | (#36633954)

I forgot the obligatory link: This article [joelonsoftware.com] is usually held up as a shining example of how to do it right, I've seen it quoted hundreds of times on programming forums.

As Mythbusters would say: "There's your problem..."

Re:why am I not surprised sql injection is first? (0)

Anonymous Coward | more than 2 years ago | (#36633140)

Yeah, SQL injection attacks and why sanitising data is important are just lost on some people though.

A few months back, I went onto a web store to buy some stuff, and it just plain didn't work. The checkout didn't let me process my order, items randomly disappeared from my shopping cart. Frustrated, I decided to report this to them. As they didn't provide an email, phone number, anything, I had to use their "wonderful" contact form.

Guess what happened when I used an apostrophe in the contact form? Yup. SQL dump to the screen, for the whole world to read. I removed all the punctuation marks from the message and sent it, also noting the horrific SQL I was shown, but I never heard back. I wouldn't be shocked if they hadn't even received the message.

Re:why am I not surprised sql injection is first? (1)

Sl0vi (1994584) | more than 2 years ago | (#36633162)

It's only one of the oldest, most well known and easiest to defend against security issues that exist and pretty much all frameworks today have an easy and built in way to prevent sql injection. Still it's all to common to see people doing something like: string query = "SELECT * FROM table WHERE Id = " + id;

Re:why am I not surprised sql injection is first? (1)

bhcompy (1877290) | more than 2 years ago | (#36633266)

The easiest way to defend against it is to use a query language that actually only does queries. The biggest security hole is the fact that you can insert/update/delete through a query language

Re:why am I not surprised sql injection is first? (0)

Anonymous Coward | more than 2 years ago | (#36633310)

As a penetration tester I can assure you that I can do plenty of damage with just a SELECT statement.

SELECT from table CC where CC='1' OR '2' = '2'

Re:why am I not surprised sql injection is first? (1)

bhcompy (1877290) | more than 2 years ago | (#36633404)

You're assuming a query language that will allow that, though. That will do absolutely nothing in ENGLISH

Re:why am I not surprised sql injection is first? (0)

Anonymous Coward | more than 2 years ago | (#36633694)

He's assuming you're not an idiot or being an ass.

Re:why am I not surprised sql injection is first? (1)

Dog-Cow (21281) | more than 2 years ago | (#36633802)

To be fair, that won't do anything in SQL either.

Re:why am I not surprised sql injection is first? (0)

Anonymous Coward | more than 2 years ago | (#36634100)

Um, sure it will. You lack imagination.

It should return a massive number of results (depending on the size of the database), which may do any number of things: it might take a really long time to run. It might negatively affect the performance of the SQL server for the other people who're trying to use it. It might cause the script to time out and abort. It might cause the SQL server or the script to run out of memory and crash or abort. It might result in an error message that reveals information that an attacker needs to mount another attack (although that's more a problem with your error reporting). Or it might just let them see a bunch of records that they're not supposed to be able to see.

Table-valued parameters; query by example (2)

tepples (727027) | more than 2 years ago | (#36633402)

pretty much all frameworks today have an easy and built in way to prevent sql injection.

True, parameterized queries work in most cases. But I've found a few places where they're not ideal, and I wrote a bit of framework to implement other ways to pass strings to SQL safely.

A lot of SQL APIs don't support parameterizing a query that includes a table-valued parameter, such as the anonymous single-column table on the right side of an IN expression (e.g. username IN ('bluebear', 'chief', 'filbert')). So I wrote and tested a function mysqli_escape_list($connection, $array) to escape each item in an array and then format it as such a table expression, and then I use this function every time I need a variable number of literals on the right side of IN or VALUES. A web site called bobby-tables.com strongly recommends against this method, instead preferring code that constructs a string of question marks, a string of types, and an array of reference variables in parallel and then calling $stmt->bind_param() through call_user_func_array(). This appears hairier than the method that I use.

A lot of database search user interfaces are based on the general concept of query by example [wikipedia.org] : present a form representing a blank record to the user, then find records whose values match the fields that the user specified and ignore fields that the user left blank. There are two ways to implement this search in SQL. One is to include two separate parameters in the query for each field (e.g. "name", "ignore name", "town", "ignore town"). The other is to generate a WHERE expression and make sure to escape it properly. The first way is good when all fields are known up front; the second way is probably needed when the list of fields will expand in the future.

Re:Table-valued parameters; query by example (2)

Sl0vi (1994584) | more than 2 years ago | (#36633744)

Funny that Microsoft is way ahead of php and mysql on this area. .Net allows you to use parameters in reqular sql queries. Just add parameters to the command object as your are building your query. You never have an excuse not to use parameterized queries.

The cost of .NET (1)

tepples (727027) | more than 2 years ago | (#36634042)

You never have an excuse not to use parameterized queries.

Other than that one is trying to save money by not using a Windows server.

Re:Table-valued parameters; query by example (1)

Dog-Cow (21281) | more than 2 years ago | (#36633886)

Your second example is wrong. If you have to include every column in the where clause, but you only want to test non-blank entries, you use code like the following fragment:
where (columnA is not null or columnA = :columnA and (columnB is not null or columnB = :columnB)

If the table may change, you just generate your where clause dynamically, using the RDMS's data dictionary to get the column names.

ACLs on search columns (1)

tepples (727027) | more than 2 years ago | (#36634074)

where (columnA is not null or columnA = :columnA and (columnB is not null or columnB = :columnB)

What is this :columnB syntax? MySQLi allows only a question mark as a placeholder. Did you mean "switch from MySQLi to something else"?

using the RDMS's data dictionary to get the column names.

For privacy and load reasons, we allow the public to search only on some columns and not others. So we'd store the column names in an ACL instead of the INFORMATION_SCHEMA. Is that OK?

Re:Table-valued parameters; query by example (1)

petermgreen (876956) | more than 2 years ago | (#36634114)

There are two ways to implement this search in SQL. One is to include two separate parameters in the query for each field (e.g. "name", "ignore name", "town", "ignore town"). The other is to generate a WHERE expression and make sure to escape it properly. The first way is good when all fields are known up front; the second way is probably needed when the list of fields will expand in the future.

Another option is to generatea parameterized where clause. That way you get the flexibility to easily change the field list (from an allowed list of fields of course) while at the same time avoiding issues due to escaping mistakes (forgetting to escape, using the wrong escaping function* etc).

* The existence of things like mysql_real_escape_string vs mysql_escape_string in php shows how this sort of thing can be fucked up.

bind_param (1)

tepples (727027) | more than 2 years ago | (#36634352)

Another option is to generatea parameterized where clause.

If I generate parameterized SQL, how will I know the type and number of ?s in advance in order to do $stmt->bind_param('iss', $var1, $var2, $var3)? And if you say I should build three things (the statement, type string, and list of variables passed by reference) in parallel and then use call_user_func_array(), a mistake in keeping all three of those in the same order is no less likely than a mistake in $conn->escape_string($value). Or did you mean "switch from MySQLi to something else"?

The existence of things like mysql_real_escape_string vs mysql_escape_string in php shows how this sort of thing can be fucked up.

I understand that the reason for existence of the _real_ functions is that the correct escape varies based on the current SQL mode. This is why I always use the connection's escape method $conn->escape_string($value).

Re:why am I not surprised sql injection is first? (1)

Joce640k (829181) | more than 2 years ago | (#36634082)

Still it's all to common to see people doing something like: string query = "SELECT * FROM table WHERE Id = " + id;

Thing is ... this could be safe:

safe_string query = "SELECT * FROM table WHERE Id = " + id;

All you need is a "safe_string" object with suitable operator overloads and all the sanitization will be done by the compiler. It's impossible to not sanitize the input.

Problem is: It needs a proper programming language, not kiddiescript 2.6.

overvalued derivatives weren't a programming error (0)

Anonymous Coward | more than 2 years ago | (#36632942)

That was a pure greed, a Wall Street/Main Street feeding frenzy that would seize on the flimsiest evidence to justify the conclusion that the boom would continue indefinitely, enriching those with the foresight to seize the day. Coupled with willful lack of regulation and oversight from Washington and New York.

Newsflash!

Re:overvalued derivatives weren't a programming er (2)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#36633028)

Only little people are capable of error, so it must have been a programming mistake.

If little people are the problem (1)

tepples (727027) | more than 2 years ago | (#36633906)

Only little people are capable of error

Mitigation: Quit buying Fisher-Price toys [fisher-price.com] .

Mitigation 2: Don't hire people of short stature. Not advisable due to disability discrimination laws targeted at conditions such as heightism [wikipedia.org] .

Those aren't "programming" mistakes... (4, Insightful)

ThosLives (686517) | more than 2 years ago | (#36632958)

...Those are system design mistakes.

A programming mistake is one where you meant to type x+1 and instead you write x-1. Missing something like authentication or checking is a requirements or design problem, not a programming problem.

If software was a car, you wouldn't say it's a manufacturing problem if the car didn't have a place to install a lock - you'd say it's a design problem. It would only be a "programming" issue if it had a place for a lock but it was left uninstalled.

(Yes, I don't consider "programming" to include the design aspects; I consider "programming" to mean "conversion of requirements into computer code." The errors about which this article talks are mostly requirements problems, not implementation problems.

Re:Those aren't "programming" mistakes... (1)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#36633090)

Wait, wait: Are you saying that "programmer", "software engineer", and "computer scientist" aren't actually synonyms?

Re:Those aren't "programming" mistakes... (1)

L4t3r4lu5 (1216702) | more than 2 years ago | (#36633110)

I disagree. Sticking with cars (as is appropriate here), I'd consider it a design error if the stereo volume control knob was a SPST switch, a manufacturing error if it was installed connected to the seating controls, and a programming error if it caused the drivers seat to fold completely flat, then completely fold forward, three times a second.

Re:Those aren't "programming" mistakes... (1)

ThosLives (686517) | more than 2 years ago | (#36633188)

Yes, that's a much better car analogy... I was having a tough time thinking of one, sadly.

Re:Those aren't "programming" mistakes... (1)

nitehawk214 (222219) | more than 2 years ago | (#36633630)

Yes, that's a much better car analogy... I was having a tough time thinking of one, sadly.

Yeah, I need a car analogy on making car analogies.

Re:Those aren't "programming" mistakes... (1)

countertrolling (1585477) | more than 2 years ago | (#36633200)

Is neglecting to close a parenthesis a programming error or design error?

Re:Those aren't "programming" mistakes... (1)

ThosLives (686517) | more than 2 years ago | (#36633416)

Perhaps I'll just say I was testing the forum software's ability to check syntax =D

Re:Those aren't "programming" mistakes... (1)

countertrolling (1585477) | more than 2 years ago | (#36633604)

:-) Probably depends on the browser you use. We're all beta testers here these days. For instance, some of us are testing the forum software's ability to open links on click.. Seems that everybody is getting different results.. Just like people, each program interprets the same instructions in their own unique way

Re:Those aren't "programming" mistakes... (1)

antifoidulus (807088) | more than 2 years ago | (#36633222)

You obviously didn't read the article then. Many of the things listed are in fact *programming* mistakes(among them integer overflows, uncontrolled format strings, and tons about not trusting inputs). My favorite of the list is "CWE-676: Use of Potentially Dangerous Functions" It's amazing how many programmers just totally brush aside compiler warnings, and while not all warnings have security implications, many do....

But ultimately here's a hint people, the compiler isn't warning you for kicks, there's usually a pretty valid reason for the warning and you shouldn't just ignore it because your code still compiles..... but then again, maybe I shouldn't be the one making these calls, after all I have Ada experience :P

Re:Those aren't "programming" mistakes... (1)

OddJobBob (1965628) | more than 2 years ago | (#36633258)

I can't agree more. The number of times I have raised issues before deployment only to be told that it is "not a requirement" is beyond me. It is very hard to fix these things afterwards and I suspect that the reason these issues are ignored is because the requirements/software architect (same person in my case) has designed something so inflexible that they cannot change anything. Using something like DOORS is all well and good but garbage in still results in garbage out.

Re:Those aren't "programming" mistakes... (5, Interesting)

Short Circuit (52384) | more than 2 years ago | (#36633330)

You seem to be advocating a distinction of responsibility of knowledge where programmers should not need knowledge of design. I would dispute that.

First, all you've done is replace "programmer" with "compiler." If you posit that there is no need for programmers to do anything more than convert a design specification to code, then all you've done is define programmers as transcoders operating on a higher-level formal langauge than current compilers already do. That seems ridiculous; you'd be able to replace "programmers" with "compilers" for this higher-level language ("Technical writing in English") your design spec is written in. At that point, your designers are doing nothing more than programming in a higher-level language...making them programmers again. Look at the trends in new and redeveloped languages to include declarative behaviors for evidence of this already happening; dataflow-driven and declaration-driven language features are getting a lot of attention.

Second, if your programmers aren't expected to have or build knowledge of good design and design practices, then they won't be able to identify mistakes--especially critical mistakes such as the ones discussed in TFA. People are people, people make mistakes. Without other people or tools (created by people) there to catch some the mistakes, more of the mistakes slip past. And while it's perhaps easy to build a unit test suite from a design document, that unit test suite is going to be better at detecting flaws in the code, not in the design.

Re:Those aren't "programming" mistakes... (1)

ThosLives (686517) | more than 2 years ago | (#36633468)

You seem to be advocating a distinction of responsibility of knowledge where programmers should not need knowledge of design.

Hrm. That was not my intent. Basically what I was saying is that there is a difference in types of errors between design errors which persist even if you program them correctly versus the type of errors which are due to writing code that doesn't match the design.

Personally, I do agree that there is a more hazy line between "software engineering" and "programming" than just "implement design as code", and people that only implement design as code tend to make more errors than those who understand the system. I have seen this first hand; it's not necessarily a question of ability either - but if you have "coders" with no exposure to or understanding of the system, it's easy to make an implementation which really doesn't meet design intent (because often times the specifications are poor).

Re:Those aren't "programming" mistakes... (1)

Dog-Cow (21281) | more than 2 years ago | (#36633972)

I prefer to refer to people who translate requirements into functional code as "coders". As in (en)coders that translate English (or whatever your analysts write in) into something the computer (compiler) can understand. I hate coders with a passion because they are devoid of thought.

What kind of mistakes they are (4, Informative)

DragonWriter (970822) | more than 2 years ago | (#36633612)

Those are system design mistakes.

While TFS and TFA call them "programming" mistakes, the actual source refers to them as the "Top 25 Most Dangerous Software Errors".

A programming mistake is one where you meant to type x+1 and instead you write x-1.

No, that's a typographical error, not a programming mistake.

A programming mistake is when you incorrectly analyze the requirements and think you need to type x-1 to correctly implement them when in fact you need to type x+1.

But either one results in a "software error"; the list and the original source are fine, the fluff piece in between the original source and Slashdot (and, consequently, the Slashdot summary) is the only potential problem here.

If software was a car, you wouldn't say it's a manufacturing problem if the car didn't have a place to install a lock - you'd say it's a design problem. It would only be a "programming" issue if it had a place for a lock but it was left uninstalled.

While its fun to construct ways to point the finger somewhere else in an organization, or to pedantically categorize errors in to narrow boxes, what I'd say is that its a failure of each and every person who had sufficient contact with the product that they should have seen the relevant facts, and sufficient technical skill that they should have recognized the error, and who either did not recognize the error or who did recognize the error but did not take action to have it corrected [whether that was implementing a fix or providing notice up the line]. Plus all the people responsible for the process that produced the error.

And most of the errors on the list are things that, whether or not they should be explicitly foreseen in requirements, programmers are positioned to recognize and ought to be taking steps to prevent. Programming isn't narrowly constrained assembly-line work, at least in any organization that expects to produce quality software.

Re:Those aren't "programming" mistakes... (2)

DougReed (102865) | more than 2 years ago | (#36633660)

As the CTO of a small startup. My first programming mistake would be to hire someone who would build a car with no lock because the original drawing had no dot where the assumed lock would go. My old boss would love you. He thought 'programming' meant writing a thousand page Word document that got debated and revised over several months of meetings and finally coded by a 'clerk typist' with a degree in languages. Our department was disbanded because in a year, we did not manage to produce anything but 5,000 pages of MS Word. I got dinged on my review because the only thing we produced in that time was one program I wrote where the users told me what they wanted and I wrote it in a few days. He thought I was writing Word. When I showed it working... he hit the ceiling. The user's loved it.

You are indeed correct (0)

Anonymous Coward | more than 2 years ago | (#36633752)

These days, someone writes the program specs and hands same to a programmer, who (rightfully) assumes that the spec writer knows what he is doing.
One certainly cannot fault the programmer for faulty specs. One can and should fault management for the problems of faulty specs. Of course, most IT
management I ever encountered was incompetent (to say the least), and some of it was downright criminally stupid.

Re:Those aren't "programming" mistakes... (1)

graveyhead (210996) | more than 2 years ago | (#36634134)

I half agree. Some of the items in the list are indeed design mistakes, but others really are programmer mistakes.

The SQL injection one is the primary one I'm thinking is really a programmer error. Take this case from Drupal/PHP:

db_query("SELECT * FROM {foo} WHERE bar='" . $_GET['bar'] . "'");

That is totally incorrect and SQL can easily be injected into the statement from outside. When the API is used *correctly* this is not an issue:

db_query('SELECT * FROM {foo} WHERE bar="%s"', $_GET['bar']);

The difference is pretty subtle here and can easily be lost on newbies. As parameters to the db_query function, untrusted inputs are cleaned. I have seen the former code on several sites that I took over from a former developer, they are certainly NOT design errors.

QA - Microsoft is really to blame. (1)

Anonymous Coward | more than 2 years ago | (#36633008)

QA has always been considered the bastard children of software development. I've never worked on a project where they weren't treated like shit. I'm guilty too; which is really bad because I started out in QA/QC.

And on the business side, stop this horseshit of releasing code and having the customer find the bugs. Of course that won't happen. Some dipshit mgr is thinking, "Why have QA when the customers will find the bugs. We'll fix the first few and the charge them for a new and better release!" Now, this is the one time when blaming/bashing Microsoft is proper. They are the ones who made it the industry norm.

Re:QA - Microsoft is really to blame. (1)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#36633086)

QA has the unfortunate status of "Cost Center". And, no matter what their best intentions are, people and organizations inevitably face a strong pressure toward hating those. It's the same as those prick 'mechanics' with their "safety concerns" who cause flight delays. All cost centers attract a certain amount of dislike, ones that also have the power to cause schedule slips, or whose work deals with heading off things that merely might be a problem, are especially at risk. QA, unfortunately for them, fulfills all three: They cost money, the issues they point out have to be fixed, and can cause deadlines to slip, and(thankfully for the existence and survival of complex software in the world) many bugs are only harmful under unusual conditions, or are never discovered and exploited, this leaves them open to the charge that they are delaying important things with their insistence on fixing purely theoretical issues.

Re:QA - Microsoft is really to blame. (1)

jlusk4 (2831) | more than 2 years ago | (#36633156)

Development is also a cost center. Those whiners are constantly bitching about architecture. That's why we look for cheap developers who won't raise objections or otherwise make waves (like, with bright ideas), they'll just code. It's just a simple matter of programming, what the heck is up with them, anyway?

Re:QA - Microsoft is really to blame. (1)

Methuseus (468642) | more than 2 years ago | (#36633762)

Most places don't see development as only a cost center because they reap real benefits from it. Granted, some companies do, but I haven't personally seen them.

Re:QA - Microsoft is really to blame. (2)

countertrolling (1585477) | more than 2 years ago | (#36633098)

That's how the legislators write law also.. Throw out anything, and let the courts sort it out.. a public works program for lawyers

Re:QA - Microsoft is really to blame. (1)

OddJobBob (1965628) | more than 2 years ago | (#36633192)

Our QA department doesn't have a single person with a background in software and when I raised this concern to the engineering manager he didn't see my point.

We had a general manager who said that only quality products should be released to customers and as engineers we wholeheartedly agreed with him. The problem was that the vice-president of engineering had the view that it is best to be first to market and you can make it better after it ships. The general manager also said that he would not entertain a project that returned less than 40c on the dollar, yet the company only made 6% net profit in exceptionally good years and usually more like 2 to 3%.

Re:QA - Microsoft is really to blame. (1)

DragonWriter (970822) | more than 2 years ago | (#36633682)

We had a general manager who said that only quality products should be released to customers and as engineers we wholeheartedly agreed with him. The problem was that the vice-president of engineering had the view that it is best to be first to market and you can make it better after it ships.

These two requirements, as stated, are common in industry, and are pretty much exactly what Agile is directed at: You release quality product with a limited feature set first tat fills an unfilled need, and then expand the feature set in subsequent releases. You are, therefore, able to both release only quality product and release it quickly, making subsequent improvements that expand features after the initial release, without sacrificing quality.

Re:QA - Microsoft is really to blame. (1)

frinkster (149158) | more than 2 years ago | (#36633214)

QA has always been considered the bastard children of software development. I've never worked on a project where they weren't treated like shit. I'm guilty too; which is really bad because I started out in QA/QC.

And on the business side, stop this horseshit of releasing code and having the customer find the bugs. Of course that won't happen. Some dipshit mgr is thinking, "Why have QA when the customers will find the bugs. We'll fix the first few and the charge them for a new and better release!" Now, this is the one time when blaming/bashing Microsoft is proper. They are the ones who made it the industry norm.

Microsoft's Visual C++ compiler will throw a huge number of warnings for things like strcpy, telling you to use strncpy_s or something like that. If you follow the recommendation, potential buffer overflows become pretty obvious very quickly because the function zeros out the entire memory area that it is allowed to reach based on the parameters passed to it - and then does the copy. Your program will blow up during testing.

The current favored design pattern for a C# application is MVVC - model-view-view controller. This pattern makes it very easy to write test cases to automate testing of your interface.

I enjoy bashing MS when appropriate, but if you actually follow their recommendations you can avoid a lot of problems.

Re:QA - Microsoft is really to blame. (1)

acoster (812556) | more than 2 years ago | (#36633270)

With some versions of Visual Studio (and the Xbox 360 extensions for VS) Microsoft ships a static analysis tool, which is also very useful in finding potential problems.

Re:QA - Microsoft is really to blame. (4, Informative)

Joce640k (829181) | more than 2 years ago | (#36634174)

Microsoft's Visual C++ compiler will throw a huge number of warnings for things like strcpy, telling you to use strncpy_s or something like that.

You shouldn't even be using strcpy(). std::string has been around for more than ten years now.

Similarly arrays: Don't use them, use std::vector instead. Visual C++ vector even does range checking by default so this throws an exception instead of corrupting memory:

std::vector foo(10);
foo[11] = 123; // Will throw an exception in VC++...

A few basic changes in programming style can make C++ as safe as Java (but with none of the drawbacks). If you're still writing C code with your C++ compiler you're Doing It Wrong.

Re:QA - Microsoft is really to blame. (0)

Anonymous Coward | more than 2 years ago | (#36633304)

Testers and developers are natural enemies.

A developer's job is to create while a tester's is to tear apart. If the developer takes pride in their work they can easily slip into considering the tester's bug reports as a personal insult. Especially since testers usually think the bugs they find should not be there (technically true) or should be easily fixed, so it's easy for a tester to slip into talking down to the developer about that bug that's still there from two versions ago. From the other direction if the developers fail to fix a bug for long enough it's easy for the testers to think the devs are ignoring them (especially if they response with "that's a feature" at any point).

Add to this that depending on the corporate setup, you can get a blame game going if the project's deadline is slipping (developers say it's late because QA wouldn't approve it, QA says they can't approve it because the developers haven't met the spec), and it's trivially easy for an antagonistic relationship to form between development and QA.

And since technically you can release software that hasn't been tested, but you can't release software that hasn't been developed, developers tend to have the high ground when push comes to shove.

Re:QA - Microsoft is really to blame. (1)

tompaulco (629533) | more than 2 years ago | (#36633454)

And on the business side, stop this horseshit of releasing code and having the customer find the bugs.
Well, management thought outsourcing is such a wonderful idea, so surely outsourcing QA is also a good idea. Unfortunately, when you outsource to your customers, they may just decide to drop your crappy product and go to the competition. But as a savvy manager, after having received a large bonus for firing the QA department, you have smartly moved on to ruin a different company.

Re:QA - Microsoft is really to blame. (1)

Thud457 (234763) | more than 2 years ago | (#36633570)

QA has always been considered the bastard children of software development. I've never worked on a project where they weren't treated like shit. I'm guilty too; which is really bad because I started out in QA/QC.

Partially because QA is mostly made up of bastard children [leisuretown.com] /jk

In C++: (1)

cpscotti (1032676) | more than 2 years ago | (#36633072)

Virtual destructor on base class.

Re:In C++: (1)

cpscotti (1032676) | more than 2 years ago | (#36633080)

Mistake: the lack of it!

Re:In C++: (2)

Joce640k (829181) | more than 2 years ago | (#36634188)

My compiler warns me about this if I forget...

Summary of Article (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36633078)

"Java and C# are better than PHP" wrapped in buzzwords and it mentions "SQL Injection attacks" (yawn).

The whole thing is insulting to read for everyone more competent than management. As usual.

0/10

#1 (1)

macraig (621737) | more than 2 years ago | (#36633120)

This data type/structure is big enough; why would I need more to store larger values than I can anticipate right now? Keeping It Simple Stupid saves some bytes, too. Why would we ever need to store a four-digit year, anyway? What could possibly go wrong?

More Testers / QA is needed and stop the overtime (2)

Joe_Dragon (2206452) | more than 2 years ago | (#36633132)

More Testers / QA is needed and stop the overtime working 80+ hour weeks just leads to more errors and bugs.

Also don't get me started on rush jobs that just become try to work around the bugs and not take the time to fix them.

Headline reveals slashdot philosophy? (5, Insightful)

damn_registrars (1103043) | more than 2 years ago | (#36633138)

it's-probably-fine,-we'll-test-it-live

Could describe every "upgrade" to slashdot that has happened since ... well probably ever.

Therac-25 and nudie scanners (2)

spoonist (32012) | more than 2 years ago | (#36633178)

The Therac-25 [wikimedia.org] had some "Dangerous Programming Mistakes".

I wonder if the nudie scanners [wikimedia.org] have any similar mistakes.

Remember Y2K? It's the tools that need to improve (1)

Tony Isaac (1301187) | more than 2 years ago | (#36633186)

Y3K will never happen.

Is this because programmers learned from Y2K and changed their ways? Well, not exactly. Before 2000, most programming languages did not have a built-in date type, so programmers had to make their own, using either numeric or text fields. They didn't want to write ALL the code necessary to do ALL kinds of date calculations, so they just wrote the ones they needed, and these often ignored the first two digits of the year.

NOW programmers in nearly every language have handy date variables they can use, that perform date arithmetic easily and reliably. Programmers naturally use these date variables, because it makes their lives easier.

Today, it is difficult to incorporate good security practices into software. This is because we largely have to roll our own. We therefore write just enough code to do what we think we need, and we don't consider all the possible ways security can be breached. ONLY when the tools improve to the point that security comes automatically, will software, as a rule, be secure.

Re:Remember Y2K? It's the tools that need to impro (1)

twidarkling (1537077) | more than 2 years ago | (#36633274)

So you're saying programmers are lazy fucks who don't consider the consequences of their actions, and can't be trusted to figure out anything for themselves. Or that's how it reads, any way. I'd like to disagree with that.

Your scope isn't nearly broad enough. Change programmers to "95% of people" and you've got it about right.

Re:Remember Y2K? It's the tools that need to impro (2)

Tony Isaac (1301187) | more than 2 years ago | (#36633396)

No, I'm not saying programmers are lazy. It's just that there is always tension between getting a job done, and getting EVERY detail right.

They ALSO are not always as knowledgeable as they should be. How many programmers know that in 1752, when the Julian calendar was replaced by the Gregorian calendar, September 2 was followed by September 14? How many programmers care? Why should they? Yet this arcane bit of knowledge could make a difference in some software that deals with antiquities.

Just as there are arcane bits of knowledge needed to make perfectly precise date calculations, the same is true of security considerations. Programmers should HAVE TO KNOW every possible arcane exploit in order to write good code. They framework/language should take care of this.

The first answer is not QA (1)

jlusk4 (2831) | more than 2 years ago | (#36633196)

tl;dr (yet)

But I do have something to say about the immediate response of "QA". These are design issues (as has been mentioned). QA is not where you test out that sort of thing. Up-front design (not necessarily Big) should be the first response. Now is not the time to slack off on design, just because a lot of the components have already been written.

Inadequate tools (0)

Anonymous Coward | more than 2 years ago | (#36633252)

Of course mistakes are made when the tools are inadequate. For example, using SQL in a program by formatting a command and asking SQL to understand it. That is just crazy. Instead there should be a proper API which clearly tells SQL what is wanted. Then there would be no possibility of SQL injection.

Re:Inadequate tools (1)

Qzukk (229616) | more than 2 years ago | (#36633632)

There are APIs, it's called a parameterized query. Depending on your language and API, using them adds anywhere from 1 to dozens (bindparam) of extra lines of code compared to the string concatenation version. Apparently nobody thinks anyone would ever want to query($database,"select * from foo where baz=:baz",$_POST); so one-off queries end up being several lines of step-by-step piecewise execution (oh, and don't forget the return value checks between each step!)

Missing a Big One (3, Interesting)

Salamander (33735) | more than 2 years ago | (#36633512)

The Mitre list does include "Use of a Broken or Risky Cryptographic Algorithm" but in my experience that's far less common than improper use of a perfectly good algorithm. Many algorithms and modes have known weaknesses that require specific generation/handling of keys and initialization vectors to maintain good security. Most algorithms and modes that are secure against unauthorized *reading* of data still require an extra MAC step to prevent unauthorized *modification* of that data (including targeted bit-flips). Developers often take shortcuts in these areas because doing all of "the right things" adds a lot of extra complexity and can absolutely kill performance. Look at recent events involving Dropbox and Jungledisk for examples. I don't think the Mitre list adequately conveys that cryptographic security requires not just good low-level algorithms like AES or Blowfish but also good higher-level (usually domain-specific) algorithms governing how the low-level algorithms and their inputs are used.

NoSQL & Ajax fail (1)

laffer1 (701823) | more than 2 years ago | (#36633622)

Not a shocker. I've heard time and time again from NoSQL fans that it's ok to put your database on the public internet over HTTP with no locks. In fact, early versions of CouchDB didn't have security.

Another problem is that many novice programmers forget to secure their AJAX endpoints.. when you have 20 calls happening all over returning json, you often forget to check session or ensure authentication + authorization.

During my computer science courses, very few times did security come up. I had one professor who cared enough to discuss input validation, authentication, etc. It's this magic thing that we'll just figure out right?

Jump to the list (1)

cjjjer (530715) | more than 2 years ago | (#36633778)

Here is the the actual list [mitre.org] .

General programming (1)

pr0nbot (313417) | more than 2 years ago | (#36633784)

CWE is about "weaknesses", i.e. security. Does anyone know of a similar group or research into classifying and ranking common software errors? For example:

- dereferencing null pointers
- memory leaks
- stack corruption via buffer overflow
- out-by-one errors
- errors in error handling code that is infrequently run
- deadlock/resource contention
- faults characteristic of concurrency
- use of globals and code with side-effects

etc. All the stuff you learnt about at university, and then went on to rediscover in your job.

I've always thought that anyone designing a new programming language should have a big list of these and consider in each case what the language/compiler/library provides to mitigate/avoid these (garbage collection, static analysis, etc).

Anyway - anyone know of such a list/research?

Here's one (0)

Anonymous Coward | more than 2 years ago | (#36633966)

Had a friend who worked in the Mailing industry who liked to clean his own mailing lists (Rather than letting the experts in IT do it) in Access & Excel on one occasion accidentally sent 30,000 letters to the same man. As my friend put it "It was all right though because he was German!". Though the mailing house is now defunct and my friend now rides a motor bike it is somewhat reasuring to know that he is still a pratt!!!

The unmentioned BIGGER mistake... (4, Insightful)

ka9dgx (72702) | more than 2 years ago | (#36634190)

Using a system where the program has to be trusted to do its job correctly is the bigger mistake. When you hand your car keys to a valet, you don't also give him power of attorney to sell your house, liquidate your stocks, savings, etc... but every operating system out there does something like that when you tell it to run a program. The program you run can do anything you are authorized to do. The default assumption is that it should have permission to do anything, no matter how stupid, dangerous, or downright evil.

This practice needs to end, about 10 years ago it should have ended... and we'll probably have to wait 10 more years because it's so freaking hard to get this idea across, nobody seems to be ready for it yet, by the way things seem to be going.

A user should be able to decide exactly which and how much of the resources they are authorized to use will be allowed to be accessed by a program they choose to run. If you want to run a program with read/write access to /sandbox, and the ability to read from the internet using a filtered http driver (one that doesn't allow puts, for example), you should be able to do so, without having to do any fancy footwork.

If put in to place, this type of system, which explicitly states what access things get, make it almost trivial to never get a virus or worm ever again. It's time to stop trusting programs, and only have to trust the hardware and OS to enforce our wishes.

I impatiently await the arrival of capability based security.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>