Our website uses cookies to enhance your browsing experience.
Accept
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
Message submitted.

Your message has been sent. We will email you at


If you do not see the email in your inbox, please check if it is filtered to one of the following folders:

  • Promotion
  • Updates
  • Spam

Webinar: Evaluation - 05.12

>
>
>
V5609. OWASP. Possible path traversal v…
menu mobile close menu
Analyzer diagnostics
General Analysis (C++)
General Analysis (C#)
General Analysis (Java)
Micro-Optimizations (C++)
Diagnosis of 64-bit errors (Viva64, C++)
Customer specific requests (C++)
MISRA errors
AUTOSAR errors
OWASP errors (C++)
OWASP errors (C#)
Problems related to code analyzer
Additional information
toggle menu Contents

V5609. OWASP. Possible path traversal vulnerability. Potentially tainted data is used as a path.

Jun 15 2021

The analyzer detected external data used as paths to files or directories without a prior check. This way, the application may become vulnerable to path traversal attacks.

Attacks of this type are in a separate risk category in OWASP Top 10 Application Security Risks 2017: A5:2017-Broken Access Control.

Consider an example:

HttpResponse response;
HttpRequest request;

private void SendUserFileContent(string userDirectory)
{
  ....
  string userFileRelativePath = request.QueryString["relativePath"];
  string fullPath = Path.Combine(userDirectory,
                                 userFileRelativePath);
  var content = File.ReadAllText(fullPath);
  
  ....

  response.Write(content);
}

This method sends a file content from a specified user's folder. The user must have access only to the contents of files inside this repository.

As a relative path, it uses a value from an external source—'Request.QueryString'. An attacker can access the contents of any files in the system as there are no checks.

For example, each user's folder may store the userInfo.xml file, that contains different information, which may be sensitive. At the same time, the code runs on Windows. How does an attacker get access to data of the user 'admin'? It only takes to pass the following string to 'Request. QueryString["relativePath"]':

..\admin\userInfo.xml

To protect against such an attack, a simple check for '..\' at the beginning of the string is not enough. For example, a string as follows can be passed to get the same data:

someFolder\..\..\admin\userInfo.xml

Another opportunity for attack is to pass an absolute path instead of a relative one. If one of the 'Path.Combine' arguments is an absolute path, then all previously written arguments are ignored. For example, the method can be called as follows:

Path.Combine("folder", "childFolder", "C:\Users\Admin\secret.txt")

The returned string - 'C:\Users\Admin\secret.txt'. Thus, the lack of input data check allows an attacker to access any file on the system. Follow the link to the official OWASP website. You'll get more details on path traversal attacks and ways to perform them.

To avoid path traversal, use varied approaches to check input data. In the above example, you can use a check for substrings ":" and "..\":

HttpResponse response;
HttpRequest request;

private void SendUserFileContent(string userDirectory)
{
  ....
  string userFileRelativePath = request.QueryString["relativePath"];

  if (   !userFileRelativePath.Contains(":") 
      && !userFileRelativePath.Contains(@"..\"))
  {
    string fullPath = Path.Combine(userDirectory,
                                   userFileRelativePath);
    var content = File.ReadAllText(fullPath);
  
    ....

    response.Write(content);
  }
  else
  {
    ....
  }
}

The analyzer also considers methods' parameters available from other assemblies to be insecure data sources. This topic is covered in details in the article: "Why You Should Check Values of Public Methods' Parameters".

Consider an example of code running on Windows:

public class UserFilesManager 
{ 
  private const string UsersDirectoryAbsolutePath = ....;
  private HttpResponse response;
  private string userName;

  public void WriteUserFile(string relativePath) 
  { 
    string path = Path.Combine(UsersDirectoryAbsolutePath,
                               userName,
                               relativePath);
    WriteFile(path);
  }

  private void WriteFile(string absolutePath) 
  { 
    response.Write(File.ReadAllText(absolutePath)); 
  } 
}

The analyzer will issue a low certainty level warning for a call of the 'WriteFile' method inside 'WriteUserFile'. After calling 'Path.Combine', insecure data gets from 'relativePath' to 'path'. Then this data acts as an argument of the 'WriteFile' call and is used as a path. This way, user input can get into the 'File.ReadAllText' method without checking, which makes this code vulnerable to path traversal.

Check parameters to protect against the attack. In this case, the check must take place before calling 'Path.Combine', because the value that 'Path.Combine' returns will be an absolute path anyway.

public void WriteUserFile(string relativePath) 
{ 
  if (relativePath.Contains(":") || relativePath.Contains(@"..\"))
  {
    ....
    
    return;
  }

  string path = Path.Combine(UsersDirectoryAbsolutePath,
                             userName,
                             relativePath);
  WriteFile(path);
}

This diagnostic is classified as:

You can look at examples of errors detected by the V5609 diagnostic.