> For the complete documentation index, see [llms.txt](https://lswsec.gitbook.io/lswsec-offensive/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://lswsec.gitbook.io/lswsec-offensive/web/local-file-inclusion/lfi.md).

# LFI

Basic LFI

* Look for URL parameters like language=en.php
  * This shows that when the language changes it brings back a file
  * the most common readable files to test with are
  * linux: /etc/passwd
  * windows: C:\Windows\boot.ini

Path Traversal

* in some scenarios, the paramater may be the directory the file is in.
  * language=en.php would mean ./language/en.php
  * to test for this put the paramater before the file you want to test for
  * ./language//etc/passwd
  * if that does not work, directory traversal may be needed
  * ./language/../../../../etc/passwd

Filename Prefix

* sometimes the paramater value could be prepended with something to give the real file name
* to combat this in path traversal start with a / instead of ..
* language=/../../../etc/passwd

Appended Extensions

* sometimes the paramater value might have an extension appended on the end
* this would make the file read as /etc/passwd.php

Second-Order Attacks

* Second-order attacks occur because web app functionalities may be insecurely pulling files from the back-end server based on user-controlled parameters.
* A web app may allow us to download our avatar through a URL file like"/profile/$username/avatar.png"
* If we craft a malicious LFI username (../../../etc/passwd), then it may be possible to change the file being pulled to another local file on the server and grab it instead of our avatar
* This would involve poisoning a database entry with a malicious LFI payload in our username
* Another web app functionality would utilize this poisoned entry to perform our attack, hence being called a second order attack
*