Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: Authentication bypass via information disclosure.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: Information disclosure in version control history | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

Step 3: Discover Content

Open Burp Suite, go to the Target tab, and then click on Site map. There, you can see the lab’s URL. Right-click on it, select Engagement tools, and then choose Discover content. A new window will pop up; select Session is not running. It will start crawling the website.

It will take some time to complete the crawling process.

As this lab is related to version control, we’ll look for git or .git-related paths.

Step 4: Exploring /.git content

Once the crawling is completed, you will see a path named .git. We’ll explore that directory. Go to the address bar, add /.git, and press Enter.

You will see some files related to Git.

To analyze these files, we need to download a copy of the entire directory using the following command:

wget -r https://0aef00d6038cfdc382dd38d3007d002e.web-security-academy.net/.git

This will start downloading the entire content of .git to your Kali Linux system.

Note: The URL may change due to inactivity, so you might need to start a new session. However, the steps remain the same.

Once the download is completed, navigate to the downloaded directory (e.g., "0a8900ac0499438880ce7b2b001a00ae.web-security-academy.net") using the cd command.

Once you’re inside this directory, use:

ls -al

Once you’re inside this directory use “ls -al” to display the hidden files and folders. Once command is executed you’ll se .git folder. Navigate to that folder and once again execute “ls -al” command, you’ll see the following files:

to display hidden files and folders. After executing the command, you will see the .git folder. Navigate to that folder and run ls -al again to view its contents.

Now, to read the contents of the config file you need to use an application called git-cola.

In the terminal, type:

git-cola

A window will pop up. Here, you will see two files: admin.conf and admin_panel.php. When you select admin.conf, you will see a line at the bottom containing "ADMIN_PASSWORD".

To view the previous commit of that file, go to Commit in the toolbar and click on Amend Last Commit.

You will see a previous version of admin.conf, which contains the admin password.

This is how we found the administrator password.

Using the found password, log in to the administrator account.

Once logged in, click on the Admin Panel.

You will be redirected to the Users page, where you can see two users: Weiner and Carlos. To complete the lab, you need to delete Carlos.

Step 5: Completing the Lab

Once you delete Carlos, check your browser, and you will see the message:
“Congratulations, you have solved the lab.”

That’s it! You’ve successfully solved the Information disclosure in version control history lab.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

PortSwigger Lab: Information disclosure in version control history was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Domain Name System (DNS) is a fundamental component of the internet that translates human-readable domain names into machine-readable IP addresses. When a user enters a website address such as example.com in a browser, the computer cannot directly understand the domain name. Instead, it must obtain the corresponding IP address of the server hosting that website. DNS performs this translation process, allowing users to access websites and services using easy-to-remember names instead of numerical IP addresses.

DNS works through a hierarchical and distributed system of servers. When a domain lookup is requested, the query typically passes through multiple layers of DNS infrastructure, including the root servers, top-level domain (TLD) servers, and authoritative name servers. Each layer helps guide the request toward the server that holds the correct record for the domain. Once the authoritative server returns the IP address, the resolver caches the result for a certain duration defined by the TTL (Time To Live) value, allowing future requests to be resolved more quickly.

Now lets learn more about the DNS Record

DNS servers store information in the form of DNS records, which define how a domain behaves on the internet. Each record contains specific instructions such as mapping a domain to an IP address, directing email servers, or creating domain aliases.

Common DNS Record Types and its importance:

A Record (Address Record)

The A record maps a domain name to an IPv4 address. When a user requests a domain, the DNS resolver uses the A record to find the corresponding server IP.

example.com   3600   IN   A   192.0.2.1

Key Components and Management

• Time to Live (TTL): This value determines how long the record remains cached in the DNS table before it must be refreshed. For example, a TTL of 3600 indicates the record will stay active for 3600 seconds, or one hour.
• Migration Best Practices: When migrating an application or database server, a common issue is that the A record still points to the old IP address because the TTL has not yet expired. To avoid this, it is recommended to lower the TTL value to a few minutes or even 60 seconds before the migration. This allows for faster testing and ensures users are routed to the new IP address more quickly.

Troubleshooting

If a website is completely unreachable or results in a “connection failed” error, it is often a sign of an A record issue or a problem with the underlying IP address. In scenarios where a change is “working for some people but not for others,” it may be that the TTL is too high, preventing the latest record from populating across the internet quickly.

AAAA Record (IPv6 Address Record)

The AAAA record performs the same function as an A record but maps the domain to an IPv6 address instead of IPv4.

example.com   3600   IN   AAAA   2001:db8::1

The relationship and key details regarding AAAA records include:

• Transition to IPv6: As the availability of IPv4 addresses has become limited, the industry is gradually moving toward IPv6, making AAAA records increasingly prominent in DNS settings.
• Optional Status: Currently, the AAAA record is often considered optional, and you will find it less frequently than A records in many existing setups.
• Dual-Stack Environments: In environments using “dual stack” (supporting both IPv4 and IPv6), the system may be configured to prioritize IPv6. In this case, a request will first attempt to connect via the AAAA record before prioritizing the IPv4 A record.
• Performance and Latency: You must be careful when configuring these records. If a dual-stack environment is looking for an IPv6 address but the AAAA record is missing, the system will experience a “fallback” to IPv4. This search and subsequent fallback can add latency and cause performance slowness in user requests. So you have to decide whether you need to have IPv6 or not.

CNAME Record (Canonical Name Record)

A CNAME record creates an alias for a domain, pointing one domain name to another domain name instead of an IP address.

www.example.com   3600   IN   CNAME   example.com

Key characteristics include:

• Forwarding Requests: It effectively routes requests from one of your domains to another destination domain.
• Cloud Integration: It is used heavily in cloud environments for managing Content Delivery Networks (CDNs) and load balancers.
• Subdomain Requirement: A critical technical limitation is that you cannot use a root domain (e.g., example.com) as a CNAME record; it must be applied to a subdomain (e.g., www.example.com).

Troubleshooting

If CNAME records are messed up or mis-configured, it can lead to “domain not found” errors. This often happens if the mapping to backend load balancers is incorrect or has been changed without updating the DNS table. When troubleshooting these errors, it is vital to verify that all load balancers are correctly mapped to their respective CNAMEs.

NS Record (Name Server Record)

The NS record identifies the authoritative DNS servers responsible for handling DNS queries for a domain.

example.com   3600   IN   NS   ns1.exampledns.com
example.com   3600   IN   NS   ns2.exampledns.com

These servers contain the official DNS records for the domain.

Basically it tells Root Domain And Top Level Domain(TLD) where to go to find the IP Address.

The DNS system operates in a hierarchy, and the NS record is a critical link in this chain:

• Routing Requests: When you type a URL, the request first hits a root domain. That root domain directs the request to a Top-Level Domain (TLD) (like .com or .org), which then uses the NS records to point the request toward the specific authorization server (also called a name server) that holds the domain’s IP address.
• Authoritative Servers: These servers are typically managed by providers like GoDaddy or AWS Route 53.
• TTL is usually high as you rarely change your NS record. Its updated when you migrate from one domain provider to another domain provider. During this period you have to wait around 48 hours or so.

SOA Record (Start of Authority)

The SOA record contains administrative information about the DNS zone, including the primary name server, administrator contact, and zone update settings.

example.com   3600   IN   SOA   ns1.exampledns.com admin.example.com (
                    2026031101 ; serial
                    7200       ; refresh
                    3600       ; retry
                    1209600    ; expire
                    3600 )     ; minimum TTL

It helps DNS servers manage zone synchronization and updates.

Key Data within a SOA Record

• Administrative Information: It includes the primary name server for the zone and the email address of the administrator (e.g., admin@example.com).
• Serial Number: This value acts as a version number for the DNS setup, helping to manage and track changes.
• Refresh and Retry Settings: These settings command how frequently the DNS table should be refreshed or retried if a refresh fails.
• Negative TTL: This specific feature determines how long the internet should “remember” that a record does not exist. For instance, if you are currently building a new subdomain (like new.example.com) that isn't live yet, a negative TTL of 24 hours tells the internet to stop looking for it for that duration before checking again.

TXT Record (Text Record)

The TXT record stores text information associated with a domain. It is commonly used for verification and security mechanisms such as SPF, DKIM, and domain ownership verification.

example.com   3600   IN   TXT   "v=spf1 include:_spf.example.com ~all"

TXT records are widely used in email authentication and service validation.

Key Functions and Use Cases

• Domain Verification: TXT records are frequently used to “legitimise” the use of third-party services on your domain. For example, if you want to integrate tools like Notion or Slack, these platforms will provide specific text entries for you to add to your DNS records to prove you own the domain.
• Email Authentication: This is one of the most critical uses for TXT records. By adding specific lines (such as SPF or DKIM records), you can authorize specific servers — like Google or Gmail servers — to send emails on your domain’s behalf.
• Security and Spam Prevention: These authentication records help prevent cyber threats and ensure your emails are recognized as legitimate rather than fraudulent.

Troubleshooting

If you find that emails sent from your domain are consistently landing in spam folders, it is a primary sign that your TXT records are not configured correctly. In this scenario, you would need to check your DNS table to ensure you have mentioned the correct authorized servers to legitimize your outgoing mail.

MX Record (Mail Exchange Record)

The MX record specifies the mail server responsible for receiving emails for a domain.

example.com   3600   IN   MX   10 mail.example.com

The number 10 represents the priority of the mail server.

The most distinct feature of an MX record is its priority field. This integer value determines the order in which mail servers are used:

• Lowest Priority First: Email is always sent to the server with the smallest numerical priority value (e.g., a priority of 1 is tried before a priority of 10).
• Redundancy and Backup: If the primary server (the one with the lowest priority) is offline or overwhelmed, the system automatically moves to the next highest priority server. This backup server may either deliver the mail directly or queue it until the primary server returns.
• Load Balancing: If multiple MX records are assigned the same priority, the email traffic is distributed evenly between those servers in a load-balanced fashion.
• Relative Values: Priority values are relative; for example, setting three servers at priorities 10, 20, and 30 functions exactly the same as setting them at 1, 2, and 3.

PTR Record (Pointer Record)

A PTR (Pointer) record is used in reverse DNS lookups, where an IP address is mapped back to a domain name. While most DNS queries resolve a domain name to an IP address (using an A or AAAA record), PTR records perform the opposite function by resolving an IP address to its associated hostname.

1.0.1.103.in-addr.arpa   3600   IN   PTR   www.example.com

Key features include:

• Reverse DNS Resolution — Converts an IP address into its corresponding domain name.
• Stored in Reverse Zones — Located under special domains like in-addr.arpa (IPv4) and ip6.arpa (IPv6).
• Email Server Verification — Commonly used by mail servers to verify the legitimacy of sending servers.
• Network Troubleshooting — Helps administrators identify hostnames from IP addresses in logs and monitoring systems.
• Managed by IP Owner — Typically configured by the ISP or the organization that owns the IP address block.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: Authentication bypass via information disclosure.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: Authentication bypass via information disclosure

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

Now open one of the product from the home page and capture its traffic

Step 3: Sending Vulnerable Parameter to Repeater

Select the request and send it to the Repeater.

Forward/Send the request sent to Repeater, we can see its gives Status Code of 200 OK.

Step 4: Manipulating the Parameter

Since we know there’s a custom HTTP header, the response reveals that the admin panel is accessible only if logged in as an administrator or if the request originates from a local IP.

Send the request again, but this time using the TRACE method:

• TRACE is a debugging method that should not be enabled in a production environment.
• Notice that the X-Custom-IP-Authorization header (containing your IP) is automatically appended to the request. (I’ve obfuscated my IP here for security reasons.)

Notice that the X-Custom-IP-Authorization header, containing your IP address, was automatically appended to your request. Thus i have obfuscated my IP here.

Now, send the TRACE request to Repeater again.

• Change TRACE to GET.
• Copy the X-Custom-IP-Authorization header from the TRACE response.
• Paste it in the GET request and set its value to 127.0.0.1 (loopback address).
• Send the request, and you should now have admin access.

To confirm admin access, search for “admin” in the response tab.

As we have admin access we can visit admin panel by adding /admin in the GET request.

We get 200 OK Status with access to admin panel. So to delete the user carlos, lets first search for carlos in the response tab.

As we can see there’s a user named carlos. Now lets copy /admin/delete?username=carlos and paste it in the GET request to perform deletion.

Step 5: Completing the Lab

Now lets copy /admin/delete?username=carlos and paste it in the GET request and send the request to perform deletion.

You’ll get 302 Found status.

Check your browser, and you’ll see the message:
“Congratulations, you have solved the lab.”

That’s it! You’ve successfully solved the Authentication bypass via information disclosure lab.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

PortSwigger Lab: Authentication bypass via information disclosure was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: Source Code disclosure via backup files.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: Source code disclosure via backup files | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

Step 3: Capturing and Crawling the website

If you have Burp Suite Pro, navigate to the Target tab, click on Site Map, locate the lab’s URL, right-click on it, select Engagement Tools, and then choose Discover Content. This will perform an in-depth crawl of the website.

Click on Session is not running, and click Yes when a pop up appears which says , “This url is outside current target scope. Are you sure you want to discover content?”

Step 4: Exploring the files

As we can see, there’s a path named /backup, which seems relevant to our current lab. Let’s copy this path into the browser and explore it further.

Here, we find a backup file containing Java source code. Let’s open it and examine its contents.

Upon analyzing the source code, we discover a hard-coded password for a Postgres database.

Step 5: Completing the Lab

Now, we’ll copy the hard-coded password from the ProductTemplate.java.bak.

1. Go back to your lab’s homepage.
2. Click on “Submit Solution”.
3. Paste the copied hard-coded password.
4. Click OK.

Check your browser, and you’ll see the message:
“Congratulations, you have solved the lab.”

That’s it! You’ve successfully solved the Source Code disclosure via backup files lab.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

PortSwigger Lab: Source code disclosure via backup files was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: Information disclosure on debug page.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: Information disclosure on debug page | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

In Burp Suite, navigate to the Proxy tab and select HTTP History. Click on Filter Settings and enable Images as shown above.

Step 3: Capturing and Crawling the website

Once you access the lab, browse through a few pages while Burp Suite captures the requests and crawls the website.

If you have Burp Suite Pro, navigate to the Target tab, click on Site Map, locate the lab’s URL, right-click on it, select Engagement Tools, and then choose Discover Content. This will perform an in-depth crawl of the website. However, in this case, it won’t be necessary.

Step 4: Exploring the Files

On the left-hand side (LHS) of Burp Suite, you’ll see a list of files that were crawled. The cgi-bin directory looks interesting — let’s check it out.

Inside this folder, there’s a file named phpinfo.php, which could reveal valuable information. Right-click on it, select Copy URL, then paste the URL into your browser. This will display detailed information about the PHP server.

Now, press CTRL + F and search for “ SECRET_KEY ” to locate any sensitive information.

Step 5: Completing the Lab

Now, we’ll copy the SECRET KEY from the phpinfo page.

1. Go to the browser tab where the lab is open.
2. Click on “Submit Solution”.
3. Paste the copied SECRET KEY.
4. Click OK.

Check your browser, and you’ll see the message:
“Congratulations, you have solved the lab.”

That’s it! You’ve successfully solved the Information Disclosure on Debug Page lab.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

PortSwigger Lab: Information disclosure on debug page was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: Information disclosure in error messages.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: Information disclosure in error messages | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

In Burp Suite, navigate to the Proxy tab and select HTTP History. Click on Filter Settings and enable Images as shown above.

Step 3: Sending Vulnerable Parameter to Repeater

Observing the requests, we can see that /image?filename= is used to fetch images from the server directory. We'll manipulate this parameter by sending it to Burp Suite’s Repeater.

Step 4: Manipulating the Parameter

The productId parameter interacts with the back-end, so we'll try manipulating it to induce an error.

Now, we’ll replace '1' with a single quote (') in the productId parameter. Since the server does not expect this as a valid input, it may throw an error and potentially display sensitive information, especially if stack traces are enabled in the production environment.

As expected, we receive a 500 Internal Server Error, along with the Apache server version i.e. 2.2.31 in the response.

Step 5: Completing the Lab

Now, we’ll copy the Apache server version from the error message.

1. Go to the browser tab where the lab is open.
2. Click on “Submit Solution”.
3. Paste the copied server version.
4. Click OK.

Check your browser, and you’ll see the message:
“Congratulations, you have solved the lab.”

That’s it! You’ve successfully solved the Information Disclosure in Error Messages lab.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

PortSwigger Lab: Information disclosure in error messages was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: File path traversal, validation of file extension with null byte bypass.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: File path traversal, validation of file extension with null byte bypass | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

In Burp Suite, navigate to the Proxy tab and select HTTP History. Click on Filter Settings and enable Images as shown above.

Step 3: Sending Vulnerable Parameter to Repeater

Observing the requests, we can see that /image?filename= is used to fetch images from the server directory. We'll manipulate this parameter by sending it to Burp Suite’s Repeater.

Step 4: Manipulating the Parameter

First, we attempt to retrieve sensitive file information using a relative path traversal:

filename=../../../etc/passwd

Looking at the response, we see that it does not work. Instead, we receive a 400 Bad Request error stating "No such file".

Since traversal sequences are blocked, we’ll try using an absolute path instead:

filename=/etc/passwd

However, we receive the same "No such file" error with 400 Bad Request. This means we need to try a different approach.

As we know from the lab title, this challenge involves file extension validation, and we need to bypass it using a null byte injection technique.

What is Null Byte Injection?

Null byte injection is an active exploitation technique used to bypass file extension validation in web applications. It works by appending a URL-encoded null byte (%00) to the user-supplied input. Many applications use string-based checks to enforce file extensions but rely on lower-level system calls (like open() in C), which stop processing at the null byte. This can trick the system into ignoring the enforced extension and accessing restricted files.

Our Approach:

To bypass the extension check and retrieve /etc/passwd, we'll use the following payload:

../../../etc/passwd%00.png

Why This Works?

• The application expects a .png file, but by appending %00.png, the sanity check sees it as a valid .png file.
• However, at the system level, %00 acts as a string terminator, causing the system to ignore everything after it and process only ../../../etc/passwd.
• This allows us to access the restricted system file while bypassing extension validation.

Now, let’s test this in Burp Suite! 🚀

Voila! null byte bypass works! We receive a 200 OK status in the Repeater, along with the contents of /etc/passwd.

Step 5: Completing the Lab

Go back to your browser, and you’ll see the message:

“Congratulations, you have solved the lab.”

That’s it! You’ve successfully exploited the vulnerability using validation of file extension with null byte bypass.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: File path traversal, validation of start of path.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: File path traversal, validation of start of path | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

In Burp Suite, navigate to the Proxy tab and select HTTP History. Click on Filter Settings and enable Images as shown above.

Step 3: Sending Vulnerable Parameter to Repeater

Observing the requests, we can see that /image?filename= is used to fetch images from the server directory. We'll manipulate this parameter by sending it to Burp Suite’s Repeater.

Step 4: Manipulating the Parameter

Compared to previous labs, we can see that the entire path where the image is stored is explicitly mentioned. This means our approach needs to be different.

Instead of using relative traversal sequences, we’ll try accessing the file directly using an absolute path:

filename=/etc/passwd

However, we receive the same "Missing parameter 'filename'" error with 400 Bad Request. This means we need to try a different approach.

As we know, the original request already contains the full image path, such as:

/var/www/images/2.jpg

This means we can directly attempt to traverse directories using an absolute path-based approach.

To access /etc/passwd, we'll modify the filename parameter as follows:

/var/www/images/../../../etc/passwd

This traversal moves three levels up from /var/www/images/ to reach the root directory (/), allowing us to access /etc/passwd. Now, let's test this in Burp Suite!

Voila! 🎉 The absolute path-based approach works!

Our payload successfully bypasses the restriction, and we receive a 200 OK status in Burp Suite’s Repeater, along with the contents of /etc/passwd.

Now, let’s proceed to complete the lab!

Step 5: Completing the Lab

Go back to your browser, and you’ll see the message:

“Congratulations, you have solved the lab.”

That’s it! You’ve successfully exploited the vulnerability using absolute path-based approach.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: File path traversal, traversal sequences stripped non-recursively.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: File path traversal, traversal sequences stripped non-recursively | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

In Burp Suite, navigate to the Proxy tab and select HTTP History. Click on Filter Settings and enable Images as shown above.

Step 3: Sending Vulnerable Parameter to Repeater

Observing the requests, we can see that /image?filename= is used to fetch images from the server directory. We'll manipulate this parameter by sending it to Burp Suite’s Repeater.

Step 4: Manipulating the Parameter

First, we attempt to retrieve sensitive file information using a relative path traversal:

filename=../../../etc/passwd

Looking at the response, we see that it does not work. Instead, we receive a 400 Bad Request error stating "No such file".

Since traversal sequences are blocked, we’ll try using an absolute path instead:

filename=/etc/passwd

However, we receive the same "No such file" error with 400 Bad Request. This means we need to try a different approach.

The application removes path traversal sequences before processing the filename parameter, but it does so non-recursively — meaning it strips ../ only once without re-evaluating the modified input.

To bypass this, we use an obfuscated payload:

....//....//....//etc/passwd

Why This Works?

• The application detects and removes ../, but ....// does not match exactly, allowing it to slip through.
• Since filtering is non-recursive, parts of the traversal sequence remain intact after initial stripping.
• Many file systems treat // as a single /, making ....// effectively behave like ../.

Now, let’s test this in Burp Suite.

Voila! Obfuscated payload works! We receive a 200 OK status in the Repeater, along with the contents of /etc/passwd.

Step 5: Completing the Lab

Go back to your browser, and you’ll see the message:

“Congratulations, you have solved the lab.”

That’s it! You’ve successfully exploited the vulnerability using a non-recursive traversal bypass technique.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!

Hello everyone! Nikhil Bhandari here. Today, I’ll be sharing a step-by-step guide on how to solve the PortSwigger Lab: File path traversal, traversal sequences stripped with superfluous URL-decode.

To access this lab, you’ll need to create a PortSwigger account. Once you’re logged in, you can access the lab using the link below:

Lab: File path traversal, traversal sequences stripped with superfluous URL-decode | Web Security Academy

So, let’s get started!

Step 1: Accessing the Lab

First, click on the Access Lab button. A new tab will open, where the lab environment will be available.

Step 2: Setting Up FoxyProxy and Burp Suite

Next, configure FoxyProxy to redirect the lab’s traffic to Burp Suite. Once configured, refresh the page in your browser to start capturing traffic in Burp Suite.

In Burp Suite, navigate to the Proxy tab and select HTTP History. Click on Filter Settings and enable Images as shown above.

Step 3: Sending Vulnerable Parameter to Repeater

Observing the requests, we can see that /image?filename= is used to fetch images from the server directory. We'll manipulate this parameter by sending it to Burp Suite’s Repeater.

Step 4: Manipulating the Parameter

First, we attempt to retrieve sensitive file information using a relative path traversal:

filename=../../../etc/passwd

Looking at the response, we see that it does not work. Instead, we receive a 400 Bad Request error stating "No such file".

Since traversal sequences are blocked, we’ll try using an absolute path instead:

filename=/etc/passwd

However, we receive the same "No such file" error with 400 Bad Request. This means we need to try a different approach.

Now, we attempt URL encoding using our first payload: we’ll try url encoding using the 1st payload:

../../../etc/passwd

To URL-encode it in Burp Suite:

• Select the payload ../../../etc/passwd
• Right-click → Convert Selection → URL → URL-Encode all characters
• Alternatively, press Ctrl + U

Even after URL encoding, we still get the same 400 Bad Request error.

Since the server is stripping traversal sequences after decoding once, we try double URL encoding:

1. Take the already URL-encoded payload.
2. Encode it again using the same method.

This ensures the server decodes it twice, allowing the traversal sequences to bypass the filter.

Let’s send the double-encoded request and check the response.

Voila! Double encoding our payload works! We receive a 200 OK status in the Repeater, along with the contents of /etc/passwd.

Step 5: Completing the Lab

Go back to your browser, and you’ll see the message:

“Congratulations, you have solved the lab.”

That’s it! You’ve successfully bypassed the restriction using traversal sequences stripped with superfluous URL-decode.

Thank you for taking the time to read my article!
I hope you found it informative and valuable. If you enjoyed it, please consider liking the article, following me for more content, and sharing it with others who might benefit from it. Your support means a lot!