Software Development Guide: Testing for Security Holes

This document is a draft. I encourage you to submit your suggestions.

• Unescaped malicious user input

  • escaping sql in input

    If the user enters '; drop table foo, you must escape the single-quote before passing this to the database as a string. You may also want to escape % and _ when you use the LIKE keyword whereever you want to allow explicit %'s and _'s (or want to disallow user-defined wildcards).

  • escaping html in output

    If the user enters <blink> into some output that you're going to display to a webpage, you must turn the square-brackets into their html equilvalent to prevent an XSS attack.

  • escaping xml

    Same as html. You should also escape the character &.

  • escaping shell commands

    Your program shouldn't invoke a shell on any text a user entered, but if it does for some reason, you need to escape many dangerous shell characters. For example, you don't want the user to be able to type ; rm -Rf / and have that command actually get run.

• Invoking The Shell

  If you must invoke a shell from a program, make sure all paths are specified explicitly. If they aren't, the user can change his path to execute his own version of the programs your code tries to execute. For example, if your code says:

    system("cp /x /y");
  

  The user could run this command at his shell:

    export PATH=.:$PATH
  

  This would cause your program to run the user's copy of cp (if it exists in the current directory) with the privileges of the your program.

• Temporary Files

  If you write to temporary files with predictable names in a world-writable location like /tmp, a malicious user can create a symlink in the place where you will write your file, thus causing you to write the data to the location of his choosing. (This might be used to overwrite an important system file, for example.)

• Bugs in variable use

  • Buffer overflows

    Avoid reading user data into character arrays (e.g. in c). It's safer to use a c++ string, since, when used correctly, it can't be buffer-overflowed (though you can generate an exception by overflowing it -- you should catch that exception).

• Tickets and Session Tokens

  Are you using tickets and/or session tokens to save state? These are a frequent source of security vulnerabilities

  • Misuse of tokens

    How do you get a token? Did you need to enter your password? If you get a token before you enter a password, then you must not assume that anyone with a token has authenticated. (The webcreate hack)

  • Token quality

    Are tokens sufficiently long and random that an attacker can't brute-force a token or detect a pattern in its assignment?

  • Are you storing secret information in a web browser cookie that can be retrieved by a malicious website?
  • Man-in-the-middle

    Can an attacker trick the user into handing it a token (through a redirect, say) and use that token to perform malicious activity?

• Handling User Passwords

  • Why are you handling passwords?
  • Do you ever output the password to the screen?
  • If you dump core, will the passwords sit around in the core file forever?

• Passwords Your Program Needs to Run

  • Try to avoid using a password in favor of a kerberos ticket or keytab or other more secure, harder-to-remember tokens.
  • If you must use a password (say, to connect to oracle), store it in a configuration file, not in the code
  • Do not store vital passwords or keytabs on the filers or other nfs-mounted partitions (/etc is a better place). nfs is inherently insecure (your files are sent around the network unencrypted). This not to mention that many nfs restrictions are ip-based, so if someone can steal an appropriate ip address, he can read all the files on the volume.
  • If you're storing passwords only in /etc, make sure there's documentation on how to create a new password/key file in case the old one is lost. The passwords necessarily should not be in the /src tree, so if disks that contained them get wiped, there should be no more copies lying around. But as long as people understand how to set a new password and regenerate the file, this will be only a minimal nuisance.

• Encryption

  Does the data being passed around need to be encrypted? Is it?