SQL INJECTION

**SQL Injection (SQLi)** is one of the oldest, most common, and most dangerous vulnerabilities in web hacking. It happens when an application takes user input (like a username or search term) and incorrectly uses it to build a database query without properly cleaning it first. This allows an attacker to "inject" their own SQL code into the command, tricking the database into executing unintended instructions. ## How It Works (The Core Concept) Imagine a standard login form. When you type in your username, the backend server runs a query that looks something like this: ```sql SELECT * FROM users WHERE username = 'USER_INPUT' AND password = 'PASSWORD_INPUT'; ``` ### The Normal Scenario If you type john_doe, the database looks for a user named john_doe. If the password matches, you get in. ### The Hacker Scenario An attacker enters this into the username field: admin' OR '1'='1 Because the application doesn't sanitize the input, the database query becomes: ```sql SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = '...'; ``` **Why this breaks the system:** In SQL, '1'='1' is always **true**. Because of the OR operator, the entire database query evaluates to true, completely bypassing the password check. The database willingly hands over access to the admin account. ## Types of SQL Injection Hackers classify SQLi based on how they extract data from the server: | Type | How it Works | Danger Level | |---|---|---| | **In-Band (Classic)** | The attacker uses the same channel to launch the attack and gather results. (e.g., the stolen data prints directly on the webpage). | **High** (Fast and easy to exploit) | | **Inferential (Blind)** | The data isn't printed on the screen. The attacker has to ask the database true/false questions and watch how the page changes, or force the database to pause (Time-based) to reconstruct the data. | **High** (Slower, but just as destructive) | | **Out-of-Band** | Used when the server is too secure to show results or behave differently. The attacker triggers the database to send the stolen data to a server they control via DNS or HTTP requests. | **Critical** (Rare, but bypasses many defenses) | ## What a Hacker Can Do with SQLi Once an attacker finds a SQL injection vulnerability, they can often control the entire database. This allows them to: * **Bypass Authentication:** Log into accounts without knowing passwords. * **Data Exfiltration:** Steal sensitive data (credit cards, SSNs, passwords, personal records). * **Data Modification:** Change balances, alter grades, or delete entire databases (dropping tables). * **Remote Code Execution:** On misconfigured systems, hackers can use the database to write malicious files to the server's OS, taking over the entire web server. ## How to Prevent SQL Injection SQLi exists because the database confuses **code** with **data**. The only way to stop it is to keep them strictly separated. ### 1. Use Parameterized Queries (Prepared Statements) This is the gold standard defense. Instead of gluing user input directly into the SQL string, you use placeholders. The database treats user input strictly as a literal value, never as executable code. * **Vulnerable (PHP):** $db-query("SELECT * FROM users WHERE name = '" . $_GET['name'] . "'"); * **Secure (PHP):** ```php $stmt = $db-prepare('SELECT * FROM users WHERE name = :name'); $stmt-execute(['name' =$_GET['name']]); ``` ### 2. Input Validation and Sanitization Ensure that input matches expected formats (e.g., ensuring an age field only contains integers) and filter out characters like ' or --. However, this should only be a secondary line of defense, not the main fix. ### 3. Principle of Least Privilege Ensure the database account used by the web application only has the permissions it absolutely needs. If the web app only needs to read data, don't give its database user DROP or ALTER permissions. Are you learning about SQL injection to secure a web application you're currently building, or are you exploring ethical hacking and penetration testing? ``` ```