I'll confess something. I like web pentesting, but I don't find it as easy to understand as AD pentesting, for example. I know that may sound weird, but it's true. The concept of PHP Wrappers was no exception. It confused me at first. But I took the time to dissect the material and simplified it for myself. Now, I want to share that breakdown with you too. Because sharing is caring.

Local File Inclusion (without PHP wrappers) is not hard to understand. The concept is simple. A URL parameter used by the webpage is replaced with an arbitrary file path. The web server includes and displays the content of that file, potentially bypassing access restrictions.

The simplest of all examples:

http://chepe-tours.com/index.php?countries=colombia

The parameter here would be: countries=

And based on nmap and GoBuster enumeration, , we can change that value to this:

http://chepe-tours.com/index.php?countries= ../../../../etc/passwd

If the web application is vulnerable to LFI, it will display/etc/passwd content in the browser:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
mysql:x:100:101:MySQL Server:/var/lib/mysql:/bin/false
chepe:x:1000:1000:Jose Perez P:/home/chepe:/bin/bash
maria:x:1001:1001:Maria Gonzalez:/home/maria:/bin/bash
ftp:x:120:65534:ftp daemon:/srv/ftp:/usr/sbin/nologin

This simple example shows how Local File Inclusion can be used to read sensitive files when no input validation is in place. But what happens when direct access to these files is restricted or blocked? That's where PHP wrappers come into play

PHP Wrappers to The Rescue

Sometimes, direct file paths don't work, especially if the server has hardened configurations or filters in place. In these cases, PHP gives us a powerful tool: wrappers. They allow us to include and interact with files, streams, and even remote content in alternative ways.

A stream is just a flow of data, like drinking water through a straw. You don't get everything at once. This is how PHP handles files, user input, and output to the browser.

Sometimes developers need to work with these streams in special ways. That's where PHP wrappers come in. And this is where LFI can become trickier and powerful too.

If a PHP website has an LFI vulnerability, an attacker can load local files. But when loading a .php file, the server executes it instead , it does not show its content, like we saw before.

To bypass this, the attacker uses PHP wrappers like php://filter to read the source code instead of executing it.

Let's say you want to see the content of index.php:


 http://chepe-tours.com/index.php?countries=index.php

In theory, this should open the content of the file. But the problem is the extension. The web app will execute the PHP code first, and only display whatever HTML output it generates.

To bypass that, we use a wrapper:


 http://chepe-tours.com/index.php?countries=php://filter/read=convert.base64-encode/resource=index.php

Now, instead of executing the file, the server gives us something like this:


 PD9waHAgZWNobyAiQWNjZXNzIEtleTogd0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWSAiOyA/Pg==

This is what we get if we decode this using any online Base64 decoder:

None
<?php echo "Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY "; ?>

With the PHP wrapper, we now have access to a piece of code hidden inside the PHP file. The developer probably thought it was safe. But it was not. He forgot to disable dangerous wrappers.

Local file inclusion vulnerabilities become much more dangerous when combined with PHP Wrappers. Together, they can turn a simple file read into full source code disclosure.

What seems like a small oversight in code can easily open the door to a serious breach, exposing sensitive files, AWS credentials, or even hidden code that was never meant to be seen.

The key takeaway here is simple: always validate and sanitize any user's input. Attackers will always find creative ways to trick the application into revealing what it shouldn't. So expect the worse.