Ví dụ riêng biệt này là không thể xâm phạm để tiêm.
Nhưng bạn phải nhận ra rằng bảo vệ khỏi tiêm sql không chỉ là sự thay thế ký tự . Và hoàn cảnh có thể khác với những hoàn cảnh bạn đang thực hiện vào lúc này. Vì vậy, về lâu dài, mã của bạn sẽ trở nên dễ bị tấn công do nhược điểm cơ bản của phương pháp này :
- thay thế ký tự chỉ là một phần định dạng bắt buộc
- sự thay thế cụ thể này chỉ có thể được áp dụng cho chuỗi, để lại các bộ phận khác không được bảo vệ tuyệt đối.
- sự thay thế như vậy nằm ngoài việc thực thi truy vấn, có nghĩa là nó dễ xảy ra lỗi do con người dưới bất kỳ hình thức nào.
- sự thay thế như vậy về cơ bản là một biện pháp có thể tháo rời, có nghĩa là nó có thể bị di chuyển quá xa so với thực thi truy vấn thực tế và cuối cùng bị lãng quên.
- kiểu thoát này dễ bị tấn công mã hóa khiến giải pháp bị hạn chế sử dụng.
Không có gì sai trong việc thay thế ký tự, nhưng chỉ khi nó được sử dụng như một phần của định dạng hoàn chỉnh; áp dụng cho phần truy vấn bên phải; và được thực hiện bởi trình điều khiển cơ sở dữ liệu, không phải lập trình viên; ngay trước khi thực hiện.
Các chức năng bạn đề xuất trong các nhận xét là một bước tiến tốt, nhưng vẫn chưa đủ, là đối tượng của những nhược điểm được liệt kê ở trên, khiến chúng dễ mắc phải tất cả các lỗi do con người gây ra.
Và SQL injection không phải là vấn đề duy nhất với cách tiếp cận này, nó cũng là một lỗi về khả năng sử dụng, vì chức năng này có thể làm hỏng dữ liệu của bạn, nếu được sử dụng như một hiện thân của late trích dẫn ảo hoặc làm cho mã của bạn cồng kềnh, nếu được sử dụng để định dạng mọi biến ngay trong mã ứng dụng.
Các chức năng như vậy có thể được sử dụng chỉ để xử lý trình giữ chỗ , nhưng tất nhiên không phải bằng cách sử dụng hàm thay thế do homebrewed mà là một hàm thích hợp được cung cấp bởi API cơ sở dữ liệu.
