You never have enough time to do Code Review if you try to walk trough every functions, instead, we can focus on the “high risk” functions that hackers have been known to take advantage of Web application.
The common potential problem areas are:
1. User input;
2. The third party input that from other untrusted sources, such as external database;
3. The output. For example, the error message may reveal too much information, or a poorly coded application may insert tainted SQL data into a database, which your application would be potentially use it.
Here is the list of “high risk” functions (copy from a PDF file and some websites, I also added some):
1. Buffer overflow
When a particular function/operation writes more data into a variable than the variable was designed to hold, the result is buffer overflow. Fortunately, this only occurs on the languages that must predeclare their variable storage size, such as C and C++. ASP, Perl, and Python all have dynamic variable allocation, which means they can interpreter themselves handle the variable size.
For C/C++, the “high risk” functions are:
(1) str* family: strcpy(), strcat(), strcadd(), strccpy(), streadd(), strecpy(), strtrns(). We should avoid to use these functions
(2) strn* family: strncpy(), strncat(), and so on. This is a safer alternative to the str* family. The strn* family is essentially the same as the str* family except it allow you to specify a maximum length. So we only need to make sure that the specified maximum value is equal or less than the destination variable size.
(3) memcpy(), bcopy(), memccpy(), memmove().
(4) sprintf(), snprintf(), vsprintf(), vsnprintf(), swprintf(), vswprintf().
(5) gets(), fgets().
(6) getc(), fgetc(), getchar(), read().
2. Cross-Site Scripting (XSS)
XSS is in fact a subset of HTML injection. It allows attackers to execute the script in the victim’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing etc.
Looking for XSS vulnerabilities is tough; the best place to start is with the common output functions used by the language:
(1) C/C++: printf(), fprintf(), output streams, and so on.
(2) Java: Don’t use
(3) .NET: the better way is to use the Microsoft Anti-XSS Library freely available from MSDN.
(4) ASP: Response.Write, Response.BinaryWrite,
(5) Perl: print, printf, syswrite.
(6) PHP: print, printf, echo.
3. Information Disclosure
This is not a technical problem, it is quite possible that the application may provide some information that can be used by attackers. For example, developer may insert some output for debug purpose and forget to delete it.
We need to review all the output functions of the language with:
(1) Printing sensitive information (passwords, credit card numbers) in full display.
(2) Displaying application configuration, server configuration information, environment variables, and so on.
(3) Revealing too much information in error message. For example, failed database connections typically spit out connection details that include database host address, authentication details and target tables; failed file inclusion may disclose file paths, which allows attackers to determine the layout of application.
(4) Avoiding the use of public debugging mechanisms in production applications. The better way is to write debugging information to a log on the application server.
4. File system access/interaction
We need to check where, when and how a web application accesses the local file system on the server, the danger lies in using filenames that may contain tainted data.
(1) C/C++: open(), fopen(), create(), mknod(), catopen(), dbm_open(), opendir(), unlink(), link(), chmod(), stat(), lstat(), mkdir(), readlink(), rename(), rmdir(), symlink(), chdir(), chroot(), utime(), truncate(), glob().
(2) ASP: Server.CreateObject() that create Scripting.FileSystemObject objects.
(3) Perl: chmod, chown, link, lstat, mkdir, readlink, rename, rmdir, stat, symlink, truncate, unlink, utime, chdir, chroot, dbmopen, open, sysopen, opendir, glob.
(4) PHP: opendir(), chdir(), dir(), chgrp(), chmod(), chown(), copy(), file(), fopen(), get_meta_tags(), link(), mkdir(), readfile(), rename(), rmdir(), symlink(), unlink(), gafile(), gzopen(), readgz-file(), fdf_add_template(), fdf_open(), fdf_save().
(5) Java: java.io.*, java.util.zip.*, java.util.jar
(6) JSP: < %@include file=’filename’% >
(7) ColdFusion: CFFile, CFInclude tags.
5. Calling External Programs
Calling external programs is danger, if tainted user data is included within the call, an attacker could trick the command processor into executing additional commands, or changing the intended command.
(1) C/C++: exec* family, exec(), execv(), execve(), and so on.
(2) Perl: exec,’’(backticks), qx//, and <> (the globbing function).
(3) PHP: fopen(), popen(), exec(), passthru(), system().
(4) Python: os.exec* family, os.exec, os.execve, os.execle, os.execlp, os.execvp, os.execvpe, os.popen, os.system.
(5) Java: Runtime.exec().
(6) ColdFustion: CFExecute, CFServlet tags.
6. Dynamic code execution
Some languages contain mechanisms to interpret and run native scripting code, the advantage is that allows the program to “build” a subprogram dynamically, and user can input fragment script code. However, it opens a door to the attacker who may insert his own script code to be compiled and executed.
(1) Perl: eval function, do, and any regex operation with the e modifier.
(2) Python: exec, compile, eval, execfile, input.
(3) ASP: Eval, Execute, ExecuteGlobal.
7. External objects/Libraries
Including or loading libraries is helpful in making the design of a program easier. However, you need to make sure that all external library loading routines do not user any sort of tainted data, an attacker could coerce your program into loading an alternate library, which could provide him an advantage.
(1) Perl: import, require, use, do.
(2) Python: import, _import_.
(3) ASP: Server.CreateObject(),
