Insecurity By Design


Kevin Kernan posts on C|Net that “the best long-term answer to the security problem is to make software intrinsically more secure.”  Read that article here.


He goes on to discuss the inability of developers and security professionals to even talk about security effectively, and makes the point that instead of investing in all the security software that tries to protect the application software after its built, we should design in security from the start. 


Security should definitely be part of the design process of software. However, this only goes so far. The simple security issues (buffer overruns, etc) are easy to educate programmers about, easy to build tools to detect and should one day become extinct. Most developers know about these kinds of vulnerabilities already and strive to avoid them. Yet, still they persist. Getting it right is difficult and is not fool proof.

The real problem lies in the subtle vulnerabilities. Ones we don’t know about yet, are difficult to recognize due to their complexity, or come about due to a combination of minor flaws that together add to trouble. These are hard to spot both by tools and human eyes.

SQL injection is a big problem. Even when educated to avoid it by validating input many programs still exhibit flaws due to weaknesses in their validating logic. Is this really an intractable problem? Are the developers just prone to never get it right?

Couldn’t we solve the problem better by re-designing the data API’s instead of putting the burden on the multitudes of developers with varying degrees of security smarts? The data API’s are not flawed, they just don’t protect you from this attack.

What if they did?

Comments (2)

  1. Travis Owens says:

    SQL injection can be reduced by moving to Stored Procedures but to truly fix the problem Microsoft must work on a multilevel format.

    Meaning the application runs at a different permission level than the user, which is also different from the system. (Yes I know IE7 is addressing this to a degree.)

    While I’m no expert on the matter I would think an enviroment where the application’s memory space and network connections are private. This means local apps cannot read or write onto this space. Local packet sniffers could not get privy to the data being sent across the line nor could they inject data into this stream. Of course this also means the user doesn’t have this access either. Unforutently this also closes the door for many types of functionality but no matter how well you balance it, ultimately security and flexibility are inversely related. At some point you have to restrict features (direct or indirect) to make something more secure.

    Most importantly, the fact that a default account in Windows has root (administrator) by default is a fundamental flaw in Windows and I would blame it on the majority of viruses, trojans and spyware. If default user permissions were limited, and a sandboxed enviroment that still allowed a place for that user to install apps & make changes specific to their account was the way, it would have been much harder for things to go wrong.

  2. jonnosan says:

    my suggestion on helping prevent sql injection – apply something like perl’s taint mode to strings that get passed in to Command.Execute* – any string made by concatenating other strings is unsafe and should be rejected.

    i.e.:

    public Customer void GetCustomerById (string customerId ) {

    //string concatenation makes query ‘tainted’

    String query = "SELECT * FROM Customers WHERE CustomerId=’"+customerId+"’";

    // thos should throw exception cause executereader got passed in a ‘tainted’ string

    SqlDataReader reader = cmd.ExecuteReader ( );

    }