Secure Programming of Web Applications: Remote File Inclusion (RFI) and Local File Inclusion (LFI) resp. Directory/Path Traversal

Added at 12/08/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book and online course "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers".

Description

In case a web applications loads files at runtime (e.g., reading local files or files through HTTP access) in an insecure way, the file location address can be manipulated so that internal, restricted files might be accessible or even external scripts might be executed.

In combination with a vulnerable file upload mechanism, an attacker might alter the web application completely or distribute malware to legit users.

The destination of such an attack usually is the server or web application directly (for instance to access accounts, passwords or server configurations etc.). In case of manipulation of scripts or the application's links using malicious external links of the attacker, the users can also be affected directly.

Example including Security Vulnerability:

A typical attempt to escape from a preset file path would use local file system command characters, e.g.

Also control characters like the null byte (%00) can be used to manipulate paths and for instance end processing paths prematurely.

Vulnerable script invocations on the other hand typically look like this:

In this case, an attacker would try - also using path manipulation - if other executable scripts (think of, e.g., common web shop systems, LAMP stacks etc.) can be found or even worse, an own remote script might be executed (HTTP).

Secure Programming:

1)

External files and script have to be linked only statically.

As far as possible, linking to or forwarding files has to be implemented internally and must not be based on URL-based parametrization. This can be done by, e.g., using a configuration file or database table. The selection of scripts which can be executed within a web application has to be limited to a fixed list. In case scripts need to be loaded from external resources, explicitly defined whitelists have to be used (compare chapter "Open Redirection").

2)

Using file accesses, for instance including user-based file uploads, requires filters which prevent "escaping" from the destination directory. This does not apply if the files are uploaded to a database.

Storing files in a database system is preferred!

In case of local file access, to prevent escaping every programming environment includes functions to "canonize" paths. Canonized path can easily be used to verify and compare different path securely. Checkout the following method as an example:

This method is more secure than building custom filters for file system command characters. However, in case of custom built filters blacklisting must not be used (like filtering control characters as the null byte or line break characters). Instead whitelisting must be implemented. This means, only a list of restricted characters are to be allowed in file names. The list has to be explicitly defined. Other characters simply have to be removed and a new file name created. A special emphasis has to be applied for null byte processing within strings in any case.

Keywords

Remote File Inclusion, RFI, Local File Inclusion, LFI, Directory Traversal, Path Traversal, Secure Programming, Web Applications, Web Application Security, OWASP, Software Development, IT Security, Awareness

Categories: IT Security Background articles Development/Java

---

Comments

Post your comment

Share

If you like this page, it would be a great thing if you share it with others:

reddit Digg StumbleUpon XING
WhatsApp Telegram