Web Application Attacks

Web app vulnerabilities can lead to data exposure, command execution, malware, and more

Introduction

Web applications are now an essential part of almost every organisation’s IT environment – From online banking and e-commerce platforms to internal business applications, customer portals and cloud services, web applications frequently process sensitive information and interact with underlying operating systems and databases.

Because of this, vulnerabilities within a web application can provide attackers with many opportunities to move beyond the application’s intended functionality.

Some of the most important examples are Command Injection, Path Traversal, Local File Inclusion (LFI), and Remote File Inclusion (RFI).

Although these vulnerabilities work in different ways, they share a common underlying problem:

The application trusts user-controlled input when it should not.

Understanding these vulnerabilities is important because they demonstrate how seemingly simple input-handling mistakes can become serious security weaknesses.

Command Injection

Command Injection occurs when an application takes information supplied by a user and passes it to the underlying operating system without properly validating or sanitising it.

The application may legitimately need to execute an operating system command.

For example, imagine a web application that allows an administrator to check whether a particular server is reachable – The application might internally execute something similar to a ping command

e.g. ping 192.168.1.10

The user supplies the IP address, and the application constructs the command.

The problem occurs when the application fails to ensure that the supplied input is actually an IP address – An attacker may attempt to manipulate the input so that additional operating system commands are executed.

e.g. cat /etc/passwd

The web application therefore becomes an intermediary between the attacker and the operating system. In this example one which exposes internal user account data.

Why is Command Injection dangerous?

Command injection can potentially provide an attacker with the ability to execute commands using the privileges of the vulnerable application.

Depending on those privileges, an attacker may be able to:

  • Read sensitive files
  • Modify files
  • Create or delete accounts
  • Discover other systems
  • Execute malicious programs
  • Establish persistence
  • Steal credentials
  • Access databases
  • Download additional malware
  • Move further into the network

The severity therefore depends heavily on the privileges available to the compromised web application.

A vulnerable application running with excessive privileges can turn a relatively simple web vulnerability into a complete server compromise.

Path Traversal

Path Traversal is another vulnerability caused by insufficient validation of user-controlled input. It occurs when an application allows a user to specify a file or directory and fails to properly restrict where that file can be accessed.

Web applications frequently need to retrieve files.

For example – https://example.com/download?file=report.pdf

The web application may take the supplied filename and locate the corresponding file on the server. However, if the application does not properly restrict the supplied path, an attacker may attempt to navigate outside the intended directory.

This is commonly associated with directory traversal sequences such as ../ which represents the parent directory.

Repeated use can therefore attempt to move backwards through the directory structure. ../../../

Understanding Path Traversal

Lets say that the web application is designed to retrieve files from the following location on the server

/var/www/files/

A legitimate request might therefore access /var/www/files/report.pdf

The attacker, however, may attempt to manipulate the path so that the application accesses a file outside the intended directory, such as ../../../etc/passwd

If the application does not properly restrict the resulting path, files that were never intended to be accessible through the web application may become exposed.

What can path traversal expose?

The consequences of unrestricted path traversal depend on what the web server account can access.

Potentially exposed information could include:

  • Configuration files
  • Application source code
  • Credentials
  • API keys
  • Database connection information
  • Operating system files
  • Log files
  • User information
  • Private application data

In some circumstances, information obtained through path traversal can be used as the starting point for a much larger attack – For example, discovering a configuration file containing database credentials could allow an attacker to attack the database directly.

Local File Inclusion

Local File Inclusion (LFI) is closely related to path traversal but involves an application dynamically including files from the local server.

Some web applications use parameters to determine which page or resource should be loaded.

For example – ?page=about

The application might internally load the following file /about.php

If the application does not properly restrict the value supplied to the page parameter, an attacker may attempt to cause the application to load another file from the local system.

For example – ?page=/etc/passwd

This is Local File Inclusion.

Why is LFI dangerous?

LFI can allow attackers to access files that were never intended to be exposed through the application. Depending on the application and server configuration, this could include:

  • Configuration files
  • Application source code
  • Log files
  • Environment information
  • Credentials
  • Session information
  • Temporary files
  • Operating system information

The vulnerability can become particularly serious when the attacker can influence the contents of a file that is subsequently included by the application.

In certain circumstances, this can potentially turn a file disclosure vulnerability into code execution.

Remote File Inclusion

Remote File Inclusion (RFI) is similar to LFI, but instead of including a file from the local server, the vulnerable application may be tricked into retrieving and including a file from a remote location.

If the application allows arbitrary remote resources to be included, an attacker may attempt to make the server retrieve content controlled by the attacker.

This is significantly more dangerous than simply accessing an unintended local file.

LFI vs RFI

The easiest way to remember the difference is:

VulnerabilityFile LocationPrimary Risk
LFILocal serverUnauthorised file access or inclusion
RFIRemote serverInclusion of attacker-controlled content

Both vulnerabilities are generally caused by applications allowing user-controlled input to influence which resources are loaded.

Modern frameworks and server configurations have reduced the prevalence of traditional RFI, but the underlying concept remains important when assessing applications that dynamically load resources.

How these attacks are connected

Although Command Injection, Path Traversal, LFI and RFI are different vulnerabilities, they all demonstrate a similar security principle – The application assumes that the supplied input represents something legitimate.

The attacker instead supplies carefully constructed input designed to alter what the application does.

This is why input validation is such an important part of secure web application development.

How organisations can prevent these attacks

Developers can significantly reduce the risk by controlling how applications process user input.

  • Validate Input – Applications should validate input against an expected format rather than simply accepting arbitrary strings. For example, if an application expects an IP address, it should verify that the supplied value is actually a valid IP address.
  • Avoid Constructing Operating System Commands – Where possible, applications should use safe APIs rather than constructing shell commands from user-controlled input. This significantly reduces the possibility of command injection.
  • Restrict File Access – Applications should restrict file access to specific directories and prevent users from navigating outside those locations. Path normalisation should also be performed before accessing files.
  • Avoid User-Controlled File Includes – Applications should avoid allowing users to directly determine which files are included. Where dynamic file selection is required, applications should use a strict allow-list of permitted resources.
  • Apply Least Privilege – Web applications should run with only the permissions they actually require. If an application becomes compromised, least privilege can significantly restrict what an attacker can do.
  • Keep Software Updated – Web servers, frameworks, libraries and applications should be regularly updated to address known vulnerabilities.

Conclusion

Command Injection, Path Traversal, Local File Inclusion and Remote File Inclusion are different vulnerabilities, but they share a common underlying weakness: the application allows user-controlled input to influence operations that should be tightly controlled.

Command Injection can allow attackers to interact with the underlying operating system, while Path Traversal can expose files outside their intended location.

LFI can cause applications to include unintended files from the local system, while RFI can potentially cause applications to retrieve and include content from an attacker-controlled remote location.

Modern development frameworks and security controls can significantly reduce these risks, but vulnerabilities continue to appear when applications fail to properly validate input, restrict file access or enforce least privilege.

For developers, the lesson is clear: never trust user input.

For security professionals, understanding these vulnerabilities provides an important foundation for understanding how attackers can move from a simple web application weakness to a much more serious compromise.