Tại sao việc sử dụng câu lệnh truy vấn trực tiếp (Raw SQL) mà không qua Prepared Statements lại nguy hiểm đối với ứng dụng PHP, và cơ chế hoạt động của Prepared Statements giúp ngăn chặn lỗ hổng SQL Injection như thế nào?

Question

Accepted Answer

1. Nguy hiểm từ Raw SQL và SQL Injection

Khi ghép trực tiếp dữ liệu do người dùng nhập vào câu lệnh SQL (ví dụ: "SELECT * FROM users WHERE username = '" . $_POST['user'] . "'"), kẻ tấn công có thể truyền vào các đoạn mã SQL độc hại để vượt qua hệ thống xác thực hoặc đánh cắp/xóa dữ liệu cơ sở dữ liệu.

2. Cơ chế hoạt động của Prepared Statements

Prepared Statements tách biệt hoàn toàn giữa câu lệnh cấu trúc SQL và dữ liệu truyền vào.
Quá trình xử lý diễn ra qua 2 bước:
Parse & Compile: Database server nhận câu lệnh SQL với các placeholder (tham số truyền vào như :username hoặc ?) và tiến hành biên dịch cấu trúc truy vấn trước.
Execute: Dữ liệu thực tế được gửi riêng biệt và gắn vào các placeholder đã biên dịch. Database hiểu dữ liệu này thuần túy là giá trị dữ liệu (data value), hoàn toàn không thể thực thi như một câu lệnh SQL.

3. Ví dụ chuẩn bảo mật với PDO
// An toàn tuyệt đối chống SQL Injection
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
$stmt->execute(['email' => $_POST['email']]);
$user = $stmt->fetch();
4. Lưu ý cho Junior

Ngay cả khi dữ liệu đã được lọc bằng các hàm validate, việc sử dụng Prepared Statements vẫn là quy tắc bắt buộc không thể bỏ qua trong mọi dự án Enterprise.

Tại sao việc sử dụng câu lệnh truy vấn trực tiếp (Raw SQL) mà không qua Prepared Statements lại nguy hiểm đối với ứng dụng PHP, và cơ chế hoạt động của Prepared Statements giúp ngăn chặn lỗ hổng SQL Injection như thế nào?

1. Nguy hiểm từ Raw SQL và SQL Injection

Khóa học PHP Hiện Đại & Clean Code

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi php liên quan cùng chủ đề