Nếu bạn biết lý do tại sao việc chèn SQL xảy ra, bạn có thể tự trả lời câu hỏi này.
Hãy xem nào. CWE mô tả việc đưa vào SQL (CWE-89) như sau:
Hơn nữa:
Vì vậy, về cơ bản:các đầu vào bị ảnh hưởng từ bên ngoài trong một truy vấn SQL được tạo không được diễn giải như dự định. Phần quan trọng ở đây là: không được hiểu như dự định .
Nếu đầu vào của người dùng được hiểu là một chuỗi MySQL chữ nhưng không phải vậy, đó là một SQL injection. Nhưng tại sao nó lại xảy ra?
Chà, chuỗi ký tự có một cú pháp nhất định mà chúng được xác định bởi trình phân tích cú pháp SQL:
Ngoài ra:
Ngoài ra, để có thể sử dụng dấu ngoặc kép trong chuỗi ký tự:
Vì tất cả các chuỗi được đề cập sau này là đặc biệt đối với các ký tự chuỗi, nên bất kỳ dữ liệu nào, được dự định hiểu là một ký tự chuỗi, phải được xử lý đúng cách để tuân theo các quy tắc này. Đặc biệt, điều này có nghĩa là:nếu bất kỳ ký tự nào được đề cập nhằm mục đích sử dụng trong một chuỗi ký tự, chúng phải được viết theo một trong những cách đã đề cập.
Vì vậy, nếu bạn nhìn nó theo cách này, nó thậm chí không phải là vấn đề bảo mật mà chỉ đơn giản là xử lý dữ liệu để chúng được diễn giải như dự định .
Điều tương tự cũng áp dụng cho các ký tự khác cũng như các khía cạnh khác của SQL.
Vậy câu hỏi của bạn thì sao?
Có, điều đó sẽ an toàn khi tiêm SQL. bin2hex trả về một chuỗi chỉ chứa các ký tự thập lục phân. Và cả hai ký tự này đều không yêu cầu xử lý đặc biệt khi sử dụng chúng trong chuỗi MySQL theo nghĩa đen.
Nhưng nghiêm túc mà nói, tại sao mọi người lại muốn sử dụng kỹ thuật định dạng rườm rà này khi có các thư viện và khuôn khổ cung cấp các kỹ thuật tiện lợi như các câu lệnh được chuẩn bị / tham số hóa?
