Spotting the Sin During Code Review

The easiest way to spot this sin during code review is to hunt down all file I/O functions, especially those that use filenames. When you find such a function, ask yourself the following questions:

• Where does the filename come from? Is it trusted?

• Is this filename being used more than once to access or manipulate the file?

• Is the file in a place on the file system that attackers can potentially access?

• Is there any way for attackers to manipulate the filename to point to a file they shouldnt be able to access?

The following is a list of common file I/O functions or operators to look for in your code.

Language	Key Words to Look For
C/C++ (*nix)	access, chown, chgrp, chmod, link, unlink, mkdir, mknod, mktemp, rmdir, symlink , tempnam, tmpfile , tempnam, unmount , unlink, utime
C/C++ (Windows)	CreateFile, OpenFile
Perl	chmod, chown, truncate, link, lstat , mkdir, rename, rmdir, stat, symlink, unlink, utime
Perl (file test operators)	-r -w -x and so on (see the Other Resources section for a link to the other operators)
C#/.NET	System.IO.File, StreamReader
Java	system.IO, File, FileInputStream

Not all of these functions are going to be security problems in every case. For instance, on modern Unix machines, the most popular functions for creating temporary files usually arent attackable . But, if your code is used in environments that are just a little out of date, there can be issues.