SQL Injection Teaching Lab

🎯 Mục tiêu học tập

• Hiểu vì sao string concatenation dẫn tới SQL Injection trong Flask + SQLite.
• Thực hành 3 nhóm tấn công phổ biến trên môi trường lab: authentication bypass, UNION-based SQLi, blind SQLi.
• So sánh trực tiếp bản vulnerable và patched để thấy parameterized queries thay đổi hành vi ra sao.
• Tự verify rằng cùng payload cũ không còn hiệu quả sau khi vá.

📖 Xem STUDENT_GUIDE và TEACHER_NOTES

📁 Cấu trúc dự án

sql-injection/
├── vulnerable/
│   ├── app.py
│   ├── database.py
│   └── templates/
├── patched/
│   ├── app.py
│   ├── database.py
│   └── templates/
├── exploits/
│   ├── exploit_login.py
│   ├── exploit_union.py
│   ├── exploit_blind.py
│   └── verify_patch.py
├── requirements.txt
└── README.md

Ghi chú:

• vulnerable/ giữ nguyên logic dễ tổn thương để phục vụ bài học tấn công.
• patched/ dùng cùng schema và giao diện nhưng thay string concatenation bằng parameterized queries.
• exploits/ chứa các script minh họa kỹ thuật tấn công và script xác nhận bản vá.

🚀 Hướng dẫn chạy lab

Trước tiên cài dependency từ thư mục gốc:

pip install -r requirements.txt

Bước 1: Chạy vulnerable server (port 5000)

cd vulnerable
python app.py

Server này dùng cho toàn bộ bài tập tấn công ban đầu.

Bước 2: Thực hành tấn công

Mở terminal khác:

cd exploits
python exploit_login.py
python exploit_union.py
python exploit_blind.py

Mục tiêu:

• bypass login bằng payload comment / OR
• dump bảng users và secret_notes bằng UNION
• xác nhận blind SQLi qua boolean-based và time-based

Bước 3: Chạy patched server (port 5001)

Mở terminal khác:

cd patched
python app.py

Server này chạy song song với vulnerable để học sinh so sánh trực tiếp before/after.

Bước 4: Verify patch

Mở terminal thứ ba:

cd exploits
python verify_patch.py

Script sẽ kiểm tra cả hai server:

• http://localhost:5000 để xác nhận bản vulnerable vẫn bị khai thác
• http://localhost:5001 để xác nhận bản patched chặn cùng payload

📚 Giải thích kỹ thuật

Tại sao String Concatenation nguy hiểm

Khi ứng dụng ghép trực tiếp input người dùng vào câu SQL, dữ liệu nhập vào không còn được xem là dữ liệu thuần nữa. Attacker có thể chèn thêm:

• toán tử logic như OR, AND
• comment SQL như --
• mệnh đề UNION SELECT
• subquery cho blind SQLi

Kết quả là database thực thi logic do attacker điều khiển chứ không còn là truy vấn ban đầu của developer.

Parameterized Query hoạt động thế nào

Parameterized query tách biệt:

• câu lệnh SQL
• giá trị đầu vào

Database nhận input như dữ liệu ràng buộc vào placeholder ?, nên chuỗi như ' OR 1=1-- chỉ còn là text bình thường thay vì cú pháp SQL có thể thực thi.

So sánh code Before/After

Route	Vulnerable	Patched
/login	SELECT * FROM users WHERE username = ' + username + ' AND password = ' + password + '	SELECT * FROM users WHERE username=? AND password=? + execute(..., (username, password))
/search	SELECT id, username, email, role FROM users WHERE username LIKE '% + keyword + %'	SELECT id, username, email, role FROM users WHERE username LIKE ? + execute(..., (f"%{keyword}%",))
/ping	SELECT id FROM users WHERE username = ' + keyword + '	SELECT id FROM users WHERE username = ? + execute(..., (keyword,))

Điểm cần quan sát:

• bản vulnerable thay đổi cú pháp SQL theo input
• bản patched giữ nguyên cú pháp SQL, chỉ thay giá trị tham số
• cùng payload nhưng hành vi server sẽ khác hoàn toàn

🏆 Checklist học sinh

• Đã chạy được vulnerable server
• Đã bypass login thành công với payload ' OR 1=1--
• Đã dump được bảng users bằng UNION
• Đã confirm Blind SQLi qua time-based
• Đã hiểu tại sao các payload hoạt động
• Đã chạy patched server và verify tất cả bị chặn
• Đã đọc và hiểu sự khác biệt code trước/sau patch