This is a capture the flag (CTF) webapp designed to teach software developers the fundamentals of application security (AppSec). Software developers learn best when reading and writing code. Most CTFs are catered towards pentesters who predominantly use a variety of tools for CTFs and in their day jobs. While certainly a more efficient approach, this does not, however, translate well for a software developer trying to learn AppSec.
How is a software developer supposed to learn how to write secure code if all they learn how to do from a CTF is click a few buttons and enter some input into a text field? That is why the purpose of this CTF is to reframe the concept of AppSec in terms of code.
There are 3 hints for every challenge. One hint will show you the exact code of the server-side vulnerability that you are trying to exploit. It is one thing to read a description of a vulnerability, and a whole another thing to actually see a working example of the code. Another hint will show you the exact code of the exploit and how to run it. Technically this is less of a hint and more just the answer to how to solve the challenge, but let's not get too hung up on semantics.
The next logical step is to provide the diff between what the vulnerable code looks like and what the secure code looks like. This is accessible to anyone who solves the challenge, which considering the exploit is provided if you cannot figure out how to write it on your own, is literally anyone.
And finally, as if this wall of text wasn't long enough, there is even more to it. If you want to run the webapp locally just follow the instructions on this README. Make any modifications you want. Add code, remove code, break things, figure out how to fix them. This is what I believe to be the most effective way for a developer to learn a concept: through code.
Never assume user input is safe. HTML form data can contain all sorts of things that you as a developer don't expect!
SQL injection is when an attacker can trick the server into running attacker-supplied SQL code against its database. For example, suppose you are an elite hacker mom . You name your son Robert'); DROP TABLE Students;-- and send him off to school.
If your son's school has a server that is vulnerable to SQL injection, then when they go to add your son as a student in the school's database this is the SQL query that is run:
INSERT INTO Students VALUES ' Robert '); DROP TABLE Students; -- ');
Black text is SQL code
Red text is data from the user
Green text is a comment
The intended result is for an insert statement to be executed. However, because the school is vulnerable to SQL injection, what happens is that the insert statement is executed, and then a drop statement is subsequently executed.
In plain English: a student named Robert gets added to the list of students at the school, and then that list of students is subsequently deleted. This is how the student records are lost for the year. What would the SQL query look like if the school wasn't vulnerable to SQL injection?
INSERT INTO Students VALUES ' Robert'); DROP TABLE Students;-- ');
In early 2021, the social media platform Gab fell victim to a SQL injection attack that exposed users' private messages, posts, and passwords. SQL injection is probably the most well-known web vulnerability out there. It has been in the spotlight since the early 2010s. Yet despite that, it still remains a potent threat even a decade later.
If you are unsure on how to proceed, then the following may help:
You can enter the input necessary to exploit this challenge manually through your browser, or you can use an automated tool such as Burp Suite or OWASP ZAP. However, since this CTF is focused specifically on the code side of application security, neither of those solutions will be presented here.
The exploit code and instructions on how to run it is presented in the third hint. However, you are encouraged to attempt to write the exploit code yourself before looking at the answer. In order to do this, you need to understand what fields are being set in the HTTP request being sent to the server from the browser. This is so that you can craft your own HTTP request from the script you write. You can use your browser's developer tools to figure out this information or you can use a tool that can decrypt encrypted traffic on your computer. Burp Suite and OWASP ZAP both offer this feature in addition to their automated pentesting. I personally used mitmproxy when writing the exploit scripts for this site because it has a lot fewer features than those other tools, and therefore is a lot simpler to use.
File truncated for brevity. Click here to view full file.
You know there is a user with the username administrator. Try to figure out how to log in as administrator without knowing what their password is!