Burp Suite’s scanner can find path traversal vulnerabilities, but it’s not a magic bullet; you still need to understand what it’s looking for and how to guide it.
Let’s see Burp in action. Imagine you’re testing a web application that allows users to download profile pictures. The URL might look something like this: http://example.com/download.php?user_id=123.
We’ll use Burp Suite to see if we can access files outside the intended download directory.
First, set up Burp Suite as a proxy. Configure your browser to use 127.0.0.1:8080 as its HTTP proxy. Navigate to http://example.com/download.php?user_id=123 in your browser. In Burp’s Proxy -> HTTP history tab, you’ll see the request. Right-click on it and select Send to Scanner.
In the Scanner tab, go to the Scan queue. You’ll see your request listed. Click Start scan. Burp will begin crawling and testing for various vulnerabilities.
When Burp identifies a potential path traversal, it will show up in the Scanner -> Issues tab. The issue will be described, and importantly, it will show the specific request Burp sent and the response it received.
Consider a successful path traversal attempt. Burp might craft a request like this:
GET /download.php?user_id=../../../../etc/passwd%00 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://example.com/some_page
Cookie: sessionid=abcdef123456
Upgrade-Insecure-Requests: 1
Notice the ../../../../etc/passwd%00. The ../ sequences attempt to move up the directory tree. /etc/passwd is a common Linux file containing user account information. The %00 is a null byte, which, in some older or misconfigured applications, can terminate string processing prematurely, effectively bypassing any intended file name sanitization. If the server is vulnerable, instead of returning a profile picture, it might return the contents of /etc/passwd.
The problem Burp is trying to solve here is that web applications often need to read files based on user input. If the application doesn’t properly validate or sanitize this input, an attacker can trick it into reading sensitive files from the server’s file system that they shouldn’t have access to. This is path traversal, also known as directory traversal or .. (dot-dot-slash) attacks.
Internally, Burp’s scanner uses a set of payloads designed to test for this. It tries various combinations of ../, ..%2F, ..%5c, and encodes them differently. It also appends common sensitive file names like /etc/passwd, C:\boot.ini, WEB-INF/web.xml, and configuration files. The scanner then analyzes the response. If the response content changes in a way that suggests it’s reading a file from an unexpected location (e.g., a large amount of text that looks like a system file, or an error indicating file not found for a legitimate file but success for a traversal attempt), it flags it as an issue.
You can configure Burp’s scanner to be more aggressive or to focus on specific types of vulnerabilities. In the Scanner -> Options tab, under Scan configuration, you can select Audit checks and ensure Path traversal is enabled. You can also define custom payloads for more targeted testing if you have specific knowledge about the application.
The core of the vulnerability lies in how the application handles user-supplied file path components. If the application takes user_id=../../../etc/passwd and directly uses it in a file read operation like read_file('/var/www/html/user_images/' . $_GET['user_id']) (in PHP, for example), the resulting path becomes /var/www/html/user_images/../../../etc/passwd, which resolves to /etc/passwd. Proper sanitization would involve stripping out ../ sequences and validating that the resulting path remains within the intended directory.
A common mistake when using Burp for this is to rely solely on its automatic scanning. While effective, Burp might miss subtle variations or might not have the specific traversal strings you need if the application has custom filters. For instance, if the application decodes URL encoding twice, Burp’s default single-decoded payload might fail. You’d then need to craft a double-encoded payload in Burp’s Intruder or Repeater tabs.
The next hurdle you’ll likely encounter after fixing path traversal is broken access control, where a user might be able to access resources they aren’t authorized for, even if the path itself is not traversable.