Path Manipulation: Zip Entry Overwrite errors occur when a Zip file is opened and expanded without checking the file path of the Zip entry.

Example 1: The following example extracts files from a Zip file and insecurely writes them to disk.

  private static final int BUFSIZE = 512;
  private static final int TOOBIG = 0x640000;
  ...
  public final void unzip(String filename) throws IOException {
    FileInputStream fis = new FileInputStream(filename);
    ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
    ZipEntry zipEntry = null;

    int numOfEntries = 0;
    long total = 0;

    try {
      while ((zipEntry = zis.getNextEntry()) != null) {
        byte data[] = new byte[BUFSIZE];
        int count = 0;
        String outFileName = zipEntry.getName();
        if (zipEntry.isDirectory()){
          new File(outFileName).mkdir(); //create the new directory
          continue;
        }
        FileOutputStream outFile = new FileOutputStream(outFileName);
        BufferedOutputStream dest = new BufferedOutputStream(outFile, BUFSIZE);
        //read data from Zip, but do not read huge entries
        while (total + BUFSIZE <= TOOBIG && (count = zis.read(data, 0, BUFSIZE)) != -1) {
          dest.write(data, 0, count);
          total += count;
        }
        ...
      }
    } finally{
      zis.close();
    }
  }
  ...

In Example 1, there is no validation of zipEntry.getName() prior to performing read/write functions on the data within this entry. If the Zip file was originally placed in the directory "/tmp/" of a Unix-based machine, a Zip entry was "../etc/hosts", and the application was run under the necessary permissions, it would overwrite the system hosts file. This in turn would allow traffic from the machine to go anywhere the attacker wants, such as back to the attacker's machine.

Privacy violations occur when:

1. Private user information enters the program.

2. The data is written to an external location, such as the console, file system, or network.
Example 1: The following code contains a logging statement that tracks the records added to a database by storing the contents in a log file.

pass = getPassword();
...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

The code in Example 1 logs a plain text password to the file system. Although many developers trust the file system as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.

Privacy is one of the biggest concerns in the mobile world for a couple of reasons. One of them is a much higher chance of device loss. The other has to do with inter-process communication between mobile applications. With mobile platforms, applications are downloaded from various sources and are run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which is why application authors need to be careful about what information they include in messages addressed to other applications running on the device. Sensitive information should never be part of inter-process communication between mobile applications.

Example 2: The following code reads username and password for a given site from an Android WebView store and broadcasts them to all the registered receivers.

...
webview.setWebViewClient(new WebViewClient() {
  public void onReceivedHttpAuthRequest(WebView view,
        HttpAuthHandler handler, String host, String realm) {
    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);
    String username = credentials[0];
    String password = credentials[1];
    Intent i = new Intent();
    i.setAction("SEND_CREDENTIALS");
    i.putExtra("username", username);
    i.putExtra("password", password);
    view.getContext().sendBroadcast(i);
  }
});
...

This example demonstrates several problems. First of all, by default, WebView credentials are stored in plain text and are not hashed. If a user has a rooted device (or uses an emulator), they can read stored passwords for given sites. Second, plain text credentials are broadcast to all the registered receivers, which means that any receiver registered to listen to intents with the SEND_CREDENTIALS action will receive the message. The broadcast is not even protected with a permission to limit the number of recipients, although in this case we do not recommend using permissions as a fix.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information

- Accessed from a database or other data store by the application

- Indirectly from a partner or other third party

Typically, in the context of the mobile environment, this private information includes (along with passwords, SSNs, and other general personal information):

- Location

- Cell phone number

- Serial numbers and device IDs

- Network Operator information

- Voicemail information


Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Permission manipulation errors occur when an attacker is able to modify a value used in determining permissions within an application.

Example 1: The following code uses input from a file to determine the FileIOPermissions required in the application.

...
String permissionsXml = GetPermissionsFromXmlFile();
FileIOPermission perm = new FileIOPermission(PermissionState.None);
perm.FromXml(permissionsXml);
perm.Demand();
...

In this scenario, if the user is able to control the XML file used to retrieve the data, they control what permissions may be demanded by the system.

Permission manipulation logging errors occur when an attacker is able to modify a value used in determining permissions within an application that are used to determine what is logged. In Windows there are System Access Control Lists (SACLs) that are used to determine users and groups that should be audited to see if access is successful or fails against resources. If the Access Control Entries (ACEs) stored within these or access settings can be controlled by an attacker, the attacker has the potential to disable auditing of their account, thus making it harder to determine what an attacker may have done in a breach.

Example 1: The following code lets a user specify which operations to generate an audit log.

...
CrytoKeyAuditRule auditRule = new CryptoKeyAuditRule(IdRef, (CryptoKeyRights) input, AuditFlags.Success); 
...

In this scenario, if the user can control input then they can specify what type of operation can be logged. If the user can manipulate this to CryptoKeyRights.Delete, then they may be able to read the encryption key without it being logged, making you unaware that an attacker has stolen your encryption keys.

When enabled, the allow_url_fopen option allows PHP functions that accept a filename to operate on remote files using an HTTP or FTP URL. The option, which was introduced in PHP 4.0.4 and is enabled by default, is dangerous because it can allow attackers to introduce malicious content into an application. At best, operating on remote files leaves the application susceptible to attackers who alter the remote file to include malicious content. At worst, if attackers can control a URL that the application operates on, then they can inject arbitrary malicious content into the application by supplying a URL to a remote server.

Example 1: The following code opens a file whose name is controlled by a request parameter and reads its contents. Because the value of $file is controlled by a request parameter, an attacker could violate the programmer's assumptions by providing a URL to a remote file.

<?php
$file = fopen ($_GET["file"], "r");
if (!$file) {
    // handle errors
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    // operate on file content
}
fclose($file);
?>

When enabled, the allow_url_include option allows PHP functions that specify a file for inclusion in the current page, such as include() and require(), to accept an HTTP or FTP URL to a remote file. The option, which was introduced in PHP 5.2.0 and is disabled by default, is dangerous because it can allow attackers to introduce malicious content into an application. At best, including remote files leaves the application susceptible to attackers who alter the remote file to include malicious content. At worst, if attackers can control a URL that the application uses to specify the remote file to include, then they can inject arbitrary malicious content into the application by supplying a URL to a remote server.

If the PHP interpreter is installed as a CGI binary then requests for PHP resources are typically redirected by the Web server to the interpreter. In this situation, when a user requests http://www.example.com/content/page.php, the server first performs the necessary access control checks on the directory /content, then redirects control to the PHP interpreter with a request to http://www.example.com/cgi-bin/php/content/page.php.

If cgi.force_redirect, which is enabled by default, is disabled, then attackers with access to /cgi-bin/php can use the permissions of the PHP interpreter to access arbitrary Web documents, thus bypassing any access control checks that would have been performed by the server.

The enable_dl configuration allows dynamic loading of libraries. These could potentially allow an attacker to circumvent the restrictions set with the open_basedir configuration, and potentially allow access to any file on the system.

Enabling enable_dl can make it easier for attackers to exploit other vulnerabilities.

When enabled, the file_uploads option allows PHP users to upload arbitrary files to the server. Permitting users to upload files does not represent a security vulnerability itself. However, this capability can enable a variety attacks because it gives malicious users an avenue to introduce data into the server environment.

Regardless of the language a program is written in, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the PHP interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the Web root. Attackers may upload malicious PHP source files to this program and subsequently request them from the server, which will cause them to be executed by the PHP interpreter.

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. If no directories are specified using the open_basedir option, then programs running under PHP are given full access to arbitrary files on the local file system, which can allow attackers to read, write or create files that they should not be able to access.

Failing to specify a restrictive set of directories with open_basedir can make it easier for attackers to exploit other vulnerabilities.

Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this race condition can allow attackers to replace a symlink to a file that passes an access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

When safe_mode is enabled, the safe_mode_exec_dir option restricts PHP to executing commands from only the specified directories. Although the absence of a safe_mode_exec_dir entry does not represent a security vulnerability itself, this added leniency can be exploited by attackers in conjunction with other vulnerabilities to make exploits more dangerous.

When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. If the working directory is specified with ., this can potentially be changed by an attacker by using chdir().

Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this race condition can allow attackers to replace a symlink to a file that passes an access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

When enabled, the register_globals option causes PHP to register all EGPCS (Environment, GET, POST, Cookie, and Server) variables globally, where they can be accessed in any scope in any PHP program. This option encourages programmers to write programs that are more-or-less unaware of the origin of values they rely on, which can lead to unexpected behavior in benign environments and leaves the door open to attackers in malicious environments. In recognition the dangerous security implications of register_globals, the option was disabled by default in PHP 4.2.0 and was deprecated and removed in PHP 6.

Example 1: The following code is vulnerable to cross-site scripting. The programmer assumes the value of $username originates from the server-controlled session, but an attacker may supply a malicious value for $username as a request parameter instead. With register_globals enabled, this code will include a malicious value submitted by an attacker in the dynamic HTML content it generates.

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

The safe_mode option is one of the most important security features in PHP. When safe_mode is disabled, PHP operates on files with the permissions of the user that invoked it, which is often a privileged user. Although configuring PHP with safe_mode disabled does not introduce a security vulnerability itself, this added leniency can be exploited by attackers in conjunction with other vulnerabilities to make exploits more dangerous.

When enabled, the session.use_trans_sid causes PHP to pass the session ID on the URL, which makes it much easier for attackers to hijack active sessions or trick users into using an existing session already under the attackers' control.

Parameters passed on the URL are more visible than POST parameters and cookie values because they often appear in browser histories, bookmarks, log files, and other highly exposed locations. If attackers learn the secret session identifier for an active session on a system, then they could possibly supply the session identifier back to the program in order to hijack the user's session.

Beyond session hijacking, exposing the session ID on the URL also facilitates session fixation attacks. In the canonical exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using that session identifier, giving the attacker access to the user's account through the active session. Passing the session identifier on the URL allows attackers to reach a large number of potential victims by sending URLs that include a compromised session identifier to victims via email or another mass communication mechanism.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores a condition, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores an error condition that might happen during a CICS transaction.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

If a transaction were to ever fail with this error condition, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

A ColdFusion application might inadvertently display detailed error messages to the user. These error messages might contain sensitive information that can enable an attacker to conduct more targeted or damaging attacks.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from doExchange().

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code ignores several exceptions that could be thrown while executing the insert statement.

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

An exception could be thrown because the table does not exist, a required value is not provided, or some other reason. If a failure occurs, there is no way to tell because the procedure will not report the failure or record what type of failure has occurred.

Multiple catch blocks can get repetitive, but "condensing" catch blocks by catching a high-level class such as Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

Example 1: The following code excerpt handles three types of exceptions in an identical fashion.

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.