SQL Injection Explained Simply

SQL Injection Explained Simply 💉 | by loopXvedant - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original SQL Injection Explained Simply 💉 The vulnerability that has been breaking databases since the internet began. loopXvedant Follow ~6 min read · March 22, 2026 (Updated: March 22, 2026) · Free: Yes SQL Injection is one of the first vulnerabilities I ever learned about. I remember reading about it and thinking — wait, you can just type something into a login form and get into someone's database? That's it? Yes. That's it. And despite being decades old, SQL Injection still shows up in real applications today — including large, well-known ones. It's been in the OWASP Top 10 for years for a reason. If you're learning web security or bug bounty hunting, this is one of the most important vulnerabilities to understand deeply. Not just what it is — but how it works, why it happens, and what the different types look like. Let's break it down. 🗄️ What Is SQL Injection? To understand SQL Injection, you first need to understand what SQL is. SQL (Structured Query Language) is the language used to interact with databases. When you log into a website, search for something, or view a product — there's almost certainly a SQL query running behind the scenes. A typical login query looks something like this: SELECT * FROM users WHERE username = 'vedant' AND password = 'mypassword'; This says: "Find me the user where the username is 'vedant' and the password is 'mypassword'." If a match is found — you're logged in. Simple. Now here's where SQL Injection happens. If the application takes your username input and directly inserts it into that query without sanitizing it first , an attacker can manipulate the query by injecting their own SQL code. Instead of typing a real username, they type: ' OR '1'='1 The query becomes: SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''; Since '1'='1' is always true — the query returns results regardless of the password. The attacker is now logged in without valid credentials. That's SQL Injection in its simplest form. 💥 Type #1 — Classic SQL Injection (Error-Based) Classic or error-based SQLi is the most visible type — the database throws an error message that reveals information about its structure. How to spot it: Enter a single quote ' into any input field — a search box, a login form, a URL parameter. If the application returns a database error like: You have an error in your SQL syntax near ''' at line 1 or ORA-00907: missing right parenthesis That's a strong indicator of SQL Injection vulnerability. The application is passing your input directly into a SQL query without sanitization — and your quote broke the query syntax. Why it matters: Error messages often reveal the database type, table names, and query structure — giving an attacker a detailed roadmap of the backend. Where to test: Login forms Search bars URL parameters ( ?id=1 , ?page=about , ?product=shoes ) Any input that interacts with the backend 🙈 Type #2 — Blind SQL Injection Blind SQLi is trickier — the application doesn't show error messages, but it's still vulnerable. Instead of reading errors, the attacker infers information from how the application behaves differently based on true or false conditions. Boolean-based Blind SQLi: The attacker sends two requests: ?id=1 AND 1=1 → Page loads normally (true condition) ?id=1 AND 1=2 → Page behaves differently (false condition) If the page responds differently based on these conditions — the application is vulnerable. The attacker can then extract data one bit at a time by asking true/false questions to the database. ?id=1 AND SUBSTRING(username,1,1)='a' "Is the first character of the username 'a'?" — if yes, page loads. If no, it doesn't. Repeat this process character by character and you can extract the entire database without a single error message appearing. Why it's dangerous: Blind SQLi is harder to detect but just as impactful as classic SQLi. Automated tools can extract entire databases using this method. ⏱️ Type #3 — Time-Based SQL Injection Time-based SQLi is a variation of blind SQLi where the attacker uses database delay functions to infer information. Instead of looking at whether a page loads or not, they look at how long the response takes. Example (MySQL): ?id=1 AND SLEEP(5) If the application is vulnerable, the response will be delayed by 5 seconds. No visible change on the page — just a pause. Then to extract data: ?id=1 AND IF(SUBSTRING(username,1,1)='a', SLEEP(5), 0) "If the first character of username is 'a', wait 5 seconds. Otherwise respond immediately." By measuring response times, the attacker extracts data character by character — completely silently. Different databases use different functions: MySQL: SLEEP(5) Microsoft SQL Server: WAITFOR DELAY '0:0:5' PostgreSQL: pg_sleep(5) Oracle: dbms_pipe.receive_message('a',5) 🔗 Type #4 — Union-Based SQL Injection Union-based SQLi uses the SQL UNION operator to append an additional query to the original one — allowing the attacker to retrieve data from other tables in the database. How it works: The original query might be: SELECT name, price FROM products WHERE id = 1; The attacker injects: ?id=1 UNION SELECT username, password FROM users-- The combined query becomes: SELECT name, price FROM products WHERE id = 1 UNION SELECT username, password FROM users--; Now the application returns both product data and usernames and passwords from the users table — displayed right on the page. Requirements for Union-based SQLi: The number of columns in both queries must match The data types must be compatible The results must be displayed somewhere on the page Finding the number of columns: ?id=1 ORDER BY 1-- → works ?id=1 ORDER BY 2-- → works ?id=1 ORDER BY 3-- → error → there are 2 columns Union-based SQLi is powerful because it allows direct data extraction when results are visible in the application's output. 🤖 SQLMap — Automating SQL Injection Testing SQLMap is an open-source tool that automates the detection and exploitation of SQL Injection vulnerabilities. For authorized testing, it's incredibly powerful. Instead of manually crafting payloads, SQLMap does it automatically. Basic usage: sqlmap -u "https://target.com/page?id=1" With a specific parameter: sqlmap -u "https://target.com/page?id=1" -p id Dump the database: sqlmap -u "https://target.com/page?id=1" --dbs sqlmap -u "https://target.com/page?id=1" -D database_name --tables sqlmap -u "https://target.com/page?id=1" -D database_name -T users --dump With cookies (for authenticated pages): sqlmap -u "https://target.com/page?id=1" --cookie="session=yourtoken" Important flags to know: --level=5 — increases testing depth --risk=3 — increases risk of tests (use carefully) --random-agent — randomizes User-Agent to avoid WAF detection --batch — runs without asking for confirmation (automation mode) ⚠️ Only use SQLMap on targets you have explicit permission to test. Unauthorized use is illegal. 🛡️ How SQL Injection Is Prevented Understanding prevention is just as important as understanding the attack. Parameterized Queries (Prepared Statements) This is the gold standard fix. Instead of building queries by concatenating user input, the query structure and data are sent separately: # Vulnerable query = "SELECT * FROM users WHERE username = '" + username + "'" # Safe — parameterized cursor.execute("SELECT * FROM users WHERE username = ?", (username,)) The database treats the input as pure data — no matter what the user types, it can never be interpreted as SQL code. Input Validation & Sanitization Never trust user input. Validate that inputs match expected formats before processing them. Web Application Firewalls (WAF) WAFs can detect and block common SQLi patterns — but they're not a replacement for proper parameterized queries. Least Privilege Database accounts used by web applications should have only the permissions they need — not full admin access. If injection does occur, the damage is limited. 🏁 Final Thoughts SQL Injection has been around since the early days of the web. It's one of the oldest and most well-documented vulnerabilities in existence. And it still gets found in real applications. Every year. On large companies. On government websites. On platforms used by millions of people. Why? Because developers make mistakes. Because legacy code exists. Because not everyone follows secure coding practices. That's why understanding SQLi deeply matters — whether you're a bug bounty hunter looking for your next finding, or a developer who wants to make sure their application never ends up on someone's vulnerability report. Learn it. Practice it on platforms like PortSwigger Web Academy and DVWA. And always test responsibly. 💉 Found this useful? Follow for more beginner-friendly cybersecurity content. Drop a comment with which type of SQLi surprised you the most. 🙌 ⚠️ Disclaimer: All techniques described in this blog are for educational purposes and authorized security testing only. Never test on systems you don't have permission to test. Always practice on legal platforms like PortSwigger Web Academy, DVWA, or TryHackMe. ☕ Support My Work If you enjoy my content, you can buy me a coffee here: Buy me a Coffee #sql-injection #sql #bug-bounty #hacking #cybersecurity Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).