SQL injection và tham số hoá

Injection có một cơ chế duy nhất, và nó giống nhau ở SQL, shell, XML, template engine và trình duyệt: bạn dựng một chuỗi lệnh bằng cách nối dữ liệu vào, rồi giao chuỗi đó cho một interpreter. Interpreter không có cách nào biết phần nào là lệnh của bạn và phần nào là dữ liệu của người khác — nó chỉ thấy một chuỗi.

Điều đó nghĩa là câu hỏi đúng khi review không phải "input này có được validate chưa" mà "dữ liệu này có bao giờ trở thành cú pháp không". Hai câu hỏi khác nhau, và câu thứ hai chỉ có một câu trả lời an toàn.

Tham số hoá giải quyết nó theo cách khác hẳn escape: nó không sửa dữ liệu. Nó gửi câu lệnh và dữ liệu qua hai đường riêng trong giao thức, nên interpreter đã biết ranh giới trước khi nó thấy dữ liệu. Không có chuỗi nào để phá.

Vì sao escape là câu trả lời sai dù nó "cũng chạy":

• Nó đúng cho một loại cơ sở dữ liệu, một charset, một chế độ SQL. Đổi một trong ba thì nó sai.
• Nó đòi bạn nhớ escape ở mọi chỗ. Tham số hoá thì chỗ nào quên là chỗ đó không chạy — lỗi hiện ra ngay lúc dev, không im lặng chờ.
• Nó không xử lý được kiểu dữ liệu: một int bị escape vẫn là chuỗi, và 1 OR 1=1 không có dấu nháy nào để escape.

Điểm cuối là chỗ nhiều người bị bất ngờ: injection không cần dấu nháy. Nếu tham số đi vào một chỗ không cần quote — WHERE id = 1 — thì escape dấu nháy chặn được đúng con số không.