November 23, 2014
Hot Topics:

Secure Design Principles

  • March 23, 2007
  • By Neil Daswani, Christoph Kern, & Anita Kesavan
  • Send Email »
  • More Articles »

Security Features Do Not Imply Security

Using one or more security features in a product does not ensure security. For example, suppose a password is to be sent from a client to the server, and you do not want an attacker to be able to eavesdrop and see the password during transmission. You can take advantage of a security feature (say, encryption) to encrypt the password at the client before sending it to the server. If the attacker eavesdrops, what she will see is encrypted bits. Yet, taking advantage of a security feature, namely encryption, does not ensure that the client/server system is secure, since there are other things that could go wrong. In particular, encrypting the client's password does not ensure protection against weak passwords. The client may choose a password that is too short or easy for the attacker to obtain. Therefore, a system's security is not solely dependent upon the utilization of security features in its design, such as the encryption of passwords, but also depends on how it is used.

Another example involves the interaction between a web client and a web server. You may decide to use SSL. SSL is the Secure Sockets Layer protocol that is used to secure communications between most web browsers and web clients. SSL allows the web client and web server to communicate over an encrypted channel with message integrity in which the client can authenticate the server. (Optionally, the server may also authenticate the client.)

Our SimpleWebServer code can be modified to use an SSL connection instead of a regular one:

import java.security.*;
import javax.net.ssl.*;

// ... some code excluded ...

            private static final int PORT = 443;
            private static SSLServerSocket dServerSocket;

            public SimpleWebServer () throws Exception {
                          SSLServerSocketFactory factory =
                                      (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
                          dServerSocket = (SSLServerSocket)factory.createServerSocket(PORT);

// ... some code excluded ...

            public void run () throws Exception {
                          while (true) {
                                       /* Wait for a connection from a client. */
                                       SSLSocket s = (SSLSocket)dServerSocket.accept();
// ... some code excluded ...

                            }

// ... some code excluded ...
Note
Some additional code is also required for the server to read a public key certificate as well as a "private" key in order for it to authenticate itself to clients that connect to it. The additional code is available from www.learnsecurity.com/ntk.

Now, for a client to connect to the server, it would connect to port 443, execute an SSL "handshake", and start exchanging HTTP messages over an authenticated, encrypted channel with message integrity in place. A browser that wants to connect to the server would use a URL such as https://yourcompany.com. The s in https signifies that an SSL connection on port 443, by default, should be used.

You may decide to take advantage of SSL as a security feature in SimpleWebServer, but using SSL does not ensure security. In fact, using SSL in the preceding code does not protect you from all the other threats (directory traversal attacks, DoS attacks, etc.), even though the client and server might communicate over an SSL connection using this code. Taking advantage of SSL security as a feature may prevent an attacker from being able to snoop on the conversation between the client and server, but it does not necessarily result in overall security, since it does not protect against other possible threats. For instance, if you did not canonicalize the pathname in the HTTP request, an attacker could steal the server's /etc/shadow file over the SSL connection. The security of a system cannot be guaranteed simply by utilizing one or more security features.

So, once you have fixed all the implementation vulnerabilities described earlier in this article and added SSL support to SimpleWebServer, is it finally secure? Probably not.6 There may very well be a few additional vulnerabilities in the code. We leave it as an exercise to the reader (that's you!) to find the extra vulnerabilities.

IS MY CODE SECURE?
In general, you don't really know that any piece of code is actually secure. You either know that it is not secure because you found some security bugs that you have not fixed yet, or it is inconclusive as to whether it is secure. You can say what you have tested for to provide a risk assessment, but that doesn't mean it is 100 percent secure. It turns out that for very small programs, it is sometimes feasible to construct mathematical proofs that the program has certain security properties. But that is mostly of theoretical interest. From a practical standpoint, it is usually impossible to say that a program or software system is secure in any absolute way-it is either insecure or the assessment is inconclusive.

Based on how much testing you have done and what you have tested for, you may be able to provide your management with a risk assessment. Generally, the more testing, and the more diverse the testing, the less risky-but all it takes is some discrete hole and all security is blown.

To quote Bruce Schneier, "Security is a process, not a product" (Schneier 2000). Security results not from using a few security features in the design of a product, but from how that product is implemented, tested, maintained, and used.

In a sense, security is similar to quality. It is often hard to design, build, and ship a product, and then attempt to make it high-quality after the fact. The quality of a product is inherent to how it is designed and built, and is evaluated based on its intended use. Such is the case with security.

The bad news about security is that an attacker may often need to find only one flaw or vulnerability to breach security. The designers of a system have a much harder job-they need to design and build to protect against all possible flaws if security is to be achieved. In addition, designing a secure system encompasses much more than incorporating security features into the system. Security features may be able to protect against specific threats, but if the software has bugs, is unreliable, or does not cover all possible corner cases, then the system may not be secure even if it has a number of security features.

Footnotes

  1. If you wanted to design an even better valet key system for an automobile, you could limit the number of miles that could be driven with the valet key (but that could introduce other safety issues-for instance, if the car would come to a dead stop upon reaching the limit).
  2. There have been known attacks in which attackers take control of the account used to run the web server and then exploit a vulnerability in the operating system to take control of other accounts that have more privileges. However, if there was only a vulnerability in the web server and not an additional one in the operating system, the least privilege approach would prevent the attacker from being able to obtain additional privileges.
  3. A root account is one that gives a system administrator complete access to all aspects of a system.
  4. Note that getCanonicalPath() may not work as expected in the presence of hard links.
  5. If robbers know that they might be given dye-laced cash, this may also serve as a deterrent, or a preventive measure, since the only way to check for dye-laced cash may be to open the briefcase. Why go through the trouble of robbing the bank if they may not be able to get usable cash? At the same time, the dye-laced cash is not a pure recovery measure, since it doesn't help the bank get the money back; it only makes it useless (in the case that real cash is in the briefcase).
  6. Actually, there definitely are additional vulnerabilities in SimpleWebServer-we are just being facetious.

About the Authors

Neil Daswani has served in a variety of research, development, teaching, and managerial roles at Stanford University, DoCoMo USA Labs, Yodlee, and Bellcore (now Telcordia Technologies). His areas of expertise include security, wireless data technology, and peer-to-peer systems. He has published extensively in these areas, frequently gives talks at industry and academic conferences, and has been granted several U.S. patents. He received a Ph.D. and a master's in computer science from Stanford University, and he currently works for Google. He earned a bachelor's in computer science with honors with distinction from Columbia University.

Christoph Kern is an information security engineer at Google and was previously a senior security architect at Yodlee, a provider of technology solutions to the financial services industry. He has extensive experience in performing security design reviews and code audits, designing and developing secure applications, and helping product managers and software engineers effectively mitigate security risks in their software products.

Anita Kesavan is a freelance writer and received her M.F.A. in creative writing from Sarah Lawrence College. She also holds a bachelor's in English from Illinois-Wesleyan University. She specializes in communicating complex technical ideas in simple, easy-to-understand language.

Source of This Material

Foundations of Security: What Every Programmer Needs to Know
By Neil Daswani, Christoph Kern, Anita Kesavan
Published: February, 2007, Paperback: 320 pages
Published by Apress
ISBN: 1590597842
Retail price: $39.99, eBook Price: $20.00
This material is from Chapter 3 of the book.
Reprinted with the publisher's permission.






Page 5 of 5



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel