2011-08-19 41 views
5

Hãy xem xét một tình huống giả định mà tôi phải lấy một số chi tiết từ cơ sở dữ liệu dựa trên userId và mã mẫu được đưa ra dưới đâyBáo cáo chuẩn bị sẵn sàng ngăn chặn các cuộc tấn công tiêm sql?

private String getpassword(String username) { 

PreparedStatement statement = null; 
ResultSet resultSet = null; 
Connection conn = null; 

final String selectQuery = "SELECT password FROM " + "users WHERE username=?"; 
try { 
    conn = dataSource.getConnection(); 
    statement = conn.prepareStatement(selectQuery); 
    statement.setString(1, username); 
    resultSet = statement.executeQuery(); 
    if (resultSet.next()) { 
     } 

} catch (SQLException e) { 
// log it 
} 
//return 
} 

Tên người dùng này thực sự đến từ phía khách hàng và người dùng có thể làm xáo trộn các dữ liệu (nếu anh ta muốn). Vì vậy, sẽ chuẩn bịBáo cáo ngăn chặn từ việc chấp nhận báo giá và chỉ gửi các hình thức lọc của SQL vào cơ sở dữ liệu.

Ví dụ: Tôi có thể cung cấp tên người dùng = 'hoặc 1 = 1 và nó sẽ là một câu lệnh SQL hợp lệ. Nhưng nếu người lái xe thoát khỏi dấu ngoặc kép từ đầu vào của người dùng, thì họ sẽ ngăn chặn việc tiêm sql.

Hiểu biết chung về điều gì?

+0

xin lỗi vì câu trả lời sai trước đây của tôi (loại bỏ). Có vẻ họ làm việc. xem bài đăng này: http://stackoverflow.com/questions/1812891/java-escape-string-to-prevent-sql-injection – Heisenbug

+0

Ngăn chặn việc tiêm SQL bằng cách thoát đúng cách là một trong những lý do đã được tạo ra. – Jacob

+0

có thể trùng lặp của [Tôi có thể tránh tất cả các cuộc tấn công SQL-injection bằng cách sử dụng các tham số không?] (Http://stackoverflow.com/questions/3736831/can-i-avoid-all-sql-injection-attacks-by-using-parameters) – Thilo

Trả lời

4

Theo đó, vâng: http://en.wikipedia.org/wiki/SQL_injection

Trong trường hợp đó báo cáo kết quả đã được biên soạn và tiêm mã sẽ không được giải thích (và do đó không được thực thi) một lần nữa.

0

Tên người dùng và truy vấn sẽ được gửi đến cơ sở dữ liệu dưới dạng hai thứ riêng biệt và công cụ cơ sở dữ liệu sẽ chịu trách nhiệm đưa hai trở lại với nhau. Truy vấn đã được biên dịch bởi công cụ bởi thời gian tham số được đọc, do đó, hai không bao giờ được coi là một phần của cùng một câu lệnh.

3

Sử dụng thông số và câu lệnh đã chuẩn bị không ngăn các cuộc tấn công SQL injection, tức là "" hoặc 1 = 1 "" sẽ không dẫn đến dữ liệu không mong muốn được trả về. Tuy nhiên, nếu ở bất kỳ giai đoạn nào bạn hiển thị lại dữ liệu cho người dùng, bạn cần đảm bảo rằng HTML được tạo ra không bị ảnh hưởng bởi đầu vào của người dùng quay lại từ cơ sở dữ liệu

Ví dụ: nếu trang web của bạn hiển thị :

Hello, ${username} 

nếu username là

<script>alert('I could have been more malicious')</script> 

có thể dẫn đến XSS hoặc CSRF tấn công.

N.B.

Hello, ${fn:escapeXml(username)} 

sẽ an toàn hơn (mã JSP).

Một tài liệu tham khảo tốt là:

Các vấn đề liên quan