> For the complete documentation index, see [llms.txt](https://itrp19-notes.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://itrp19-notes.gitbook.io/notes/reference/hacking/web-app-pentesting/lfi-rfi.md).

# LFI/RFI

\
Local File Inclusion (LFI) is a type of vulnerability often found in web applications that allows an attacker to read or execute files on the server that hosts the application. This issue arises when an application accepts user input to determine which files to include for execution or display without adequately sanitizing the input to prevent malicious manipulation. LFI vulnerabilities are primarily associated with PHP applications due to PHP's extensive use of file inclusion functions like `include()`, `require()`, `include_once()`, and `require_once()`. However, the vulnerability is not exclusive to PHP; it can occur in any web application that dynamically includes files based on user input, including those built with JSP, ASP, and similar technologies.

The exploitation of an LFI vulnerability can have various impacts, ranging from mild to critical, depending on the nature of the application, the configuration of the server, and the privileges of the files accessible through the vulnerability. These impacts include but are not limited to:

1. **Code Execution on the Server**: If an attacker can include and execute their PHP code on the server, they can perform any action that the server's permissions allow. This can lead to a complete compromise of the server and its data.
2. **Code Execution on the Client-Side**: Including malicious scripts (e.g., JavaScript) in the output sent to the user can lead to cross-site scripting (XSS) attacks. This can result in session hijacking, phishing, or defacement of the website.
3. **Denial of Service (DoS)**: By including files in a loop or by including large files, an attacker could exhaust the server's resources, leading to denial of service.
4. **Sensitive Information Disclosure**: An attacker could include configuration files, source code, logs, or other sensitive files in the output, leading to the disclosure of credentials, intellectual property, or personal data.
5. **Authentication Bypass**: In some cases, including specific files could lead to bypassing authentication mechanisms, granting the attacker unauthorized access to restricted areas of the application.

Mitigation of LFI vulnerabilities involves several best practices, including:

* Validating and sanitizing all user inputs to ensure that only intended paths and files can be included.
* Employing a whitelist of allowable files for inclusion, rather than trying to block malicious input.
* Using low-privilege modes for the web server process to limit the files that can be accessed and executed.
* Applying the principle of least privilege to file permissions to restrict the ability of an attacker to include sensitive files.
* Regularly updating and patching all software components to mitigate known vulnerabilities.

In addition to the common LFI attack, there's a related attack called Remote File Inclusion (RFI) that allows an attacker to include files from a remote server. This distinction is crucial because while LFI is about exploiting local files, RFI can introduce or execute entirely new code from an external source.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://itrp19-notes.gitbook.io/notes/reference/hacking/web-app-pentesting/lfi-rfi.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.