Add SQL Injection guide for beginners (#94)

This guide provides a comprehensive overview of SQL injection, its risks, prevention techniques, and secure coding practices for developers.

Author: mihika632

ebook/en/content/sql_injection.md

@@ -0,0 +1,296 @@
+# SQL Injection — A Beginner's Understanding
+
+> **Purpose**: This guide provides beginners with a clear, safe, and practical overview of what SQL injection (SQLi) is, how it happens at a conceptual level, and — most importantly — how to prevent and detect it. It focuses on defensive, responsible practices without providing exploit instructions.
+
+## 📋 Table of Contents
+
+1. [What is SQL Injection?](#1-what-is-sql-injection)
+2. [Why it matters (risks & impact)](#2-why-it-matters-risks--impact)
+3. [High-level types of SQLi (conceptual)](#3-high-level-types-of-sqli-conceptual)
+4. [How SQLi happens — a conceptual example](#4-how-sqli-happens--a-conceptual-example)
+5. [Vulnerable vs. secure code (safe examples)](#5-vulnerable-vs-secure-code-safe-examples)
+6. [Top prevention techniques (detailed)](#6-top-prevention-techniques-practical-prioritized)
+7. [Detection, logging, and monitoring](#7-detection-logging-and-monitoring)
+8. [Secure coding checklist for developers](#8-secure-coding-checklist-practical-copyable)
+9. [Responsible testing and legal/ethical notes](#9-responsible-testing-and-legalethical-notes)
+10. [Learning resources & next steps](#10-learning-resources--next-steps)
+
+---
+
+## 1. What is SQL Injection?
+
+**SQL Injection** is a class of security vulnerability where untrusted input affects the structure or execution of SQL queries. When input is improperly handled, an attacker could cause the database to run unintended commands or reveal data. 
+
+> **The core problem**: Untrusted data mixed with query structure.
+
+---
+
+## 2. Why it matters (risks & impact)
+
+SQL injection can lead to serious consequences:
+
+- 🔓 **Data leakage**: Personal or sensitive data exposure
+- 🗑️ **Data modification or deletion**: Unauthorized changes to critical information
+- 🚪 **Authentication bypass**: Circumventing login mechanisms
+- 💻 **Complete system compromise**: If database credentials or OS-level commands are exposed
+- ⚖️ **Legal, financial, and reputational consequences**: Regulatory fines and brand damage
+
+---
+
+## 3. High-level types of SQLi (conceptual)
+
+Understanding these categories helps defenders know what to look for in logs and responses:
+
+### 🎯 **In-band SQLi**
+The same channel is used to both inject and get results (e.g., error messages).
+
+### 🔍 **Blind SQLi**
+Attacker learns true/false or timing information when responses don't directly reveal data.
+
+### 📡 **Out-of-band SQLi**
+Uses alternate channels to retrieve results (rare and environment-dependent).
+
+---
+
+## 4. How SQLi happens — a conceptual example
+
+Imagine an application that builds a query by concatenating user input directly into SQL:
+
+```sql
+-- ❌ Conceptual (dangerous) pattern:
+query = "SELECT * FROM users WHERE username = '" + userInput + "'";
+```
+
+If `userInput` contains special characters or SQL fragments, it can change the intended query structure.
+
+> **Key idea**: The vulnerability isn't the database — it's how the application constructs the query using untrusted input.
+
+---
+
+## 5. Vulnerable vs. secure code (safe examples)
+
+### ❌ **Vulnerable pattern** (conceptual demonstration)
+
+```javascript
+// Do NOT use: concatenating raw user input into SQL
+username = getRequestParam("username")
+sql = "SELECT * FROM users WHERE username = '" + username + "'"
+db.execute(sql)
+```
+
+*This shows the pattern that causes risk, but does not provide exploit strings.*
+
+### ✅ **Secure pattern** — Parameterized queries / prepared statements
+
+Use parameters so input never changes query structure:
+
+```javascript
+// ✅ Preferred: parameterized query
+username = getRequestParam("username")
+sql = "SELECT * FROM users WHERE username = ?"
+db.execute(sql, [username])   // driver sends query & data separately
+```
+
+### 🛡️ **Additional secure practice** — ORM / query builders
+
+Using a well-maintained ORM or query builder (correctly) typically avoids manual string building, but still requires care (e.g., avoid raw SQL APIs unless necessary).
+
+**Examples:**
+
+```python
+# Python with SQLAlchemy ORM
+user = session.query(User).filter(User.username == username).first()
+```
+
+```javascript
+// Node.js with Sequelize ORM
+const user = await User.findOne({ where: { username: username } });
+```
+
+```java
+// Java with JPA/Hibernate
+User user = entityManager.createQuery(
+    "SELECT u FROM User u WHERE u.username = :username", User.class)
+    .setParameter("username", username)
+    .getSingleResult();
+```
+
+---
+
+## 6. Top prevention techniques (practical, prioritized)
+
+### 🥇 **Primary Defenses**
+
+1. **Use parameterized queries / prepared statements everywhere**
+   - Most effective single defense
+   - Separates code from data completely
+
+2. **Use stored procedures with parameters**
+   - Only if they use parameters and don't build SQL strings unsafely
+   - Centralized business logic
+
+3. **Use least privilege database accounts**
+   - App account should only have needed permissions
+   - Separate accounts for different application functions
+
+### 🥈 **Secondary Defenses**
+
+4. **Input validation and normalization**
+   - Enforce allowed formats (e.g., email regex, numeric ranges)
+   - Use as safety net, not primary defense
+
+5. **Proper escaping**
+   - Only when parameterization is not possible
+   - Must use the DB driver's proper escaping functions
+
+6. **Use allowlist (whitelisting) for critical parameters**
+   - Especially for sort column names, table names
+   - Validate against known good values
+
+### 🥉 **Supporting Defenses**
+
+7. **Use ORMs/query builders carefully**
+   - Avoid raw query concatenation
+   - Understand ORM's SQL generation
+
+8. **Centralize DB access logic**
+   - Reduce code duplication and mistakes
+   - Easier to audit and maintain
+
+9. **Web Application Firewalls (WAFs)**
+   - Additional layer, not replacement for secure code
+   - Can detect and block common patterns
+
+10. **Keep everything updated**
+    - Patch drivers, ORMs, and frameworks regularly
+    - Monitor security advisories
+
+---
+
+## 7. Detection, logging, and monitoring
+
+### 📊 **Logging Strategy**
+
+- ✅ Log failed queries and unusual DB errors
+- ⚠️ Be careful not to log sensitive data
+- 📈 Monitor query patterns and latency spikes
+- 🚨 Look for unusual application errors or stack traces
+
+### 🔍 **Monitoring Indicators**
+
+- Anomalies that can indicate probing attempts
+- High volume of failed parameterized queries
+- Unexpected error types or frequencies
+- Unusual database access patterns
+
+### 🛠️ **Testing Tools**
+
+- **SAST (Static Application Security Testing)**: During development
+- **DAST (Dynamic Application Security Testing)**: In testing environments
+- **Database activity monitoring**: Production environments
+
+---
+
+## 8. Secure coding checklist (practical, copyable)
+
+### 🔐 **Development Checklist**
+
+- [ ] All DB queries use parameterized queries or prepared statements
+- [ ] No raw concatenation of user input into SQL strings
+- [ ] Inputs validated with allowlists for format and length
+- [ ] App DB user has minimal privileges (no DROP/ALTER unless required)
+- [ ] Error messages returned to users are generic
+- [ ] Detailed errors logged only server-side
+- [ ] Sensitive data in logs is redacted
+
+### 🚀 **Deployment Checklist**
+
+- [ ] Regular dependency and runtime patching is scheduled
+- [ ] Security tests run in CI (SAST/DAST) before production deploy
+- [ ] Production WAF or equivalent protections in place
+- [ ] Incident response plan includes data breach steps
+
+---
+
+## 9. Responsible testing and legal/ethical notes
+
+### ⚖️ **Legal Considerations**
+
+> **⚠️ Warning**: Never test for SQLi on systems you don't own or have explicit permission to test. Unauthorized security testing is illegal in many jurisdictions.
+
+### 🧪 **Safe Testing Practices**
+
+- ✅ Use staging/test environments that mirror production
+- ✅ Follow responsible disclosure process
+- ✅ Coordinate with application owners
+- ✅ Use automated tools for defensive remediation only
+
+### 🎯 **Recommended Testing Environments**
+
+- Local VMs designed for learning
+- Intentionally vulnerable applications you own
+- Dedicated security testing labs
+- Authorized penetration testing environments
+
+---
+
+## 10. Learning resources & next steps
+
+### 📚 **Essential Reading**
+
+- 🌐 **[OWASP Top Ten](https://owasp.org/Top10/)** — Read the Injection category and remediation guidance
+- 📋 **[OWASP SQL Injection Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)** — Defensive best practices
+- 🔧 **Secure coding guides** for your language/framework
+
+### 💻 **Platform-Specific Resources**
+
+#### Python
+- [Python DB-API 2.0](https://peps.python.org/pep-0249/) - Parameterized queries
+- [SQLAlchemy Security](https://docs.sqlalchemy.org/en/14/core/security.html)
+
+#### Java
+- [JDBC PreparedStatement](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)
+- [Hibernate Security Guide](https://hibernate.org/orm/documentation/5.6/)
+
+#### Node.js
+- [node-postgres Parameterized Queries](https://node-postgres.com/features/queries)
+- [Sequelize Security](https://sequelize.org/docs/v6/core-concepts/paranoid/)
+
+#### PHP
+- [PDO Prepared Statements](https://www.php.net/manual/en/pdo.prepared-statements.php)
+- [mysqli Prepared Statements](https://www.php.net/manual/en/mysqli.quickstart.prepared-statements.php)
+
+### 🏃‍♂️ **Next Steps**
+
+1. **Learn to configure secure DB drivers** and connection libraries
+2. **Practice secure coding** in controlled lab environments
+3. **Set up automated security testing** in your CI/CD pipeline
+4. **Implement monitoring and alerting** for your applications
+5. **Create incident response procedures** for security events
+
+---
+
+## 🎯 Quick Takeaway
+
+> **Don't concatenate. Parameterize.** That's the shortest path to preventing SQL injection.
+
+Combine parameterization with:
+- 🔒 Least privilege
+- ✅ Input allowlists  
+- 📊 Proper logging
+- 🧪 Regular testing
+
+...to build a secure application.
+
+---
+
+## 📞 Additional Resources
+
+- **OWASP**: [https://owasp.org](https://owasp.org)
+- **SANS Secure Coding**: [https://www.sans.org/white-papers/](https://www.sans.org/white-papers/)
+- **NIST Cybersecurity Framework**: [https://www.nist.gov/cyberframework](https://www.nist.gov/cyberframework)
+
+---
+
+*Last updated: October 2025*  
+*This guide focuses on defensive practices and responsible security education.*