Web Gauntlet ~ CyLab Security Academy CTF Write-up | SQL Injection and Filter Bypass

Author: Affanhaxor Platform: CyLab Security Academy Challenge: Web Gauntlet Category: Web Security Topic: SQL Injection, Authentication Bypass, Input Filtering

Introduction

Web Gauntlet is a web security challenge that demonstrates how SQL injection can affect login functionality. The challenge consists of multiple rounds, and each round introduces additional restrictions on the characters or keywords that can be used in an input.

The main objective is to understand how the application processes login credentials and how SQL queries can behave unexpectedly when user input is not handled safely.

This challenge highlights an important lesson: filtering a few SQL keywords or special characters is not a reliable way to prevent SQL injection.

The challenge begins with a login page labeled Round 1 / 5. The page provides username and password fields along with a sign-in button.

The challenge requires completing five rounds. Each successful round advances to the next stage, where the input filtering rules become more restrictive.

Round 1: Understanding the SQL Query

The first step is to understand how the application handles the username and password fields.

A vulnerable login implementation may construct a SQL query by directly concatenating user input:

SELECT * FROM users
WHERE username='USER_INPUT'
AND password='PASSWORD_INPUT';

SELECT * FROM users
WHERE username='USER_INPUT'
AND password='PASSWORD_INPUT';

If the application inserts input directly into the query, specially crafted values may change the query's original meaning.

In this round, I examined the response after submitting input and observed that the application displayed information about the filtering rules.

The key takeaway from this stage is that user-controlled input should never be treated as trusted SQL syntax.

Round 2 : Identifying Additional Filters

After successfully completing the first round, the application advanced to Round 2.

The filtering rules now included additional SQL-related keywords and symbols. This made the challenge more difficult because some of the techniques that might work in a basic SQL injection scenario were no longer available.

The application displayed a message confirming progression to the next round.

This stage demonstrates why SQL injection testing requires understanding the exact query structure and how the application filters input.

Round 3: Handling More Restrictions

Round 3 introduced further restrictions on SQL keywords and operators.

The application's response showed that the filter was becoming more restrictive with each stage. Rather than relying on a single keyword, the challenge required analyzing how different characters and expressions were interpreted.

The next login attempt successfully advanced the challenge.

This round highlights a common weakness in blacklist-based security: developers may block specific strings without addressing the underlying issue of unsafe query construction.

Round 4: Analyzing the SQL Statement

In Round 4, the challenge introduced another restriction involving the admin keyword.

The application displayed part of the SQL query, making it easier to understand how the submitted username and password were incorporated into the statement.

For example, a query constructed through string concatenation could resemble:

SELECT * FROM users
WHERE username='admin'
AND password='user_input';

SELECT * FROM users
WHERE username='admin'
AND password='user_input';

The exact query depends on the application's implementation, but the important point is that user input should not be able to alter SQL syntax.

After submitting the appropriate challenge input, the application confirmed progression.

Round 5: Final Filter

The final round introduced additional restrictions, including filtering related to the UNION keyword and the admin string.

The login interface displayed Round 5 / 5, indicating that the challenge had reached its final stage.

Technical Explanation

The challenge is based on SQL injection, a vulnerability that occurs when an application incorporates untrusted input directly into a SQL query.

A vulnerable query might look like:

SELECT * FROM users
WHERE username='$username'
AND password='$password';

SELECT * FROM users
WHERE username='$username'
AND password='$password';

When user input is concatenated into the query, an attacker may be able to change its logical structure.

The challenge progressively blocks different SQL keywords and characters to demonstrate how filters can make exploitation more difficult.

However, blacklist-based filtering is not a reliable security control. Attackers may find alternative expressions or syntax that are not covered by the filter.

The correct solution is to prevent user input from being interpreted as SQL code in the first place.

Security Lessons

This challenge demonstrates several important web application security concepts:

SQL injection can lead to authentication bypass.
User-controlled input must not be directly concatenated into SQL statements.
Blocking keywords such as OR, UNION, or comment characters does not reliably prevent SQL injection.
Error messages and query output can reveal useful information about the backend implementation.
Authentication logic should be implemented using secure database access patterns.

Recommended Mitigations

Developers should use the following practices to prevent SQL injection:

1. Use Prepared Statements

Parameterized queries separate SQL instructions from user-provided data.

Example using Python:

cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password)
)

cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password)
)

The database treats the supplied values as data rather than SQL code.

2. Avoid Blacklist-Based Filtering

Do not rely on blocking specific keywords or characters. SQL injection prevention should be handled at the database query layer.

3. Store Passwords Securely

Passwords should be stored using a strong password hashing algorithm such as Argon2id, bcrypt, or scrypt. They should never be stored as plaintext or reversible encrypted values.

4. Apply Least Privilege

The database account used by the web application should have only the permissions required for its tasks.

5. Avoid Revealing SQL Details

Production applications should not expose SQL queries, database errors, or internal authentication logic to users.

Conclusion

Web Gauntlet was a useful exercise in understanding SQL injection and input filtering. Each round introduced additional restrictions, demonstrating how vulnerable login logic can be challenged even when certain keywords are blocked.

The most important lesson is that filtering SQL keywords is not a substitute for secure query construction. Prepared statements, proper password handling, and least-privilege database permissions are essential for protecting authentication systems.

This challenge reinforces the importance of testing web applications carefully and fixing the root cause of SQL injection rather than relying on temporary filters.

Connect With Me

LinkedIn: https://www.linkedin.com/in/affanhaxor

Instagram: https://instagram.com/affan_haxor

Follow me for more CTF write-ups, web security labs, and AppSec content.

Contents