📌 This blog is about Local File Inclusion (LFI), how attackers exploit it to gain access to sensitive files, and how developers can secure their code against this vulnerability. We will analyze a real-world vulnerable web application, PinewoodStore, demonstrate a full attack scenario, and discuss mitigation strategies.
Note:
A full demo of this attack will be posted on our YouTube channel, showcasing step-by-step exploitation and mitigation techniques.
What is Local File Inclusion (LFI)?
Local File Inclusion (LFI) is a web vulnerability that allows attackers to access files on the server by manipulating file paths. If exploited, LFI can lead to:
- Reading sensitive files (e.g.,
/etc/passwd,config.yml). - Leaking source code of the web application.
- Retrieving logs and credential files.
- Potential Remote Code Execution (RCE) under certain conditions.
LFI Vulnerability in PinewoodStore
Vulnerable Source Code (LfiController.java)
@RestController
@RequestMapping("/files")
public class LfiController {
@Value("${lfi.file.dir}")
private String baseDirectory;
@GetMapping("/read")
public ResponseEntity<Resource> readFile(@RequestParam String filename) throws IOException {
File file = new File(baseDirectory + filename);
System.out.println(baseDirectory);
System.out.println(filename);
if (!file.exists()) {
return ResponseEntity.status(HttpStatus.NOT_FOUND).body(null);
}
Resource resource = new FileSystemResource(file);
return ResponseEntity.ok()
.contentType(MediaType.TEXT_PLAIN)
.body(resource);
}
}
Why is this Code Vulnerable?
- User input (
filename) is not validated, allowing directory traversal (../) attacks. - Concatenation of
baseDirectory+filenameallows attackers to break out of the intended directory. - No access restriction, meaning an attacker can access any file on the server.
Full Attack Demonstration
1. Accessing Sensitive System Files
By manipulating the filename parameter, an attacker can traverse directories to read critical system files.
Example 1: Reading /etc/passwd (Linux User Information)
GET /files/read?filename=../../../../etc/passwd
Response:
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin ...
This reveals all system users, which can be useful for privilege escalation.
2. Reading Web Application Source Code
If PinewoodStore is deployed in /var/www/pinewoodstore/, an attacker can retrieve critical files:
Example 2: Reading application.properties
GET /files/read?filename=../../../../var/www/pinewoodstore/application.properties
Potential Leak:
- Database credentials
- API keys
- Secret tokens
3. Extracting Log Files
Log files may contain authentication tokens, usernames, and passwords.
Example 3: Reading app.log
GET /files/read?filename=../../../../var/logs/app.log
How to Fix LFI in PinewoodStore?
1. Validate User Input (Whitelist Approach)
Allow only predefined files to be accessed.
List<String> allowedFiles = List.of("file1.txt", "file2.txt");
if (!allowedFiles.contains(filename)) {
return ResponseEntity.status(HttpStatus.FORBIDDEN).body(null);
}
2. Restrict Directory Access (Path Normalization)
Ensure the requested file remains inside the allowed directory.
import java.nio.file.*;
Path filePath = Paths.get(baseDirectory).resolve(filename).normalize();
if (!filePath.startsWith(Paths.get(baseDirectory))) {
return ResponseEntity.status(HttpStatus.FORBIDDEN).body(null);
}
3. Use Secure File APIs
Instead of concatenating strings (baseDirectory + filename), use Paths.get() for safe path resolution.
Conclusion
The PinewoodStore application is vulnerable to Local File Inclusion (LFI) due to improper file path handling. Attackers can exploit this to read sensitive files, extract credentials, and gain further access.
🚀 The attack demo and code walkthrough will be posted on YouTube to show how to exploit and fix this vulnerability in real-world scenarios.
Would you like additional proof-of-concept scripts for automation? Let me know! 🔥
