Skip to content

Commit 6cb0048

Browse files
authored
Update README.md
1 parent 8ac78d1 commit 6cb0048

File tree

1 file changed

+18
-47
lines changed

1 file changed

+18
-47
lines changed

SQL Injection/README.md

Lines changed: 18 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -357,58 +357,29 @@ In short, the result of the first SQL query is used to build the second SQL quer
357357
## Second Order SQL Injection
358358

359359
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.
363361
364362
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+
366375
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+
367381
4. If this query is built unsafely, the injection is triggered.
368382

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 |
404-
|------------------------|--------------------------|-----------------------------------------------------------|-------------------------------------------|
405-
| User Registration | `username`, `email` | Values stored, reused in logs or admin views | When admin views logs or user profile |
406-
| Profile Update | `display name`, `bio` | Reused in dashboards or internal reporting tools | When data is retrieved by another user |
407-
| Feedback/Contact Forms | `subject`, `message` | Stored in DB, emailed or inserted into analytics queries | When viewed or processed by admin |
408-
| Support Ticket System | `ticket title`, `details`| May be reused in SQL joins, search features | When admin searches or filters tickets |
409-
| Comment Systems | `username`, `comment` | Appears in other queries like moderation tools | When moderator queries by username |
410-
411-
412383
## Generic WAF Bypass
413384
---
414385

0 commit comments

Comments
 (0)