Bug Or Feature? Hidden Web Application Vulnerabilities Uncovered

Web Application Security consists of a myriad of security controls that ensure that a web application:

Functions as expected.
Cannot be exploited to operate out of bounds.
Cannot initiate operations that it is not supposed to do.

Web Applications have become ubiquitous after the expansion of Web 2.0, which Social Media Platforms, E-Commerce websites, and email clients saturating the internet spaces in recent years.

As the applications consume and store even more sensitive and comprehensive data, they become an ever more appealing target for attackers.

Common Attack Methods

The three most common vulnerabilities that exist in this space are Injections (SQL, Remote Code), Cryptographic Failures (previously sensitive data exposure), and Broken Access Control (BAC). Today, we will focus on Injections and Broken Access Control.

Injections

SQL is the most common Database software that is used, and hosts a plethora of payment data, PII data, and internal business records.

A SQL Injection is an attack that uses malicious SQL code for backend database manipulation to access information that was not intended to be displayed.

The starting point for this, is a command such as the one below:

This will return ALL rows from the "Users" table, since OR 1=1 is always TRUE. Going further with this, this method will also return passwords if there are any.

Picture an attack like this being performed against a large social media company, or a large e-commerce business, and one can begin to see how much sensitive data can be retrieved with just one command.

Broken Access Control

Broken Access Control (BAC) has risen the ranks on the OWASP top ten from fifth to the most common Web Application Security Risks. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category during OWASP's recent testing.

The most common types of BAC, is Vertical and Horizontal privilege escalation. Vertical privilege escalation occurs when a user can elevate their privileges and perform actions, they should not have access to do.

The CVE-2019-0211, which was an Apache Local Privilege Escalation. This critical vulnerability, from 2019, affected Apache HTTP servers running on Unix systems, especially those utilizing the mod_prefork, mod_worker, and mod_event libraries.

This granted attackers the capability to execute unprivileged scripts, potentially leading to root access and compromising shared hosting services. Exploiting this flaw requires the manipulation of shared-memory regions within Apache's worker processes, which must be done before initiating an Apache graceful restart.

The below is a screenshot of the POC code. As one can see, a certain level of technical ability is required in this respect, however, vertical privilege escalation can just as easily occur when a user's permissions are overly permissive, or not revoked when they leave a business.

This takes us back to the principle of least privilege, a ubiquitous term found throughout the IT world, that is now becoming more commonplace as we realise how crucial web applications have become.

Horizontal Privilege Escalation is when a user gains access to data they are not supposed to have access to, but that data is held at the same level as their own permissions. This can be seen with one standard user accessing the data of another standard user. Whilst this should not be allowed, the privileges are not rising vertical, but spreading horizontally. This is sometimes seen as more dangerous, as it can occur without raising any alerts on security systems.

With BAC becoming ever more present in the last couple of years, it is important to remember:

Solely depending on obfuscation is not a sufficient method for access control.
If a resource is not meant to be accessible to the public, it should be denied access by default.
Developers should explicitly specify allowed access for each resource at the code level, with access denial as the default setting.

Best Practices - Read between the Lines (of code!)

To maintain security, developers need to verify incoming data, implement parameterized queries when interacting with databases, and apply effective session management methods to protect sensitive data. Much of this relies on both the security of web browsers, but also of the back-end security of the web servers delivering web content, leading to a segregation of duties in web security.

The biggest problem that arises here, is that whilst Web Application Firewalls (WAFs), can mitigate these risks, much of the responsibility for secure implementation of web content lands at the feet of the developers who put these sites together. Cybersecurity can often become an afterthought, with functionality being preferred.

Practical Example – Input Validation

Input Validation is the simplest and most effective ways to implement secure coding, in this example to prevent SQL injections.

User Input: The user provides input, for example:

Sanitization: The user input is not directly inserted into the SQL query. It is sanitized and treated as data, not as SQL code.
Query Execution: The SQL query is executed with the user input as a parameter:
As such, the query enters the backend as below:

In this code, the (user_input,) is a tuple containing the user's input. The database driver takes care of escaping and properly handling this input. It ensures that the input is treated as a data value, not executable SQL code.

If the user input contains malicious code, such as "105 or 1=1," it is not executed as SQL. Instead, it's treated as a value to be compared to the UserId in the database.

The database driver automatically handles the escaping of the input, preventing it from affecting the structure of the SQL query or introducing security vulnerabilities.

Web Application Firewalls (WAFs)

A WAF operates at layer 7 of the OSI model, and acts as a reverse proxy, ensuring client traffic passes through the WAF before entering the backend server. The rules or policies on the WAF protect against the documented vulnerabilities that are present in these backend servers and filter out malicious traffic.

There are a plethora of WAFs on the market, and these can all provide a strong defence against the more novel attacks, and contribute well to a defence in depth approach, the practice of secure coding is something that ensure the foundations of the web application is secure and will not fall victim to more complex or novel attacks in the future.

WAFs are currently moving towards a mixture of security model that use behavioural-analysis technologies to detect malicious threats, and further mitigate against the threats of more advanced 'bots' which have been leveraged for low-effort attacks on websites.

The main drawback of using a WAF, aside from the added latency and HTTP overhead, is the fact that a WAF can be bypassed by using a 0-day exploit against a web application, which secure coding and correct sanitisation can mitigate against more effectively that offsetting all Web application security to a WAF. It is important to remember a WAF is simply a layer of security, and not the entire solution.

Incident Response and Recovery

SecurityHQ's suggestions to mitigate against attacks:

Employing a WAF as a first line of defence is critical to ensure business can defend against a large volume of attacks.
Ensure up-to-date and strong standard algorithms and protocols are in use, this should be paired with proper key management.
Encrypt data in transit with secure protocols such as TLS with forward secrecy (FS) ciphers, cipher prioritization by the server. Enforce encryption using directives such as HTTP Strict Transport Security (HSTS).
Enable bot management strategies on websites and have a documented incident response plan.
Ensure secure development practices are in place, with a documented process of testing new features on web applications and ensure input validation is deployed.