Slashdot Mirror
Blame Bad Security on Sloppy Programming
CowboyRobot writes "ACM Queue has an article that blames security flaws on poor programming, rather than any inherent problems with particular languages.
From the article: 'Remember Ada? ... we tried getting everyone to switch to a 'sandboxed' environment with Java in the late 1990s... Java worked so well, Microsoft responded with ActiveX, which bypasses security entirely by making it easy to blame the user for authorizing bad code to execute.'"
The same is especially true in PHP. The short learning curve for getting started in the language allows for a great deal of insecure coding on the internet. I run a site that promotes secure programming, and is running a security challenge for writing scripts as well. The URL is http://www.uberhacker.com
While it's easy to rip on the idea behind ActiveX, Mozilla.org thought it was a good enough idea to copy it as XPI*.
The basic idea is that plugins and toolbars should be easy to install, and due to the nature of these things, they often can not be "sandboxed" or run in a Java VM. One of the big complaints about Mozilla is that people find it difficult to install the Flash/Java/Real plug-ins. If vendors supported XPI, this would be mostly resolved.
The real security problems with IE are not directly related to ActiveX, but instead the holey and flawed "zone" system. There's also some operational annoyances with ActiveX (like throwing up dialogs even though ActiveX is disabled and the lack of an easy way to whitelist), but it sounds like XP SP2 is going to try to fix some of those things.
* ? Apologies if I'm confused about the moz alphabet soup.
Business. Numbers. Money. People. Computer World.
Bugs should not result in security issues.
I repeat: Bugs should not result in security issues!
A properly designed application will have multiple layers of error detection and security checking. As you write your software, abstract things like security checks and database access into an API, and then do insane amounts of input validation behind that API!
In my home turf language, PHP, one of the biggest common problems in applications is the dreaded SQL-Insertion bug.
The pat, standard answer is to validate-validate-validate!
But, I'm human. I *WILL* make mistakes. It's only a question of when, not if.
Ask yourself: How can I structure my application so that mistakes in this regard do not result in an immediate, full compromise?
I bury database access behind an API that forces me to identify the data being passed to the database, and then trap errors from the database so it doesn't show anything to the web client.
Example:
<?
$sql="INSERT INTO logindata (login, password) VALUES ('[login]', '[password]')";
$todb=array('login'=>$login, 'password'=>$password);
if (!$DB->SafeQuery($sql, $todb))
Error($DB->Error());
?>
What happened here? The SQL statement does not contain any data - instead I'm passing a template for the query, and the data array to parse into the query. The function SafeQuery() does a pattern match to get the names of the fields (in the square brackets) and then does the requisite addslashes(), as well as checking the number of fields to ensure that everything matches up, before actually dumping this statement over to the database.
Errors get trapped within the object, and are accessed through function Error(). This prevents any sensitive information being sent to the browser, and the global Error() function simply displays an "Sorry but an error occured" webpage while logging the text of the error message, and quits.
Now, none of this negates the need to do input validation - but this makes a very bad threat for PHP application all but disappear!
As you develop your applications, structure them as much as possible such that bugs and errors do not result in security breaches.
Use constraints and triggers in your databases to kick out data that can't be demonstrated as good. Use APIs and functions to interface with areas (such as the shell/CGI interface) so that common security mistakes (such as not escaping a shell argument) simply can't happen.
Repeat after me: Bugs should not result in security issues!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The first image conjured up by "sloppy" is someone using sprintf in production code (much buffer overrun potential), raw pointers unnecessarily, ad-hoc string manipulation code, and so on. But it's much deeper than that.
Consider something as simple as BMP file format decoder. Writing a decoder is easy. It takes about 30 minutes tops to write one for a subset of the format. But writing a safe version is much more difficult. First, you have to validate all fields. Easy enough. Then you have to handle attempts to crash an application by passing in really huge values, like 10,000,000 pixels in each dimension. That's a bit trickier, because you have to figure out what you should allow and what you shouldn't. Then you have to deal with intentionally malformed images, where the RLE information doesn't add up to the total image size. Depending on how the code is written, this can cause you to chew through memory past the end of the image. To fix this, you have to put some checks into your inner decoding loop. The temptation to avoid doing this is strong, especially among "performance" oriented coders.
So, yes, you can blame this on poorly written code. But had this been written in a checked language, like Lisp or Python or any similarly safe language, then some of the problems go away immediately. Not all of them but some.
Uh, not quite. ActiveX was more a response to JavaScript/Flash/et al. Anything that created a lightweight web app.
.NET is their response to Java (and, for all intents and purposes, .NET is miles ahead of anything MS has ever created in terms of security). .Net is what MS developed when they decided not to support Java client-side. Its pretty good in terms of security, but still has weaknesses when compared to Java.
Uh, yes quite! ActiveX was exactly and precisely a response to Java - Java Applets that is. The idea was to run embedded binaries in a web browser. ActiveX components would run only on Windows, so they could use the Windows APIs, and so not require a plug-in or pre-installed VM, like Java Applet. ActiveX 'security' was by digital authentication, as against Java's sandbox. ActiveX is not related at all to client-side scripting, as with JavaScript. Microsoft's response to JavaScript was - to support JavaScript.
Actually, you can continue to use C/C++ and just use a garbage collector with them. I don't know why more people don't do this. You don't even need to change your code, as Boehm's garbage collector translates malloc() to it's own allocation routine, and free() does nothing.
In fact, even better, if you have Boehm GC installed anywhere on your system you can do this for already compiled programs using LD_PRELOAD.
Just do:
export LD_PRELOAD=/path/to/libgc.so
/path/to/program
and I'm automagically using a garbage-collected runtime for the program, even if it was compiled to use the standard malloc()/free() calls.
Engineering and the Ultimate