Ngăn chặn tiêm sql - tại sao một người nên thoát khỏi đầu vào nếu sử dụng các câu lệnh chuẩn bị?

Question

Tôi đang làm một số nghiên cứu về bảo mật web, và người sửa lại bài viết của tôi nói:

"Nó nên được rõ ràng rằng để tránh SQL Injection, ứng dụng nên sử dụng chuẩn bị phát biểu, thủ tục lưu trữ và thoát đầu vào"

Câu hỏi của tôi là: Một trong những phương pháp này có đủ không? Ok, các câu lệnh được chuẩn bị hoặc các thủ tục lưu sẵn tốt hơn một lối thoát đơn giản, nhưng nếu tôi sử dụng PDO, tại sao tôi nên thoát khỏi đầu vào hoặc có một thủ tục lưu sẵn? Điều này có nghĩa không?

Answer 1

tôi sẽ thay đổi cách diễn đạt của người sửa lại để:

Nó nên được rõ ràng rằng để tránh SQL Injection, ứng dụng nên sử dụng chuẩn bị phát biểu, thoát đầu vào, hoặc áp dụng bộ lọc dữ liệu trước khi nội suy thành một chuỗi SQL.

Không cần thiết phải thoát khỏi giá trị nếu bạn định chuyển sang tham số. Trong thực tế, bạn không nên, bởi vì bạn sẽ chèn dấu gạch chéo ngược chữ vào dữ liệu của bạn.

Bạn cần phải nội suy chuỗi vào câu lệnh SQL của mình khi bạn không thể sử dụng tham số truy vấn. Ví dụ:

• Tên và tên cột có own syntax for delimited identifiers. Đây phải là một phần của truy vấn SQL vào lúc chuẩn bị, vì vậy RDBMS có thể phân tích và xác nhận chúng.

• Từ khóa SQL, nên được khử trùng nhưng không thể bị thoát vì chúng không được phân tách.

• Cú pháp hoặc biểu thức khác.

• Một số trường hợp phải cung cấp giá trị bằng chữ vào thời gian chuẩn bị, ví dụ: Các hàm fulltext của MySQL không hỗ trợ các tham số cho mẫu tìm kiếm.

Các thủ tục được lưu trữ không phải là biện pháp phòng chống SQL injection. Bạn có thể chuẩn bị và thực hiện các câu lệnh SQL động không an toàn bên trong một thủ tục lưu sẵn. Xem http://thedailywtf.com/Articles/For-the-Ease-of-Maintenance.aspx để biết câu chuyện tuyệt vời về điều đó.

Tôi bao gồm tất cả các trường hợp này trong bản trình bày SQL Injection Myths and Fallacies. Đó có thể là một tài nguyên hữu ích cho bạn.

Tôi cũng đề cập đến việc bảo vệ tiêm SQL trong một chương của cuốn sách của tôi, SQL Antipatterns: Avoiding the Pitfalls of Database Programming.

Answer 2

Nếu tôi sử dụng PDO, tại sao tôi nên chọn đầu vào hoặc lưu trữ?

Miễn là bạn luôn luôn sử dụng PDO, tôi không thấy lý do bận tâm với lần thoát đầu vào hoặc SP.

Answer 3

Khi nghi ngờ, hãy tự hỏi: liệu đoạn dữ liệu đầu vào đơn giản này có bị thoát bởi một số API xuống dòng không? Hầu hết thời gian họ sẽ làm, trừ khi bạn xây dựng các câu SQL theo cách thủ công từ dữ liệu đầu vào.

Bạn không nên thoát nếu bạn sử dụng PDO. Bạn không nên thoát nếu bạn sử dụng các câu lệnh được chuẩn bị JDBC với các tham số. Tương tự, hầu hết các API khác cũng quan tâm đến điều này. Các thủ tục được lưu trữ thậm chí không quan tâm đến dữ liệu đã thoát và sử dụng chúng sẽ không tránh được các vấn đề bảo mật của SQL injection nếu dữ liệu đầu vào không được thoát trong SQL chạy thủ tục đó.

Luôn là dữ liệu SQL-Escape mà bạn đặt trong câu SQL. Không bao giờ SQL-Escape dữ liệu bên ngoài câu SQL.