Local File Inclusion — Learning the Request-to-File Path

What I Was Trying to Understand

I wanted to understand Local File Inclusion as a chain of decisions rather than as a payload to memorize: where user input enters an application, how that input reaches a file-handling function, and what server-side controls determine whether the requested resource can be accessed.

What I Observed

The important part of the exercise was tracing the application’s input flow. A parameter that appears harmless at the browser level can become security-sensitive when it is used to construct a filesystem path.

What I Tried

I worked through the Academy material and used the lab environment to inspect how different inputs changed the application’s response. I also spent time understanding the role of PHP configuration and the distinction between reading local resources and making the server retrieve remote content.

What Failed

Some early assumptions came from treating the vulnerable parameter as if it had one obvious behavior. The exercise made it clear that the application, PHP configuration, filesystem permissions, and web-server behavior all influence what an LFI attempt can actually achieve.

What Worked

The most useful approach was to reason from the application’s behavior: identify the parameter, establish a normal request, change one variable at a time, and use the response as evidence. That made the technique much easier to understand than memorizing a list of payloads.

What I Learned

LFI is fundamentally about trust between application input and filesystem operations. The practical lesson is broader than LFI: when assessing an application, I should follow data from its entry point to the sensitive operation and ask where validation or trust boundaries are enforced.

Classification

This was guided learning through Hack The Box Academy. I am documenting it as a study exercise, not presenting it as an independently discovered vulnerability.