Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

The cases below are a few examples of source code disclosure that can be caused by passing special characters via request parameters:


Example 1: By appending a space character ("%20"), an application might be forced into disclosing the source for any PHP file.

Example 2: Source code disclosure might also occur from a null character ("%00") appended to a file name in the request URL.

Example 3: Partial encoding of file extensions has been known to disclose the application source code (e.g. "%2ejsp", "%2ejhtml").

Example 4: Certain configurations are prone to source code disclosure issue when the "#" character is used in the extension (e.g. ".#php").

Example 5: Access restrictions implemented by certain web servers based on explicit access to /WEB-INF/ have known to be bypassed by requesting /WEB-INF./.

Example 6: Source code disclosure can occur when the "+" character is appended to the file extension in the request URL (e.g. "jsp+").

Example 7: Including the "%" character in the file name could also result in the disclosure of file source.

If an application or server fails to account for special characters passed with malicious input, severe disclosure issues can occur.

The behavior of functions in this category varies by operating system, and at times, even by operating system version. Implementation differences can include:

- Slight differences in the way parameters are interpreted leading to inconsistent results.

- Some implementations of the function carry significant security risks.

- The function might not be defined on all platforms.

Different operating systems use different characters as file separators. For example, Microsoft Windows systems use "\", while UNIX systems use "/". When applications have to run on different platforms, the use of hardcoded file separators can lead to incorrect execution of application logic and potentially a denial of service.

Example 1: The following code uses a hardcoded file separator to open a file:

...
File file = new File(directoryName + "\\" + fileName);
...

When comparing data that may be locale-dependent, an appropriate locale should be specified.

Example 1: The following example tries to perform validation to determine if user input includes a <script> tag.

  ...
  public String tagProcessor(String tag){
    if (tag.toUpperCase().equals("SCRIPT")){
      return null;
    }
    //does not contain SCRIPT tag, keep processing input
    ...
  }
  ...

The problem with Example 1 is that java.lang.String.toUpperCase() when used without a locale uses the rules of the default locale. Using the Turkish locale "title".toUpperCase() returns "T\u0130TLE", where "\u0130" is the "LATIN CAPITAL LETTER I WITH DOT ABOVE" character. This can lead to unexpected results, such as in Example 1 where this will prevent the word "script" from being caught by this validation, potentially leading to a Cross-Site Scripting vulnerability.

SAP systems are designed to be platform independent. Open SQL, SAP's portable SQL dialect, makes applications independent of a specific database vendor's JDBC driver. Usage of Open SQL abstracts the intricacies of the underlying database, and provides a common interface to application programs for all database operations. However, native SQL is specific to the underlying database and therefore its usage on other platforms may lead to incorrect execution of application logic and potentially a denial of service.
Example 1: The following code uses native SQL:

...
import java.sql.PreparedStatement;
import com.sap.sql.NativeSQLAccess;

String mssOnlyStmt = "...";
// variant 1
  PreparedStatement ps =
  NativeSQLAccess.prepareNativeStatement(
    conn, mssOnlyStmt);
  . . .
// variant 2
  Statement stmt =
  NativeSQLAccess.createNativeStatement(conn);
  int result = stmt.execute(mssOnlyStmt);
  . . .
// variant 3
  CallableStatement cs =
  NativeSQLAccess.prepareNativeCall(
  conn, mssOnlyStmt);
  . . .