Comprehensive Kali Linux Tutorial: Mastering Web Application Security and Reflected XSS Attacks

 

1. Course Overview

 

This Kali Linux tutorial is a hands-on course designed to help you learn through practical labs. To explain certain operations in the labs, theoretical concepts are also included. Moreover, we will suggest carefully selected articles to strengthen your theoretical foundation while you engage in hands-on practice.

Note: Due to the high cost of configuration, the number of cloud-based virtual machines for the exercises is limited. Each experiment is restricted to a maximum of six attempts.

2. Learning Approach

 

The Kali Linux course series on the Experiment Platform consists of five training camps. This particular camp focuses on web application attack methods. The course includes 20 labs, all accompanied by detailed steps and screenshots. It’s suitable for learners with some basic knowledge of Linux systems who want to quickly get started with Kali penetration testing.

The recommended approach is to practice extensively and ask plenty of questions. Start the experiments, follow the steps provided, and understand the details of each step as you move forward.

If recommended reading material is provided at the beginning of the experiment, make sure to read it thoroughly before proceeding. Theoretical knowledge is a critical foundation for practical implementation.

3. Content Outline for This Lesson

 

This experiment introduces the concept of Kali Linux and penetration testing. You will need to complete the following tasks in order:

• Introduction to Reflected XSS
• Implementation of Reflected XSS
• Prevention of Reflected XSS

4. Recommended Reading

 

For this experiment session, the following resources are recommended:

1. Introduction to XSS
2. Session Management Cheat Sheet

5. Reflected XSS

 

5.1 Introduction to Reflected XSS

 

In the previous experiment, we learned what XSS attacks are and explored their classification.

So, what exactly is Reflected XSS?

Reflected XSS, also known as Non-Persistent XSS, refers to a type of JavaScript injection that does not modify anything on the server. This means that other users visiting the webpage will not be affected. However, when users access a specific URL crafted by an attacker, they can be “compromised.”

Essentially, by modifying a URL, attackers can execute specific commands to extract sensitive information.

5.2 Introduction to DVMA

 

Simply providing text definitions and explanations can be overly abstract and hard to grasp. To better understand these concepts, we will use a platform like DVMA.

DVMA stands for Damn Vulnerable Web App. It’s a platform specifically designed for learning web penetration techniques. It provides a controlled environment featuring intentional vulnerabilities to help users test and understand attack methods and their underlying principles.

In our experimental setup, this platform is pre-installed. To get started, simply launch the Metasploitable2 virtual machine.

On the experiment desktop, double-click the Xfce terminal to open it:

Run the sudo virsh start Metasploitable2 command to initiate the virtual machine system:

Wait until the virtual machine is fully initialized. Then, open Firefox from the desktop:

Access the virtual machine system using its IP address: 192.168.122.102:

After successfully launching the system, visiting the IP address will display the following page:

It provides the following features:

• TWiki: A flexible and powerful wiki system
• phpMyAdmin: Essential because the DVWA platform uses a PHP/MySQL framework
• Mutillidae: Similar to DVWA, it includes the 10 most common web application vulnerabilities
• DVWA: A platform showcasing common web vulnerabilities

Clicking on DVWA takes you to its login page. By default, the username and password are admin and password. After logging in, you’ll access a page like this:

The platform provides demonstrations of all common web vulnerabilities:

By adjusting the security levels, you can enhance your understanding of attack vectors and develop corresponding defensive measures.

First, to enable the simplest attacks, we will set the security default to the lowest level. Begin by navigating to the security mode adjustment page:

Then, adjust the security level to “low”:

If you notice that the “Level” displayed at the bottom of the page has changed, it means the modification was successful:

6. Practical Exercises with DVWA

 

Select the “XSS Reflected” option, and you’ll be taken to a platform provided by DVWA for experimenting with reflected XSS attacks:

This scenario mimics situations we encounter on forums, e-commerce platforms, academic systems, and so forth, where we fill out forms to update information, log in, or perform validations.

Enter a random string in the text box and click “Submit”:

After submission, you’ll observe the following change:

This is a very basic feature where the username you input is stored by the backend PHP code into a variable. That variable is then sent to the server, where its value is read and displayed as output.

From the changes in the URL, we can see that a variable named “name” is being used. If we manually alter the value of the “name” variable in the URL:

Pressing “Enter” will show that the output displayed on the page has changed:

Below, there is a “View Source” button. By clicking on it, we can examine how this functionality is implemented:

 

We can see from this code snippet that it performs a straightforward check to determine whether the input field contains any value. If the input field is empty, a variable `$isempty` is set to true, and no further actions are performed. However, if the input field contains a value, the code outputs a message of `hello` followed by the user input.

This implies that the PHP code does not apply any filtering or sanitization. As long as the input is not empty, the code will output and execute whatever is provided. So what happens if we input JavaScript code into the field?

Let’s input the following into the text field:

After submitting, you’ll notice that an alert box appears on the page:

This occurs because the page executed our injected malicious JavaScript code. You can also observe the URL changes. If you were to share this URL with someone else and they used it, they’d see the same alert. Try it out if you’re curious.

This is an example of *Reflected Cross-Site Scripting (Reflected XSS). *

Hackers exploit such vulnerabilities to spread malicious URLs far and wide, tricking users into clicking them. Naturally, attackers wouldn’t execute something as simple as an alert box in real-life scenarios.

How is Reflected XSS implemented?

Let’s examine the source code again:

The behavior once the variable is determined to contain a value is as follows:

echo '

 ';
echo 'Hello ' . $_GET['name'];
echo '

‘;

The script uses `echo` to output HTML tags and variables. When the browser parses this output as HTML, it interprets the ``, the PHP backend translates it into the following:

echo '

 ';
echo 'Hello '  ;
echo '

';

Stripping away the PHP syntax, you’re left with:

 
Hello  

 

You can view the resulting HTML using the browser's developer tools (press F12). If the page has no visible content, remember to stop the page from loading.

Here’s how to stop page loading:

Once stopped, locate the code responsible for the alert box:

This is the fundamental mechanics of Reflected XSS. Using such vulnerabilities, attackers can retrieve the user's cookies. For instance, entering `` into the input field and submitting would reveal the following:

Through the stolen cookie, attackers can perform "Man-in-the-Middle" attacks or impersonate the user. This grants access to private information or resources, which can then be exploited to gain profit.

(This image is from HackingLoops)

Man-in-the-Middle Attacks: ...

Would you like to explain more measures this **code sequence aligned's diagnostics

Man-in-the-Middle Attack (MITM): A Man-in-the-Middle attack, abbreviated as "MITM attack," has long been a commonly used and ancient attack method by hackers, and it continues to have extensive potential even today.

In terms of web security, MITM attacks are widely utilized. Techniques such as SMB session hijacking and DNS spoofing, which were rampant at one point, are classic examples of MITM attacks. As hacking techniques are increasingly used to achieve financial gains, MITM attacks have become one of the most threatening and destructive attack methods targeting online banking, online gaming, and e-commerce transactions.

In simple terms, an MITM attack intercepts normal network communication data to manipulate or sniff it, while the communicating parties remain completely unaware. (Source: Baidu Encyclopedia)

7. Preventing Reflected XSS

From the above, it’s evident that the root cause of the XSS vulnerability lies in the ability of the client to execute arbitrary JavaScript code. To prevent such vulnerabilities, you need to prevent this kind of situation from occurring.

First, we adjust our security level to medium:

Next, we try the earlier method of triggering the pop-up dialog:

We will find that it no longer works. The result we obtain looks like this:

It seems that the <script> tag we input has been replaced, preventing the browser from interpreting it as JavaScript code.

Let’s examine the source code:

Compared to the previous code, we notice this change:

echo 'Hello ' . str_replace('<script>', '', $_GET['name']);

The str_replace() function has been applied to the name variable before output.

According to the PHP manual, this function searches for all instances of the <script> string in the variable and replaces them with an empty string, effectively preventing the execution of arbitrary JavaScript code. As a result, the output only consists of the remaining characters in the input value.

However, this countermeasure is insufficient. HTML is a weakly typed language, and even minor syntax errors can execute correctly. Additionally, HTML does not differentiate between uppercase and lowercase. If we replace the script in our input with uppercase letters, such as <SCRIPT>, it can execute normally:

This occurs because the earlier str_replace() function is case-sensitive and fails to filter uppercase variants. Meanwhile, the HTML parser processes the input correctly:

Is there no way to resolve such XSS vulnerabilities? There certainly is! Let's raise the security level to the highest tier:

Here’s the translation of the plain text content in the post, while retaining the original structure and formatting:

---

At this point, if we try again, we’ll find that regardless of uppercase or lowercase input, the browser will no longer parse it as JavaScript code. Instead, it outputs it directly:

Let’s take another look at how the source code changes under these circumstances:

In the source code, we can see that str_replace() was replaced with htmlspecialchars().

The purpose of htmlspecialchars() is to escape all special characters in the provided variables. For example, commonly used special characters are escaped as follows:

Character	Escaped
& (ampersand)	&
” (double quote)	"
‘ (single quote)	'
< (less than)	<
> (greater than)	>
/	/

Inserting JavaScript code requires using the <script> tag, which depends on the special characters < (less than) and > (greater than).

After applying this function for escaping, the browser will process the code as follows:

 <SCRIPT> alert("nihao,shiyanlou")</SCRIPT>

Such code will not be interpreted by the browser as JavaScript. Instead, the browser will output the corresponding character encoding, displaying it as normal content. This prevents arbitrary injection of <script> tags while still allowing content to display properly.

This is Reflective XSS:

• Purpose: Enables attackers to arbitrarily inject and execute JavaScript code, thereby gaining access to cookies. This allows impersonating users, viewing sensitive data, and carrying out man-in-the-middle attacks.
• Cause: Variables submitted via GET are not filtered correctly.
• Characteristics: Propagates through the URL, as GET variables are included in the URL.

8. Summary

 

In this experiment, we learned the following. If you have any unclear points, feel free to discuss them with us in the Shiyanlou Q&A section:

• An introduction to Reflective XSS.
• How to implement Reflective XSS.
• How to defend against Reflective XSS.

Be sure to practice these steps yourself. It’s easy to understand by reading, but the real challenges arise when performing the tasks, and solving these problems is where the real learning occurs.

9. Exercises

 

1. For those who haven’t learned PHP, try defensive measures at the medium level and see if you can obtain cookies.
2. For those familiar with PHP, create a simple form submission locally and check if such vulnerabilities exist.
3. Use Mutillidae to implement a Reflective XSS attack.

When accessing the target machine’s IP address, select the Mutillidae option to enter the page. The XSS experiment environment can be found at:

Perform a Reflective XSS attack in this environment.