Chúng tôi đang có một cuộc thảo luận khác ở đây về việc sử dụng các truy vấn sql được tham số hóa trong mã của chúng tôi. Chúng tôi có hai mặt trong cuộc thảo luận: Tôi và một số người khác nói rằng chúng ta nên luôn sử dụng các thông số để bảo vệ chống lại việc tiêm sql và những người khác cho rằng nó không cần thiết. Thay vào đó, họ muốn thay thế các dấu nháy đơn bằng hai dấu nháy đơn trong tất cả các chuỗi để tránh tiêm sql. Cơ sở dữ liệu của chúng tôi đều đang chạy Sql Server 2005 hoặc 2008 và cơ sở mã của chúng tôi đang chạy trên .NET framework 2.0.
Hãy để tôi cung cấp cho bạn một ví dụ đơn giản trong C #:
Tôi muốn chúng tôi sử dụng cái này:
string sql = "SELECT * FROM Users WHERE Name=@name";
SqlCommand getUser = new SqlCommand(sql, connection);
getUser.Parameters.AddWithValue("@name", userName);
//... blabla - do something here, this is safeTrong khi những người khác muốn làm điều này:
string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);
SqlCommand getUser = new SqlCommand(sql, connection);
//... blabla - are we safe now?Trong đó hàm SafeDBString được định nghĩa như sau:
string SafeDBString(string inputValue)
{
return "'" + inputValue.Replace("'", "''") + "'";
}Bây giờ, miễn là chúng tôi sử dụng SafeDBString trên tất cả các giá trị chuỗi trong truy vấn của mình, chúng tôi sẽ an toàn. Đúng?
Có hai lý do để sử dụng chức năng SafeDBString. Đầu tiên, đó là cách nó đã được thực hiện từ thời kỳ đồ đá và thứ hai, việc gỡ lỗi các câu lệnh sql sẽ dễ dàng hơn vì bạn thấy truy vấn đào được chạy trên cơ sở dữ liệu.
Vậy thì. Câu hỏi của tôi là liệu nó có thực sự đủ để sử dụng hàm SafeDBString để tránh các cuộc tấn công tiêm sql hay không. Tôi đã cố gắng tìm các ví dụ về mã phá vỡ biện pháp an toàn này, nhưng tôi không thể tìm thấy bất kỳ ví dụ nào về nó.
Có ai ngoài đó có thể phá vỡ điều này không? Bạn sẽ làm điều này như thế nào?
CHỈNH SỬA: Để tóm tắt các câu trả lời cho đến nay:
- Chưa ai tìm ra cách để vượt qua SafeDBString trên Sql Server 2005 hoặc 2008. Đó là tốt, tôi nghĩ?
- Một số câu trả lời đã chỉ ra rằng bạn sẽ đạt được hiệu suất khi sử dụng các truy vấn được tham số hóa. Lý do là các kế hoạch truy vấn có thể được sử dụng lại.
- Chúng tôi cũng đồng ý rằng việc sử dụng các truy vấn được tham số hóa cung cấp mã dễ đọc hơn và dễ bảo trì hơn
- Hơn nữa, việc luôn sử dụng các tham số sẽ dễ dàng hơn là sử dụng các phiên bản SafeDBString khác nhau, chuyển đổi chuỗi thành số và chuyển đổi chuỗi ngày.
- Sử dụng các tham số, bạn sẽ nhận được chuyển đổi kiểu tự động, một thứ đặc biệt hữu ích khi chúng tôi đang làm việc với ngày tháng hoặc số thập phân.
- Và cuối cùng: Đừng cố tự bảo mật như JulianR đã viết. Các nhà cung cấp cơ sở dữ liệu dành nhiều thời gian và tiền bạc cho việc bảo mật. Không có cách nào chúng ta có thể làm tốt hơn và không có lý do gì chúng ta phải cố gắng làm công việc của họ.
Vì vậy, trong khi không ai có thể phá vỡ tính bảo mật đơn giản của hàm SafeDBString, tôi có rất nhiều lập luận tốt khác. Cảm ơn!