Fortify Path Manipulation Issues

Trant BateySoftware Engineer
A solution for Fortify Path Manipulation.


The reason for this article is to suggest a solution to Fortify Path Manipulation issues.


Many companies, like my own, use a tool called Fortify to analyze their code. Fortify is an HP application that finds memory leaks and security threats. It is likely the most popular and well known tool for these purposes. Companies use it to improve the quality of their code and to prepare for third party audits. There are some Fortify links at the end of the article for your reference.

One of the common issues reported by Fortify is the Path Manipulation issue. The issue is that if you take data from an external source, then an attacker can use that source to manipulate your path. Thus enabling the attacker do delete files or otherwise compromise your system.

Like many other people I found this issue in my code and did a search on the internet for a resolution. The most common proposal was to use the Java class FileSystems in the nio package to process the path. The intention is to obfuscate the fact that the path is coming from an external source. While this sometimes works, it does nothing to address the real issue. 

The Fortify suggested remedy to this problem is to use a white-list of trusted directories as valid inputs and reject everything else. This solution is not always viable in a production environment because you can't always control where the client will be deploying your application. In my company's situation, we can't control where the client keeps their source data. So, we need to support the flexibility of specifying a directory path during execution. In this situation, and list of valid paths will not work.

The Solution

I am putting forward an alternative remedy. 

Allow the user to enter the path and parse the input for a white-list of acceptable characters. Reject from the input, any character you don't want in the path. It could be either removed or replaced. This approach gives you control over what the user can input while still allowing them the flexibility they need to specify their data and configuration.

Below is an example. This does pass the Fortify review. It is important to remember here to return the literal and not the char being checked. Fortify keeps track of the parts that came from the original input. If you use any of the original input, you may still get the error.

Related Links:



Path Manipulation:

public class CleanPath {

    public static String cleanString(String aString) {
        if (aString == null) return null;
        String cleanString = "";
        for (int i = 0; i < aString.length(); ++i) {
            cleanString += cleanChar(aString.charAt(i));
        return cleanString;

    private static char cleanChar(char aChar) {
       // 0 - 9
       for (int i = 48; i < 58; ++i) {
              if (aChar == i) return (char) i;
       // 'A' - 'Z'
       for (int i = 65; i < 91; ++i) {
              if (aChar == i) return (char) i;
       // 'a' - 'z'
       for (int i = 97; i < 123; ++i) {
              if (aChar == i) return (char) i;
       // other valid characters
        switch (aChar) {
            case '/':
                return '/';
            case '.':
                return '.';
            case '-':
                return '-';
            case '_':
                return '_';
            case ' ':
                return ' ';
        return '%';


Comments (1)

Instead of the custom code above, use:

Open in new window

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.