From 8ac78d12fa9e20d915e3454c98a5cae3366ce804 Mon Sep 17 00:00:00 2001 From: Madhurendra kumar <95265573+m14r41@users.noreply.github.com> Date: Fri, 11 Apr 2025 02:11:53 +0530 Subject: [PATCH 1/2] enhancement: clarified and expanded details on Second-Order SQL Injection. I improved the existing details on Second-Order SQL Injection by providing a clear, concise, and comprehensive explanation of this rare vulnerability. --- SQL Injection/README.md | 53 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 49 insertions(+), 4 deletions(-) diff --git a/SQL Injection/README.md b/SQL Injection/README.md index 5bbe8ba..d8fb853 100644 --- a/SQL Injection/README.md +++ b/SQL Injection/README.md @@ -357,15 +357,60 @@ In short, the result of the first SQL query is used to build the second SQL quer ## Second Order SQL Injection Second Order SQL Injection is a subtype of SQL injection where the malicious SQL payload is primarily stored in the application's database and later executed by a different functionality of the same application. +Unlike first-order SQLi, the injection doesn’t happen right away — it’s **triggered in a separate step**, often in a different part of the application. -```py -username="anything' UNION SELECT Username, Password FROM Users;--" -password="P@ssw0rd" +### ⚙️ How It Works + +1. User submits input that is stored (e.g., during registration or profile update). +2. That input is saved **without validation**. +3. Later, the application retrieves and uses the stored data in a SQL query. +4. If this query is built unsafely, the injection is triggered. + +### Example Scenario + +#### **Step 1: Malicious User Registers** + +```text +Username: attacker' -- +Email: attacker@example.com ``` -Since you are inserting your payload in the database for a later use, any other type of injections can be used UNION, ERROR, BLIND, STACKED, etc. +Stored in DB as: + +```sql +INSERT INTO users (username, email) VALUES ('attacker\' --', 'attacker@example.com'); +``` + +✅ No error yet — payload is saved. + +#### Step 2: Admin Dashboard Later Uses Username + +```python +# Backend code +query = "SELECT * FROM logs WHERE username = '" + user_from_db + "'" +``` + +If `user_from_db = attacker' --`, this becomes: + +```sql +SELECT * FROM logs WHERE username = 'attacker' --' +``` + +🔥 Query is broken → Injection succeeds. + +### Where and How to Test Payloads + +| 🔍 Application Area | 🧪 Field to Inject | 💣 Why It's Vulnerable | ⏱️ When Injection Triggers | +|------------------------|--------------------------|-----------------------------------------------------------|-------------------------------------------| +| User Registration | `username`, `email` | Values stored, reused in logs or admin views | When admin views logs or user profile | +| Profile Update | `display name`, `bio` | Reused in dashboards or internal reporting tools | When data is retrieved by another user | +| Feedback/Contact Forms | `subject`, `message` | Stored in DB, emailed or inserted into analytics queries | When viewed or processed by admin | +| Support Ticket System | `ticket title`, `details`| May be reused in SQL joins, search features | When admin searches or filters tickets | +| Comment Systems | `username`, `comment` | Appears in other queries like moderation tools | When moderator queries by username | + ## Generic WAF Bypass +--- ### White Spaces From 6cb0048e229beab579a3828cfc2953fecb4b3f3f Mon Sep 17 00:00:00 2001 From: Swissky <12152583+swisskyrepo@users.noreply.github.com> Date: Wed, 13 Aug 2025 11:52:26 +0200 Subject: [PATCH 2/2] Update README.md --- SQL Injection/README.md | 65 ++++++++++++----------------------------- 1 file changed, 18 insertions(+), 47 deletions(-) diff --git a/SQL Injection/README.md b/SQL Injection/README.md index d8fb853..443d5ad 100644 --- a/SQL Injection/README.md +++ b/SQL Injection/README.md @@ -357,58 +357,29 @@ In short, the result of the first SQL query is used to build the second SQL quer ## Second Order SQL Injection Second Order SQL Injection is a subtype of SQL injection where the malicious SQL payload is primarily stored in the application's database and later executed by a different functionality of the same application. -Unlike first-order SQLi, the injection doesn’t happen right away — it’s **triggered in a separate step**, often in a different part of the application. - -### ⚙️ How It Works +Unlike first-order SQLi, the injection doesn’t happen right away. It is **triggered in a separate step**, often in a different part of the application. 1. User submits input that is stored (e.g., during registration or profile update). -2. That input is saved **without validation**. + + ```text + Username: attacker'-- + Email: attacker@example.com + ``` + +2. That input is saved **without validation** but doesn't trigger a SQL injection. + + ```sql + INSERT INTO users (username, email) VALUES ('attacker\'--', 'attacker@example.com'); + ``` + 3. Later, the application retrieves and uses the stored data in a SQL query. + + ```python + query = "SELECT * FROM logs WHERE username = '" + user_from_db + "'" + ``` + 4. If this query is built unsafely, the injection is triggered. -### Example Scenario - -#### **Step 1: Malicious User Registers** - -```text -Username: attacker' -- -Email: attacker@example.com -``` - -Stored in DB as: - -```sql -INSERT INTO users (username, email) VALUES ('attacker\' --', 'attacker@example.com'); -``` - -✅ No error yet — payload is saved. - -#### Step 2: Admin Dashboard Later Uses Username - -```python -# Backend code -query = "SELECT * FROM logs WHERE username = '" + user_from_db + "'" -``` - -If `user_from_db = attacker' --`, this becomes: - -```sql -SELECT * FROM logs WHERE username = 'attacker' --' -``` - -🔥 Query is broken → Injection succeeds. - -### Where and How to Test Payloads - -| 🔍 Application Area | 🧪 Field to Inject | 💣 Why It's Vulnerable | ⏱️ When Injection Triggers | -|------------------------|--------------------------|-----------------------------------------------------------|-------------------------------------------| -| User Registration | `username`, `email` | Values stored, reused in logs or admin views | When admin views logs or user profile | -| Profile Update | `display name`, `bio` | Reused in dashboards or internal reporting tools | When data is retrieved by another user | -| Feedback/Contact Forms | `subject`, `message` | Stored in DB, emailed or inserted into analytics queries | When viewed or processed by admin | -| Support Ticket System | `ticket title`, `details`| May be reused in SQL joins, search features | When admin searches or filters tickets | -| Comment Systems | `username`, `comment` | Appears in other queries like moderation tools | When moderator queries by username | - - ## Generic WAF Bypass ---