You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: SQL Injection/README.md
+18-47Lines changed: 18 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -357,58 +357,29 @@ In short, the result of the first SQL query is used to build the second SQL quer
357
357
## Second Order SQL Injection
358
358
359
359
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.
360
-
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.
361
-
362
-
### ⚙️ How It Works
360
+
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.
363
361
364
362
1. User submits input that is stored (e.g., during registration or profile update).
365
-
2. That input is saved **without validation**.
363
+
364
+
```text
365
+
Username: attacker'--
366
+
Email: attacker@example.com
367
+
```
368
+
369
+
2. That input is saved **without validation** but doesn't trigger a SQL injection.
370
+
371
+
```sql
372
+
INSERT INTO users (username, email) VALUES ('attacker\'--', '[email protected]');
373
+
```
374
+
366
375
3. Later, the application retrieves and uses the stored data in a SQL query.
376
+
377
+
```python
378
+
query ="SELECT * FROM logs WHERE username = '"+ user_from_db +"'"
379
+
```
380
+
367
381
4. If this query is built unsafely, the injection is triggered.
368
382
369
-
### Example Scenario
370
-
371
-
#### **Step 1: Malicious User Registers**
372
-
373
-
```text
374
-
Username: attacker'--
375
-
Email: attacker@example.com
376
-
```
377
-
378
-
Stored in DB as:
379
-
380
-
```sql
381
-
INSERT INTO users (username, email) VALUES ('attacker\' --', '[email protected]');
382
-
```
383
-
384
-
✅ No error yet — payload is saved.
385
-
386
-
#### Step 2: Admin Dashboard Later Uses Username
387
-
388
-
```python
389
-
# Backend code
390
-
query ="SELECT * FROM logs WHERE username = '"+ user_from_db +"'"
391
-
```
392
-
393
-
If `user_from_db = attacker' --`, this becomes:
394
-
395
-
```sql
396
-
SELECT*FROM logs WHERE username ='attacker'--'
397
-
```
398
-
399
-
🔥 Query is broken → Injection succeeds.
400
-
401
-
### Where and How to Test Payloads
402
-
403
-
| 🔍 Application Area | 🧪 Field to Inject | 💣 Why It's Vulnerable | ⏱️ When Injection Triggers |
0 commit comments