Secure by design

From Wikipedia, the free encyclopedia

Secure by design, in software engineering, means that the program in question has been designed from the ground up to be secure. Often this involves being fully fault tolerant. If, for instance, a user has to type his name, and that name is then used elsewhere in the program, care must be taken that when a user enters a blank name, the program does not break.

The key idea of "security by design" is design. Many computer systems today are what one might call "secure by accident" — they are the results of years of testing and debugging, and while they may provide a great deal of security, they typically have no way to guarantee that a new bug or exploit won't be revealed tomorrow (see zero-day exploit).

Generally, designs that work well do not rely on being secret. It is not mandatory, but good security usually means that everyone is allowed to know and understand the design, because it is secure. If a design is insecure, it is often kept secret to "protect" its users (and designers!). Conversely, if a design is kept secret, then it may be insecure without anyone's realizing it. (See Linus's law.)

Also, it is very important that everything work with the least privilege possible. A Web server that runs as the administrative user (root or admin) can have the ability to remove files and users that do not belong to itself. Thus, a flaw in that program could put the entire system at risk. On the other hand, a Web server that runs inside a virtual private server and only has the privileges for required network and filesystem functions cannot compromise the system it runs on unless the security around it (the "sandbox") is also flawed.

To summarize: a system which is "secure by design" has been designed to make it difficult to abuse or misuse.

[edit] Security by design in practice

Many things, especially input, should be distrusted by a secure design. (A fault-tolerant program could even distrust its own calculations!)

Two classic examples of insecure design are use of the C programming language's gets routine and the format string vulnerability. The following C program demonstrates both flaws:

#include <stdio.h>

int main()
{
    char buffer[100];
    printf("What is your name?\n");
    gets(buffer);
    printf("Hello, ");
    printf(buffer);
    printf("!\n");
    return 0;
}

The first flaw in this program is that the user can cause a buffer overflow by typing more than 99 characters at the prompt, because the gets function does not stop writing bytes into buffer until the user types a newline. (The programmer may have assumed that no normal user would have a name longer than 99 characters, and this is a reasonable assumption — but the programmer did not account for the possibility of a malicious user whose goal is to make the program crash or exhibit abnormal behavior.)

The second flaw, which exposes the program to a format string attack, is that the program tries to print its input by passing it directly to printf. The printf function prints out its first argument, replacing instances of "%s", "%d", et cetera, with its other arguments as needed. Thus, if a malicious user entered "%d" instead of his name, the program would attempt to print out a non-existent integer value, and undefined behavior would result.

A related mistake in Web programming is for an online script not to validate its parameters. For example, consider a script that fetches an article by taking a filename, which is then read by the script and parsed. Such a script might use the following hypothetical URL to retrieve an article about dog food:

http://www.example.net/cgi-bin/article.sh?name=dogfood.html

If the script has no input checking, instead trusting that the filename is always valid, an attacker could forge an URL to retrieve configuration files from the webserver:

http://www.example.net/cgi-bin/article.sh?name=../../../../../etc/passwd

Depending on the script, this may expose the /etc/passwd file, which on Unix-like systems contains (among others) user IDs, their login names, home directory paths and shells. (See SQL injection for a similar attack.)