Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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.'"

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]

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.

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.

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?

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 adm

Yes, PICK os/db. Today it functions within *nix as a virtualized/emulated database/os with a network connectivity layer to allow communication. This is the implementation I've used(there are others, by varying cos). Doing comparative tests, the speed of it as a querying system is ridiculously fast compared to SQL, primarily due to the superior file system(which also acts as the db hierarchy) that allows for very fast location of data

You don't even have to use a different query language. Let's say you have a Web frontend to a database that lets people enter search terms. An obvious avenue for SQL injection, right? Not if you run it with a user that has only permission to SELECT, and not to INSERT or DELETE or anything else.

Some of these things are really not hard to address, just seems a lot of Web developers are pathologically lazy.

Oh, I understand. Read only users are necessary for all sql implementations that have that kind of connectivity. The problem I have is more implementation based. It's a major security issue to allow a querying language to allow updates/inserts/deletes in general. A better system would be to have separate implementations for both(the one I'm most experienced with uses compiled code for updates/inserts/deletes and the query language is read only by design. thus there is no room for injection of any kind, e

Except what essentially amounts to denial of service is much different than the typical sql injection. The biggest problem with sql injection is the fact that it lets you alter the database, not that you can hammer the server with a select statement. True, both are security issues, but one is greater than the other

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

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.

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.

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.

Parameters are still better because they can support data-types that can't be passed in as a string. Also, the SQL engine is actually more efficient when using parameters as the SQL command and the parameters are sent via separate data streams. This also means you can't "accidentally" mess up your sanitization as it is not even required.

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

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 progr

Bull. 2 out of those three examples make it easy to do the right thing.

Perl has DBI, which does parametrised queries very well, and in fact makes quoting a pain, because all the nice functions like binding variables to query results do not work well (if at all) with quoted queries. And if DBI is too low-level, there is always the DBIx::Class ORM.

Python's DB-API 2.0 is the standard to do databases in Python, and it too makes parametrised queries a lot simpler than quoting. And on top of that you can use SQLAlchemy.

I agree with PHP being bad. Sure it has parametrised query support in various libraries, but the default is still to use MySQL as backend and use the various mysql_yes_really_quote_it_correctly_this_time() functions. Given that until recently even the maintainers of the language didn't have clue as to how to do security right, PHP is by far the most unsuitable language to do secure web programming in.

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.

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.

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

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.

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

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.

Another type of mistake or error that should be considered is the attempt to program or write code for something at all. I remember watching a lecture about this topic at some point and I cannot find the link anymore. The general message was that no programs are bug-free, and in some circumstances it's unethical to even attempt to program for certain devices because undetected coding errors could end up killing many people. An example would be an automated missile defense system in which someone out there h

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

Only 3 of the 25 deal with missing requirements or design. The rest are implementation details. Sure, you can make a design that makes writing code vulnerable to SQL injection more difficult, but it's still something the programmer has to watch out for. Also, I expect programmers to bring up glaring omissions in the requirements or design, just like I would hope a worker on a car manufacturing floor would bring issues to the attention of engineering. They are on the front lines and see things designers

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?

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.

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.

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 profe

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.

Actually, this is done some of the time under Linux, it's called AppArmor.

Getting capabilities fully integrated into Linux, in a user friendly format, should be feasible, if there were a community that wanted to make it happen, and we could get Linus to go along with it. The whole SE/Linux and security plugin infrastructure gets us part way there.

There's no need to re-write apps, it's just a matter of a few more errors if the app tries to do something forbidden.

Even Windows could support it, with current apps, but then Microsoft wouldn't be able to use it to push Office 2020.

Ahem. Windows does support "capabilities". They are called privileges in Windows. Unlike in Linux/Unix where you need to elevate to the all-powerful root, Windows actually allows delegation of privileges, such as shutting down/restarting, back up, change system time, change timezone etc.

There was actually a push to create a POSIX standard for "capabilities". Unfortunately it was abandoned/retracted. Still, Linux does actually support a number of "Linux Capabilities" - but they are woefully underused. Theore

It is unfortunate that it's necessary to try to overload an existing term with a new, slightly different definition, but that's what has happened here.

Capabilities in a capability based system (cabsec for short) are fine grained access rights to things like single files, a directory, etc. They are explicitly granted at run time to a process, they are not persistent.

This is in contrast to the Access Control List permissions of VAX/VMS, inherited by Windows, and the User/Group/World permissons of Unix/Linux, both of which are geared towards restricting the rights of a user, and are generally persistent.

For example, if you give a process write access to a log file, and I/O access to the internet, and 1% of total cpu use....it could watch something on the net, and log the results. It could not access anything other than the log file, no matter what... this means a buffer overflow bug, or any other fault could not cause data to leak from the system.

In a permissions/ACL based system, the administrator decides the rights of users, and the programs they run, without distinction

With cabsec capabilities, the user decides which of their rights they wish to delegate to a process or program. This frees the user from the need to trust a given program with all of their rights. This also frees the system administrator from having to set up extra accounts with limited permission for each new service or daemon that needs to be run.

I see cabsec as a very useful extension to the existing user permissions systems. Combined you get the best of both worlds.

In UNIX operating systems it's common practice to use separate user accounts for daemons and to not run anything as root. Isn't that enough to do what is being asked? In addition, we've PAM, SELinux, PaX, and more that's capable of locking down the system beyond filesystem permissions and user accounts.

These systems probably aren't configured by home users at all, but it's practically mandatory in enterprise.

Parent is completely right. Windows registry is one of the biggest examples of this problem, but even on Linux any program can modify nearly any other file of any other program the user has access to.

What? The Windows registry is securable per key - as in each key has its own (but usually inherited from its container) ACL. To have the equivalent in Linux where most configuration is kept in text files you would have to be able to assign an ACL to each line of the file. The Windows registry also supports mandatory integrity control (MIC) which does not allow a lower-integrity process to write to a higher-integrity key even if the user account it runs under formally has write-permission.

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, fulfi

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?

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

You left out some details about bounds checking that deserve some notice:

According the the C++ Standard, std::vector::operator[] does not do bounds checking -- if you want an exception to be thrown, use std::vector::at(). As an aside, I which they would have switched which one does checking and which one doesn't, but it is the way it is.

Visual C++ has an extension to do bounds checking on operator[]. Compile with _SECURE_SCL 1 [microsoft.com], which is the default. When an access goes out of bounds, the program will ter

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.

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.

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

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.

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.

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