WAF Capabilities on Handling Common Web App Vulnerability

In the realm of web security, the strategic deployment of a Web Application Firewall (WAF) stands as a pivotal measure to fortify the defense mechanis.

By Jessie Angelica, Solution Architect Intern

In the realm of web security, the strategic deployment of a Web Application Firewall (WAF) stands as a pivotal measure to fortify the defense mechanisms of web applications against an array of cyber threats. Alibaba Cloud WAF (Web Application Firewall) protects your websites and web servers based on the intelligent computing capabilities of Alibaba Cloud Security. WAF provides end-to-end security protection for your websites or apps. WAF identifies, scrubs, filters out malicious web traffic and then forwards regular traffic to your origin servers. This protects your origin servers against attacks and ensures data and service security. Here’s proof of the WAF function to protect the server from attacks in Damn Vulnerable Web Application (DVWA) application.

How to Set Up?
Command Injection
SQL Injection
XSS(DOM)
XSS(Reflected)
XSS(Stored)

How to Set Up?

1) First, open a web browser to access DVWA via the IP address in the address bar.

2) Second, log in to the DVWA by entering the correct username and password.

3) Change the DVWA security level to low. This setting is the lowest level and does not have any security measures.

4) With DVWA set up and running, you can start testing its vulnerabilities.

Command Injection

Command injection is a cyber-attack focusing on injecting and executing commands on Operating System. The attack might have catastrophic results since a hacker could take complete control of the web application if they could run commands on the operating system. This includes stealing data or deleting every single file.

The first command to be executed is a ping. Ping is used to check the response from the host and allows users to test and verify if a specified destination IP address can accept requests in computer network administration. As an example, let's try to ping the IP address 8:8:8:8 in the input section and click submit to get a view of the directory structure.

Figure 1.1. Ping in Command injection attack

Type the IP address followed by the command, eg. 8.8.8.8||whoami. The whoami command is used to see the currently logged-in user.

Figure 1.2. whoami in Command injection attack

Then, to exploit further vulnerabilities found in the DVWA application, we can add the ls -la command is used to view the contents of the directory. Normal users should not be able to see the contents if the application has good security. Let's try to type 8.8.8.8|ls -la in the input section and click submit to get a view of the directory structure.

Figure 1.3. Command injection attack a) without WAF, b) using WAF

The IP address followed by the cat command creates, merges, or displays files in the standard output screen. You can type 8.8.8.8|| cat index.php.

Figure 1.4. Cat in Command injection attack

Repeated use of ../../ sequentially redirects to sequentially higher parent directories. Since we want to retrieve the index.php directory, we must point to the previous one. It is followed by ls -la, and the echo HACKED command is intended to write the text "HACKED" into a file content. Let's try to type 8.8.8.8 | ls -la ../../ | echo "HACKED"> index.php. Successfully, the website is already hacked.

Figure 1.5. The website is hacked in Command injection attack

SQL Injection

SQL injection is malicious SQL queries by exploiting application vulnerabilities. SQL injection is a code injection technique to get important information from your database. This can vary from altered data to total data loss after a malicious actor deleted it. As the input field requires a user ID, we give it to the server. Still, additionally, we append our command (which is constructed according to the database type and version). As the DVWA SQL Injection vulnerability task is to get the users' information, this query will reach the database and return the user list, which is existing users' first names and surnames in this case.

Let's try to type 1' or '1'='1. Since '1'='1' is always true, an attacker could circumvent authentication and log in without needing the correct password.

Figure 2. SQL injection attack a) without WAF, b) using WAF

Xss (Dom)

Cross-Site Scripting (XSS) is an injection attack in which malicious scripts are injected into the website and executed as legitimate ones. The DOM-based XSS happens because the client-side script modifies a DOM environment.

First, there is a selection with different values as the language options, so you must click the select button and then change the "English" to "test”. You can type this URL http://149.129.224.139:4280/vulnerabilities/xss_d/?default=test in the address bar. As a result, the script will fire:

Figure 3.1 XSS (DOM) attack by “test”

You also can change the previous URL in the address bar to

http://149.129.224.139:4280/vulnerabilities/xss_d/?default=[script]alert(document.cookie)[/script] to give the alert

Figure 3.2. XSS (DOM) attack a) without WAF, b) using WAF

XSS (Reflected)

XSS Reflected only executes code with one request. This injection is not persistent; one of the examples of how this can be exploited is when the user is tricked into clicking on a malicious link.

In the form below, you are asked to enter a name, and the input in the form should return the name displayed afterwards, as shown below.

Figure 4.1. XSS (Reflected) by name

However, what if what is included is a Javascript HTML code snippet? For example, you will enter the following code in the form in the input section. What happened was as follows:

Figure 4.2. XSS (Reflected) attack a) without WAF, b) using WAF

This shows that security on the web still allows loopholes for attackers to execute code via the associated request URL. The code displayed from the alert as above is a cookie that applies to our session. Attackers can enter other code, such as inserting code that will take us to a dangerous website if we press the link, executing code that steals data for authentication, and so on.

XSS (Stored)

Stored XSS is permanently stored on the website, and malicious scripts can be executed whenever the user visits the page. XSS Stored "stores" the code in the website database. This means the code will be executed by the person who clicked on the related link and all users who enter the page. For example, suppose a website is vulnerable, and a script is injected into the comments form. In that case, every user's browser will execute it on a page visit.

On this page, the web provides a feature where users can enter names and messages, which then the message will be displayed as shown below. Let's try to type test in the input section of the name and "[script]This is a test comment[/script]

Figure 5.1. XSS (Stored) attack a) without WAF, b) using WAF

In this feature, each name and message input will be stored in the database to display each user's input in other users' browsers. The same data will be displayed whenever the user exits and re-enters this page. Another example, let’s try to type [script]alert(‘Stored XSS Attact’)[/script]

Community

WAF Capabilities on Handling Common Web App Vulnerability

Table of Contents

How to Set Up?

Command Injection

SQL Injection

Xss (Dom)

XSS (Reflected)

XSS (Stored)

Read previous post:

Read next post:

Alibaba Cloud Indonesia

You may also like

Comments

Alibaba Cloud Indonesia

Related Products

Data Security on the Cloud Solution

Security Solution

Web Hosting Solution

Cloud Hardware Security Module (HSM)