🌐 Web Application Security Learning Journey: SQL Injection & Cross-Site Scripting (XSS)

After practicing networking, reconnaissance, port scanning, service enumeration, and vulnerability scanning, I decided to take the next step in my cybersecurity learning journey: Web Application Security.

This practice session focused on understanding two of the most well-known web application vulnerabilities:

💉 SQL Injection (SQLi) 🕸️ Cross-Site Scripting (XSS)

For this hands-on learning exercise, I used DVWA (Damn Vulnerable Web Application) in my own controlled laboratory environment.

The objective was not simply to enter payloads and observe results. I wanted to understand why the application behaved differently, how input validation affected security, how information could be exposed, and why developers need proper defensive mechanisms.

⚠️ Disclaimer: All activities described in this repository were performed in an intentionally vulnerable DVWA environment for educational and authorized security training purposes only.

🎯 Learning Objectives

During this practice, my goals were to:

• Understand how user input interacts with a web application.
• Learn the basic concept behind SQL Injection.
• Observe how SQL queries can behave unexpectedly when input is not properly handled.
• Understand reflected Cross-Site Scripting.
• Compare different security levels and filtering mechanisms.
• Learn how source code review can help you understand vulnerabilities.
• Extract information in a controlled lab environment.
• Understand why secure coding practices are important.

🛠️ Lab Environment The following environment was used during this practice: Operating System: Kali Linux Target Application: Damn Vulnerable Web Application (DVWA) Browser: Mozilla Firefox Target IP: 10.6.6.13 Practice Type: Controlled and authorized lab environment

NOTE: Download Kali from the Cisco resource site so you do not need to set up DVWA and all other machines by yourself; it is built in that package.

DVWA is intentionally designed for security learning and allows students to understand common web vulnerabilities under different security configurations.

💉 Part 1: SQL Injection

📖 What is SQL Injection?

SQL Injection is a vulnerability that can occur when an application takes user-controlled input and places it into a database query without proper validation or parameterization.

In a vulnerable situation, the application's intended query logic may be altered by specially crafted input.

For example, a normal application may internally perform a database lookup similar to:

SELECT first_name, last_name FROM users WHERE user_id = '<user_input>';

If user input is not handled securely, the database query may behave differently from what the developer originally intended.

My goal during this lab was to observe this behavior step by step.

🔎 Step 1: Testing the Normal Input

I first interacted with the SQL Injection page using normal values.

The application accepted a User ID and returned the corresponding user information.

This established a baseline and helped me understand the expected behavior of the application before testing any security issues.

🔓 Step 2: Testing Authentication/Query Logic

The next stage was to test how the application responded when special SQL characters were introduced into the input.

During the lab, I observed that changing the input structure could affect the application's query processing.

For example, the screenshots show testing involving SQL expressions such as:

' OR 1=1 #

The application returned multiple records instead of behaving like a normal single-user lookup.

This demonstrated an important security concept:

If an application directly trusts user input while constructing a database query, the user may influence the logic of that query.

📊 Step 3: Understanding Query Behavior

I continued experimenting with SQL expressions to understand how the application processed the supplied input.

One of the key observations was that a logical condition that always evaluates as true could change the application's behavior.

This helped me understand that SQL Injection is not simply about "breaking into a database." At a fundamental level, it is about:

Untrusted input changes the meaning of an application's database query.

That was one of the most important lessons from this practice.

🧪 Step 4: Using ORDER BY

I then practiced using an ORDER BY clause to better understand the structure of the underlying query.

The screenshots show testing with values similar to:

' ORDER BY 1 #

and other column positions.

At one point, increasing the number produced an error similar to:

Unknown column '3' in 'order clause'

This was a useful learning moment.

The error suggested that the application was attempting to process the supplied SQL syntax. In a real security assessment, error messages can sometimes reveal useful information about the application's backend.

🗄️ Step 5: Database Information Discovery

After understanding the basic query behavior, I practiced retrieving information about the database in the lab environment.

The screenshots show testing with database functions such as:

VERSION()

and:

DATABASE()

This demonstrated how SQL database systems contain functions that can provide information about the database environment.

During the lab, the application displayed the database version and database name.

This was an important lesson because exposed database information can help an attacker better understand the target environment.

📋 Step 6: Exploring Database Metadata

Next, I learned about the concept of information_schema.

Modern relational databases maintain metadata about databases, tables, and columns.

In the controlled DVWA environment, I practiced querying metadata to understand:

Available databases Table names Column names

The screenshots show exploration of database metadata and the discovery of tables related to the DVWA application.

🧱 Step 7: Identifying Columns

After identifying the relevant table, I continued the lab by exploring its column structure.

The screenshots show the discovery of columns including information such as:

user password user_id first_name last_name

This step demonstrated why database metadata protection is important.

If an attacker can successfully manipulate a vulnerable query, they may eventually gain access to information that the application never intended to expose.

🔐 Step 8: Understanding Sensitive Data Exposure

In the final SQL Injection stages of my practice, I observed how data stored in the users table could be returned by the vulnerable application.

The lab demonstrated the risk of exposing sensitive information, including usernames and password hashes.

The important point here was that the passwords were represented as hashes rather than plaintext. This introduced another learning topic: password hashing and offline password security.

For example, one of the observed hashes was tested separately in a password-hash cracking demonstration within the lab workflow.

🕸️ Part 2: Reflected Cross-Site Scripting (XSS)

📖 What is Reflected XSS?

After practicing SQL Injection, I moved to Reflected Cross-Site Scripting (XSS).

Reflected XSS occurs when an application receives user-controlled input and immediately includes that input in the server response without properly encoding or sanitizing it.

A simple example is a web application that displays:

Hello <user_input>

If the application does not safely handle special characters and HTML or JavaScript-related input, the browser may interpret the supplied content differently from plain text.

🧪 Step 1: Testing Normal Application Behavior

I first entered a normal name into the DVWA XSS page. The application responded with a greeting similar to:

Hello Jimmy

This gave me a baseline for understanding the intended behavior of the page.

🔍 Step 2: Testing Script-Based Input

Next, I tested how the application handled script-related input. The screenshots show attempts involving HTML and JavaScript-related characters. At lower security configurations, the application did not properly protect the reflected input, demonstrating how unsafe output handling can allow browser-side code execution.

An alert was successfully triggered during the controlled lab exercise.

⚙️ Step 3: Reviewing the Application Source

One of the most useful parts of this exercise was reviewing the DVWA source code.

The source showed how the application processed the name parameter.

At one security level, the code used filtering logic similar to removing specific

This taught me an important lesson:

Blocking one specific malicious pattern is not the same as securely handling untrusted input.

Security filters that only look for a particular keyword or tag may be bypassed by alternative representations or unexpected input formats.

🛡️ Step 4: Comparing Security Levels

I continued testing the application at different DVWA security levels.

The screenshots demonstrate that the behavior of the application changed depending on the configured protection level.

At higher security levels, certain characters and patterns were filtered using regular expressions.

This was particularly interesting because it demonstrated the limitations of blacklist-based filtering.

For example, filtering one dangerous keyword does not necessarily guarantee that all dangerous browser behavior is prevented.

The more I practiced, the clearer it became that context-aware output encoding is generally much stronger than trying to maintain a blacklist of every possible malicious input.

🧩 Step 5: Testing Alternative Input Formats

I then continued experimenting with different HTML contexts.

The screenshots show attempts involving image elements and event-handler-style attributes.

This was useful because it demonstrated that browser-side behavior is not limited to only one HTML tag.

A security filter that focuses only on <picture> <source media="(max-width: 768px)" srcset="/img/medium/700/1*_PZr9Yy7p41HfKWLlmOmwA.png 1x"> <source media="(min-width: 769px)" srcset="/img/medium/2000/1*_PZr9Yy7p41HfKWLlmOmwA.png 1x"> <img src="/img/medium/700/1*_PZr9Yy7p41HfKWLlmOmwA.png" alt="None" width="795" height="468" loading="lazy" data-zoom-src="/img/medium/4000/1*_PZr9Yy7p41HfKWLlmOmwA.png" class="prose-image"/> </picture> <picture> <source media="(max-width: 768px)" srcset="/img/medium/700/1*_LNiA7taD34Ymwv-qKMzgg.png 1x"> <source media="(min-width: 769px)" srcset="/img/medium/2000/1*_LNiA7taD34Ymwv-qKMzgg.png 1x"> <img src="/img/medium/700/1*_LNiA7taD34Ymwv-qKMzgg.png" alt="None" width="521" height="155" loading="lazy" data-zoom-src="/img/medium/4000/1*_LNiA7taD34Ymwv-qKMzgg.png" class="prose-image"/> </picture>

🔎 Step 6: Observing Application Responses

During the practice, I observed several possible responses from the application:

The input was reflected normally. Certain parts of the input were filtered. The browser interpreted the input differently. An alert was triggered. The page displayed only part of the supplied input.

These different outcomes helped me understand that web application security testing requires observation and analysis rather than simply trying random inputs.

The context in which input appears matters significantly.

For example, user-controlled data behaves differently when placed inside:

HTML text HTML attributes JavaScript URLs CSS Browser DOM elements

🧠 Key Lessons Learned

This practice session gave me a much deeper understanding of web application security.

1. Never Trust User Input

Both SQL Injection and XSS begin with the same fundamental problem:

The application accepts untrusted input and handles it insecurely.

The vulnerability may occur at different layers, but the root cause is often improper handling of user-controlled data.

2. SQL Injection Can Reveal More Than Data

Before this lab, SQL Injection seemed like a vulnerability mainly related to bypassing authentication.

After practicing it step by step, I understood that SQL Injection can potentially involve:

Manipulating query logic Triggering database errors Discovering database structure Identifying tables Identifying columns Extracting application data

This made me appreciate the importance of prepared statements and parameterized queries.

3. XSS Is About Browser Interpretation

The XSS practice helped me understand that browsers are powerful execution environments.

If user input is inserted into a webpage without proper protection, the browser may interpret that input as code or markup instead of ordinary text.

The security context matters.

A value that is safe in one context may be dangerous in another.

4. Blacklisting Is Not Enough

One of my biggest takeaways from reviewing the DVWA source code was the weakness of simple blacklist filtering.

Trying to remove only specific keywords or tags is risky because there can be multiple ways to represent potentially dangerous browser behavior.

A stronger approach includes:

Context-aware output encoding Proper input validation Parameterized database queries Secure frameworks and APIs Content Security Policy (CSP) HttpOnly and Secure cookie attributes

🛡️ Recommended Defensive Practices Preventing SQL Injection Developers should: Use prepared statements. Use parameterized queries. Avoid building SQL queries through string concatenation. Apply least-privilege permissions to database accounts. Validate input where appropriate. Avoid exposing detailed database errors to users.

Example of a safer approach:

cursor.execute( "SELECT first_name, last_name FROM users WHERE user_id = ?", (user_id,) )

The exact syntax depends on the programming language and database library.

Preventing XSS Developers should: Encode output based on its context. Treat all user-controlled data as untrusted. Use modern templating frameworks safely. Avoid unsafe HTML insertion methods. Implement Content Security Policy where appropriate. Use HttpOnly cookies for sensitive session data. Validate input based on expected formats.

📊 Skills Practiced During this hands-on exercise, I practiced:

Web Application Security SQL Injection -Query Manipulation -Error Observation -ORDER BY Testing -Database Enumeration -Table Discovery -Column Discovery -Data Exposure Analysis

Cross-Site Scripting -Reflected XSS -Input Reflection -Browser Behavior -Security Filter Testing -Source Code Review -Security Level Comparison

🚀 Conclusion

This was an important step in my cybersecurity learning journey.

Moving from network scanning and vulnerability assessment into web application security gave me a different perspective. Network security often focuses on hosts, ports, services, and protocols. Web application security goes deeper into how an application processes data and how trust boundaries can be broken.

The most valuable part of this exercise was not memorizing payloads. It was about understanding the logic behind the vulnerabilities.

For SQL Injection, I learned how insecure database queries can allow untrusted input to influence database operations.

For XSS, I learned how insecure handling of reflected input can cause a browser to interpret user-controlled data as active content.

I also learned the importance of reviewing source code and understanding defensive mechanisms. Seeing the difference between low, medium, and high security configurations helped me understand why some protections work and why others can still have weaknesses.

This is only the beginning of my web application security journey.I will continue documenting my hands-on cybersecurity learning journey, one lab at a time. 🚀

⚠️ Disclaimer This repository documents security testing performed exclusively in an intentionally vulnerable and authorized training environment using DVWA. The techniques were practiced for educational purposes only. Never perform security testing against systems, applications, or networks without explicit authorization.