Nếu tôi nhớ chính xác, tôi nghĩ Jeff đã đề cập trong podcast Stack Overflow là một điểm yếu có thể xảy ra trong các câu lệnh SQL được chuẩn bị. Tôi đang tự hỏi (những) điểm yếu của anh ta? Có lẽ nó chỉ là khoảng inappropriate usage của chúng, hoặc một cái gì đó độc ác hơn?Tiêm SQL bằng câu lệnh đã chuẩn bị?
Podcast, để ghi nhớ, không đi sâu hơn vào chủ đề, nó chỉ là một lời nhận xét.
Tôi chưa nghe podcast, nhưng trong kinh nghiệm của tôi chỉ tốt đến từ các câu đã chuẩn bị. Nó thường cải thiện hiệu suất của ứng dụng và ngăn chặn SQL injection (nếu được sử dụng đúng, không phải là ví dụ thứ hai trong liên kết của bạn).
Nếu câu lệnh được chuẩn bị có các thông số được tạo động theo bất kỳ cách nào, thì điều đó sẽ có nhiều khả năng là nguồn gốc của điểm yếu.
Nếu bạn sử dụng thư viện cơ sở dữ liệu thích hợp với các lớp được kiểm tra để thiết lập các tham số, thì bạn không tự mở bản SQL ở bất kỳ điểm nào, câu lệnh đã chuẩn bị hay không.
Hãy nhớ rằng, chỉ vì một câu lệnh được chuẩn bị, hoặc vì bạn đang sử dụng một thủ tục được lưu trữ, điều đó không có nghĩa là bạn được an toàn khỏi các cuộc tấn công tiêm. Chỉ khi bạn đang sử dụng mã của nhà cung cấp cơ sở dữ liệu sẽ làm vệ sinh đầu vào của các tham số (cũng như áp dụng nó cho tất cả các tham số có thể được sử dụng) để bạn có được sự bảo vệ khỏi việc tiêm SQL.
Ngoài việc tiêm sql bình thường (thứ mà chúng ta có thể gọi là thứ tự đầu tiên) tấn công có các cấp thứ cấp. Ví dụ, không có gì lạ khi có các thủ tục được lưu trữ sử dụng nối chuỗi để xây dựng một truy vấn mà nó thực thi. Nếu kết quả của các giá trị trường đã lấy được bao gồm trong một kết nối như vậy thì có nguy cơ bị tiêm.
Tôi nghĩ những gì ông ta nói là, khi bạn sử dụng báo cáo đã chuẩn bị, máy chủ SQL có thể lưu trữ kế hoạch thực thi truy vấn của bạn, vì vậy, ngay cả khi bạn sửa đổi một số tham số trên truy vấn thực hiện, máy chủ có thể chọn sai được lưu vào bộ nhớ cache) kế hoạch thực hiện sẽ thực hiện rất nặng.
Ông cũng đề cập đến một tính năng mới của SQL Server 2008 để buộc động cơ phải đánh giá lại các kế hoạch thực hiện mà ông đã sử dụng để khắc phục tình trạng này.
Với báo cáo được chuẩn bị, vấn đề duy nhất tôi có là vấn đề này. Hãy xem xét Mã Java sau:
String sql = "select * from table where name like ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, "PATTERN%");
ResultSet rs = pstmt.executeQuery();
Ở đây bạn có thể mong đợi, nếu bạn có chỉ mục trên bảng (tên) nó sẽ được kế hoạch truy vấn sử dụng. Vâng, nó sẽ không. Bởi vì PraparedStatement phải biên dịch trước và mong đợi điều tồi tệ nhất: ví dụ '% PATTERN%'. Vì vậy, nó sẽ không tối ưu hóa. Phải mất một lúc tôi mới hiểu được điều này. Nó đã gây ra cơ sở dữ liệu của tôi bị ảnh hưởng. :(
Hy vọng điều đó sẽ giúp ích.