SQL injection is a popular technique used by attackers to exploit web applications by crafting malicious input and executing arbitrary SQL statements in the backend database. In this lab, we will set up a SQL injection environment use the sqli-labs with docker, and perform hands-on experiments to understand the principles and exploitation methods of SQL injection vulnerabilities.
Welcome to our introductory course on web security testing, specifically focusing on identifying potential SQL injection vulnerabilities. SQL injection is a common and potentially devastating security flaw in web applications, but with the right knowledge, you can learn how to identify and prevent it.
SQL Injection is a technique where an attacker inserts malicious SQL code into a web application's database query. If the web application does not properly sanitize user input, this can lead to data breaches, loss of data, or other serious issues.
Web applications that interact with a database often have URLs that include parameters. These parameters can potentially be exploited if they are not properly sanitized. For instance, you might see a URL that looks like this:
http://some-website.com/page.php?id=XXIn this URL, id is a parameter that interacts with the database. Any web page that uses such parameters could potentially be vulnerable to SQL injection if the input is not properly sanitized.
One simple way to test for SQL injection vulnerabilities is to use the single quote technique. Here's how you do it:
') to the parameter value in the URL. For example, you could change the URL to look like this: http://some-website.com/page.php?id=1'The reason this works is that both numeric and string data types in SQL will generate a syntax error when an unbalanced single quote is introduced. This error can reveal the presence of a SQL injection vulnerability.
If no error is shown when you append a single quote, it doesn't necessarily mean there is no SQL injection vulnerability. It's possible that the application is filtering out single quotes, which would require you to use other techniques to test for vulnerabilities. Don't worry, we'll cover these more advanced techniques in a future lesson.
Remember, ethical hacking is about improving security. Always respect privacy and legality in your testing endeavors. Happy learning!
Great job on identifying potential SQL injection points! Now, let's move on to the next step: determining the type of SQL injection vulnerability. There are two main types we'll focus on: numeric and string-based SQL injection.
When the input parameter (let's call it x) is treated as an integer by the web application, the SQL query might look like this:
select * from <table_name> where id = xTo identify a numeric SQL injection, we use two simple logical conditions: and 1=1 and and 1=2. Here's how:
http://some-website.com/page.php?id=x and 1=1 into your browser. If the page loads as expected, go to the next step.http://some-website.com/page.php?id=x and 1=2. If the page returns an error or behaves differently, it might indicate a numeric SQL injection vulnerability.Why does this work?
When you input and 1=1, the resulting SQL query is:
select * from <table_name> where id = x and 1=1The condition 1=1 is always true, so if the page loads normally, it suggests that the input is being inserted directly into the SQL query.
When you input and 1=2, the resulting SQL query is:
select * from <table_name> where id = x and 1=2The condition 1=2 is always false, so if the page behaves differently (like returning an error), it suggests that our input is affecting the SQL query, indicating a potential SQL injection vulnerability.
In some cases, the input parameter x is treated as a string. The SQL query might look like this:
select * from <table_name> where id = 'x'To identify a string-based injection, we use a similar approach to the numeric injection but with string conditions: and '1'='1' and and '1'='2'. Here's how:
http://some-website.com/page.php?id=x' and '1'='1 into your browser. If the page loads as expected, go to the next step.http://some-website.com/page.php?id=x' and '1'='2. If the page returns an error or behaves differently, it might indicate a string-based SQL injection vulnerability.Why does this work?
When you input and '1'='1', the resulting SQL query is:
select * from <table_name> where id = 'x' and '1'='1'The condition '1'='1' is always true, so if the page loads normally, it suggests that the input is being inserted directly into the SQL query.
When you input and '1'='2', the resulting SQL query is:
select * from <table_name> where id = 'x' and '1'='2'The condition '1'='2' is always false, so if the page behaves differently (like returning an error), it suggests that our input is affecting the SQL query, indicating a potential SQL injection vulnerability.
In both cases, remember that an unusual response from the web application is a hint that you may have found a SQL injection point. However, always ensure you have permission to perform these tests and use your skills responsibly. Happy learning!
In this lab, we'll delve deeper into SQL injection vulnerabilities. Our focus will be on how to exploit these vulnerabilities to circumvent login authentication, a technique often referred to as the "universal password" attack.
To kick things off, we'll need to prepare our lab environment. We'll use the Damn Vulnerable Web Application (DVWA) - a PHP/MySQL web application designed to be intentionally insecure, making it an ideal learning tool for understanding web application security.
Download the sqli-labs Docker Image: The sqli-labs Docker image is available for download on Docker Hub. Use the following command in your terminal to pull it:
docker pull acgpiano/sqli-labsLaunch the sqli-labs Docker Container: After downloading the image, run it using the command below:
docker run -it -d --name sqli-labs -p 80:80 -p 13306:3306 acgpiano/sqli-labsThis command initiates a new container and maps port 80 and 3306 in the container to port 80 and 13306 on your host machine, respectively.
By following these steps, you've successfully set up the necessary lab environment.
After the setup is complete, open Firefox and type in http://localhost into the address bar.
If this is your first time visiting http://localhost, please click on Setup/reset Database for lab to prepare the lab and then refresh the webpage.
You should now see a simple login page when you click on Less-11. Try entering an arbitrary username 123 and password 123.
The error page will inform you "Invalid username or password."
Let's examine the backend code responsible for the authentication process:
// take the variables
if(isset($_POST['uname']) && isset($_POST['passwd']))
{
$uname=$_POST['uname'];
$passwd=$_POST['passwd'];
//logging the connection parameters to a file for analysis.
$fp=fopen('result.txt','a');
fwrite($fp,'User Name:'.$uname);
fwrite($fp,'Password:'.$passwd."\n");
fclose($fp);
// connectivity
@$sql="SELECT username, password FROM users WHERE username='$uname' and password='$passwd' LIMIT 0,1";
$result=mysql_query($sql);
$row = mysql_fetch_array($result);
....
}The actual SQL query that gets executed is:
SELECT * FROM users WHERE username='123' AND password='123' LIMIT 0,1This query is simple to understand: if it returns a row where both the username and password match, then the login is successful.
Building on the knowledge from the previous lab, let's attempt to input the following payload:
Username: 123' or 1=1 #
Password: 123' or 1=1 #
Interestingly, this allows us to log in successfully! The reason for this is that the actual SQL query that gets executed is:
SELECT * FROM users WHERE username='123' or 1=1 #' AND password='123' or 1=1 #'In MySQL, the # symbol is used to comment out the rest of the line, so the query effectively becomes:
SELECT * FROM users WHERE username='123' or 1=1Given that the condition or 1=1 is always true, the query will always return a result, leading to a successful login.
We can also experiment with a variation that doesn't use the comment symbol:
Username: 123' or '1'='1
Password: 123' or '1'='1
The SQL query that gets executed is then:
SELECT * FROM users WHERE username='123' or '1'='1' AND password='123' or '1'='1'In this case, the two or conditions ensure that the and condition between them is always true, leading to a successful login.
As demonstrated above, there are numerous techniques that can be used to exploit SQL injection vulnerabilities and bypass authentication. Feel free to explore and experiment with different payloads. The goal here is to understand these vulnerabilities so that you can better protect your own applications from them. Happy ethical hacking!
In this lab, we learned how to identify SQL injection vulnerabilities by using the single quote technique and how to determine the type of SQL injection (numeric or string-based) using specific payloads. We also explored the exploitation of SQL injection vulnerabilities to bypass login authentication, a common scenario known as the "universal password" attack. By conducting hands-on experiments, we gained practical experience in understanding and exploiting SQL injection vulnerabilities, which are prevalent in web applications if input sanitization is not properly implemented.