🔒 OWASP API Security

Injection Attacks - A Comprehensive Guide

👋 Welcome Amazing Hackers!

This comprehensive guide will walk you through one of the most critical vulnerabilities in API security: Injection Attacks. Understanding these vulnerabilities is essential for both offensive and defensive security practices.

📋 What Are Injection Attacks?

Injection attacks occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

⚠️ Critical Severity

Injection vulnerabilities consistently rank among the top security risks in the OWASP Top 10. They can lead to data loss, corruption, disclosure to unauthorized parties, loss of accountability, or denial of access.

🎯 SQL Injection Demonstration

Basic Login Page Vulnerability

Let's examine a common SQL injection scenario using a basic login form with username and password fields.

The Vulnerable Query

Consider this SQL statement that checks user credentials:

SELECT * FROM users WHERE username = '[USER_INPUT]' AND password = '[PASSWORD_INPUT]'

🔓 The Attack Vector

An attacker can manipulate the input fields to bypass authentication:

Malicious Input:

Username: admin Password: ' OR '1'='1

Resulting SQL Query:

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

Since 1=1 is always TRUE, this query will return all users, effectively bypassing authentication!

🔄 SQL Injection Attack Flow Diagram

Attack Process Visualization

Step 1
User Input
(Malicious Data)
→
Step 2
Unsanitized
Processing
→
Step 3
SQL Query
Execution
→
Step 4
Unauthorized
Access Granted

🛡️ Types of Injection Attacks

The injection vulnerability category extends far beyond SQL. Here are the major types you need to be aware of:

🔹 SQL Injection

Manipulating SQL queries to access or modify database data without authorization.

🔹 Cross-Site Scripting (XSS)

Injecting malicious scripts into web pages viewed by other users.

🔹 LDAP Injection

Exploiting applications that construct LDAP statements from user input.

🔹 Command Injection

Executing arbitrary commands on the host operating system.

🔹 XML Injection

Manipulating XML data to alter application logic or access sensitive information.

🔹 JSON Injection

Injecting malicious JSON data to manipulate application behavior.

🔹 CSV Injection

Embedding formulas in CSV files that execute when opened in spreadsheet applications.

🔹 NoSQL Injection

Exploiting NoSQL databases through unsanitized user input.

💻 Testing for SQL Injection

Here are common test payloads and commands used to identify SQL injection vulnerabilities:

Basic Test Payloads:

' OR '1'='1 ' OR '1'='1' -- ' OR '1'='1' /* admin' -- admin' # ' UNION SELECT NULL--

Using SQLMap for Automated Testing:

sqlmap -u "http://target.com/login.php" --data="username=admin&password=test" --batch sqlmap -u "http://target.com/page.php?id=1" --dbs sqlmap -u "http://target.com/page.php?id=1" -D database_name --tables sqlmap -u "http://target.com/page.php?id=1" -D database_name -T table_name --dump

🔐 Prevention and Mitigation Strategies

1. Parameterized Queries (Prepared Statements)

Always use parameterized queries to separate SQL code from data:

PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?"); stmt.setString(1, username); stmt.setString(2, password);

2. Input Validation

Implement strict input validation and sanitization:

  • Whitelist acceptable input characters
  • Validate data types (numbers, emails, etc.)
  • Limit input length
  • Reject suspicious patterns

3. Stored Procedures

Use stored procedures with proper parameterization:

CREATE PROCEDURE ValidateUser @username VARCHAR(50), @password VARCHAR(50) AS SELECT * FROM users WHERE username = @username AND password = @password

4. Least Privilege Principle

Database accounts used by applications should have minimal permissions:

  • Read-only access where possible
  • No administrative privileges
  • Access limited to required tables only
  • Separate accounts for different application functions

🧪 Developer Console Testing Example

Inspecting the Attack

When testing SQL injection in a browser, you can:

  • Open Developer Console (F12)
  • Change input type from "password" to "text" to see your input
  • Monitor network requests to see how data is transmitted
  • Check for error messages that reveal database structure

Console Command to Change Input Type:

document.querySelector('input[type="password"]').type = 'text';

🎓 Key Takeaways

  • Injection attacks are deep and varied - They extend beyond SQL to include XSS, LDAP, Command, JSON, CSV, and many others
  • Simple vulnerabilities can have severe consequences - A basic SQL injection can compromise entire databases
  • Always validate and sanitize input - Never trust user input, regardless of the source
  • Use parameterized queries - This is the most effective defense against SQL injection
  • Apply defense in depth - Combine multiple security layers for comprehensive protection
  • Regular security testing is essential - Continuously test applications for injection vulnerabilities

📚 Additional Resources

  • OWASP Top 10: https://owasp.org/www-project-top-ten/
  • OWASP API Security Project: https://owasp.org/www-project-api-security/
  • SQLMap Documentation: https://sqlmap.org/
  • OWASP Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
  • PortSwigger Web Security Academy: https://portswigger.net/web-security

🎯 Remember

Security is not a product, but a process. Stay vigilant, keep learning, and always test responsibly!