Fortify Path Manipulation Issues

Published on
11,417 Points
Last Modified:
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:

Fortify: https://en.wikipedia.org/wiki/Fortify_Software

HP: https://en.wikipedia.org/wiki/Hewlett-Packard

Path Manipulation: https://stackoverflow.com/questions/12690652/how-to-fix-path-manipulation-vulnerability-in-some-java-code

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 '%';

Author:Trant Batey
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free