Ten Commandments of secure development

Last year I was in a training about web security, according to the report 2008 CSI / FBI in the last 3 years doubled the attack on web applications.

Arnaud my french coworker who did the presentation, plus the commandments taught us the KISS principle.

It’s more difficult to secure complex architectures
It’s more difficult to secure complex code

So, Ten commandments of secure development, take note if you don't like to living in the hell !!!



Input is evil

It’s better to consider that users or external systems that communicate with your application may be someday harmful for your application

E.g.:

-A user that tries to input unexpected data in a form
-A partner’s system, with privileged access to one of your applications, that is compromised by a hacker or worm and tries to attack your network




Minimize Attack Surface

“Complexity is the enemy of IT Security”

The more a program or architecture is complex, the more it will incorporate bugs (incl. security ones) and ways to penetrate it (open network ports, services, accounts, components, etc.)
So, you have to minimize the way to attack an application (it’s the “attack surface”)




Use defense in depth

The whole application security should not be based on only one security measure.

Since applications are often divided in different layers, each layer should have it own security functions.

Example: On UNIX systems, passwords are stored encrypted in /etc/shadow file AND access to this file is restricted (only root has access to it).




Fail securely

When an application crashes, it can become suddenly more vulnerable and provide very interesting information to a hacker

So, all errors must be trapped, detailed error messages must not be sent to the user (on production systems) and a log entry should be safely written at the server side (log file, mail …)






Never depend on Security Through Obscurity

It means that hiding vulnerable components while hoping that hackers won’t find them does not make a system more secure!

Indeed, hackers have automated tools that allow to identify vulnerable components even if they aren’t in common places

However, it’s always better to hide information that do not need to be known by attackers (type and version of an application engine, etc.)



Learn from mistakes

Applications become more and more complex while their development time is lower and lower. It is a source of mistakes.

When a security flaw is identified, it’s important to check that the same kind of problem can’t be found somewhere else in the application

Better is to analyse why the mistake has been done and be sure it won’t happen again in the future







Security feature != Secure feature

Using SSL, encryption, digital signature, etc. don’t necessarily make applications more secure!

E.g. : a very badly written application using SSL won’t be more secure: it will only provide confidentiality to the transmitted data and encrypt attack attempts as well!
So, security has to be thought globally and, only after, implemented using security mechanisms

Security is not a product or a feature, it’s a process


Enforce the Least Privilege Principle

It’s one of the most important security principle

All privilege given to an application or user must be the least possible

Why ?

If an application or component is running under admin rights (root) and a vulnerability allowing remote code execution is identified, a hacker could get the admin rights and control the whole system…


Separate privileges

If high privileges are required for an application to perform a specific task, the corresponding code has to be isolated in a dedicated component running with high privileges, when the remaining components of the application will run under lower rights

Examples
Apache’s parent process is running with admin rights, its children (serving http requests) under “nobody”
Use a different database connection string for administrative functions