Có phải sự phụ thuộc vào các truy vấn tham số là cách duy nhất để bảo vệ chống lại việc tiêm SQL?

Tất cả những gì tôi đã thấy về các cuộc tấn công SQL SQL dường như gợi ý rằng các truy vấn được tham số hóa, đặc biệt là các truy vấn được lưu trữ, là cách duy nhất để bảo vệ chống lại các cuộc tấn công đó. Trong khi tôi đang làm việc (trở lại thời kỳ đen tối), các thủ tục lưu trữ được xem là thực hành kém, chủ yếu là vì chúng được xem là ít bảo trì hơn; ít kiểm tra hơn; kết hợp cao; và khóa một hệ thống vào một nhà cung cấp; ( câu hỏi này bao gồm một số lý do khác).

Mặc dù khi tôi đang làm việc, các dự án hầu như không biết về khả năng của các cuộc tấn công như vậy; các quy tắc khác nhau đã được thông qua để bảo mật cơ sở dữ liệu chống lại tham nhũng thuộc nhiều loại khác nhau. Các quy tắc này có thể được tóm tắt là:

1. Không có ứng dụng khách / ứng dụng nào có quyền truy cập trực tiếp vào các bảng cơ sở dữ liệu.
2. Tất cả các truy cập vào tất cả các bảng đều thông qua các khung nhìn (và tất cả các cập nhật cho các bảng cơ sở được thực hiện thông qua các kích hoạt).
3. Tất cả các mục dữ liệu có một miền được chỉ định.
4. Không có mục dữ liệu nào được phép là không thể thực hiện được - điều này có ý nghĩa khiến các DBA nghiến răng đôi khi; nhưng đã được thi hành
5. Vai trò và quyền được thiết lập phù hợp - ví dụ: vai trò bị hạn chế chỉ cung cấp cho các chế độ xem quyền thay đổi dữ liệu.

Vì vậy, một tập hợp các quy tắc (được thi hành) như thế này (mặc dù không nhất thiết phải là tập hợp cụ thể này) có phải là sự thay thế phù hợp cho các truy vấn được tham số hóa trong việc ngăn chặn các cuộc tấn công SQL SQL không? Nếu không, tai sao không? Cơ sở dữ liệu có thể được bảo mật chống lại các cuộc tấn công như vậy bằng các biện pháp cụ thể (chỉ) cơ sở dữ liệu không?

BIÊN TẬP

Nhấn mạnh của câu hỏi thay đổi một chút, trong ánh sáng của các câu trả lời ban đầu nhận được. Câu hỏi cơ bản không thay đổi.

EDIT2

Cách tiếp cận dựa vào các truy vấn tối ưu hóa dường như chỉ là một bước ngoại vi trong phòng thủ chống lại các cuộc tấn công vào các hệ thống. Đối với tôi, dường như các biện pháp phòng vệ cơ bản hơn đều được mong muốn và có thể khiến việc phụ thuộc vào các truy vấn đó là không cần thiết, hoặc ít quan trọng hơn, thậm chí để bảo vệ chống lại các cuộc tấn công tiêm chích.

Cách tiếp cận ngầm trong câu hỏi của tôi dựa trên cơ sở dữ liệu "bọc thép" và tôi không biết liệu đó có phải là một lựa chọn khả thi hay không. Nghiên cứu sâu hơn đã gợi ý rằng có những cách tiếp cận như vậy. Tôi đã tìm thấy các nguồn sau đây cung cấp một số gợi ý cho kiểu tiếp cận này:

http://database-programmer.blogspot.com

http://thehelsinkideclaration.blogspot.com

Các tính năng chính tôi đã lấy từ các nguồn này là:

1. Một từ điển dữ liệu rộng lớn, kết hợp với một từ điển dữ liệu bảo mật mở rộng
2. Tạo các kích hoạt, truy vấn và ràng buộc từ từ điển dữ liệu
3. Giảm thiểu mã và tối đa hóa dữ liệu

Mặc dù các câu trả lời tôi đã có cho đến nay rất hữu ích và chỉ ra những khó khăn phát sinh từ việc bỏ qua các truy vấn tối ưu hóa, cuối cùng chúng không trả lời (các) câu hỏi ban đầu của tôi (hiện được nhấn mạnh bằng chữ in đậm).

Procs lưu trữ không tự động bảo vệ chống tiêm. Cái này thì sao

CREATE PROC proc
  @id VARCHAR(5)
AS
BEGIN
  EXEC("SELECT * FROM Client WHERE ClientId = " + @id);
END

Sử dụng các truy vấn tham số sẽ bảo vệ bạn khỏi tiêm, cho dù chúng có trong procs hay không.

Vì vậy, một tập hợp các quy tắc (được thi hành) như đây là một sự thay thế phù hợp cho các thủ tục được lưu trữ trong việc ngăn chặn các cuộc tấn công tiêm nhiễm SQL? Nếu không, tai sao không?

Không, bởi vì họ gây ra một hình phạt nặng nề cho các nhà phát triển. Bảng phân tích cho mỗi mục:

1. Không có ứng dụng khách / ứng dụng nào có quyền truy cập trực tiếp vào các bảng cơ sở dữ liệu.

Sử dụng vai trò. Khách hàng chỉ có thể truy cập DB thông qua vai trò bị hạn chế chỉ có quyền truy cập CHỌN, CHERTN, CẬP NHẬT và XÓA vào các bảng đó (và các hàng, nếu có thể) mà nó cần truy cập. Nếu bạn muốn đảm bảo rằng không có khách hàng nào có thể spam hoặc xóa tất cả các mục, hãy sử dụng API để sửa đổi dữ liệu.

2. Tất cả các truy cập vào tất cả các bảng đều thông qua lượt xem.

Đó có thể là bất cứ điều gì từ không đáng kể đến chi phí hiệu suất lớn, tùy thuộc vào hiệu quả của các lượt xem. Đó là sự phức tạp không cần thiết làm chậm sự phát triển. Sử dụng vai trò.

3. Tất cả các mục dữ liệu có một miền được chỉ định.

Có thể là rất nhiều công việc để duy trì, và có lẽ nên được chuẩn hóa thành một bảng riêng biệt.

4. Không có mục dữ liệu nào được phép là vô hiệu - điều này có ý nghĩa khiến các DBA nghiến răng đôi khi; nhưng đã được thi hành

Điều đó hoàn toàn sai. Nếu các nhà phát triển không thể xử lý NULL, bạn có vấn đề lớn.

Cơ sở dữ liệu có thể được bảo mật chống lại các cuộc tấn công như vậy bằng các biện pháp cụ thể (chỉ) cơ sở dữ liệu không?

Bạn không cần các thủ tục được lưu trữ, chỉ cần sử dụng các truy vấn tham số với hàm thoát khỏi các đối số, chẳng hạn như pg_query_params . Tất nhiên, nếu cơ sở dữ liệu của bạn có thể ghi được trên thế giới hoặc vai trò khách hàng có toàn quyền truy cập vào mọi thứ, dù sao bạn cũng bị lừa. Ai đó chỉ cần đi cùng và nhận ra những gì khách hàng đang làm, và sau đó nấu một khách hàng trong năm phút phá hủy (hoặc tệ hơn là các chất độc) DB của bạn.

Tôi không chắc chắn các quy tắc của bạn sẽ bảo vệ bạn hoàn toàn.

Vấn đề đầu tiên là bạn tuyên bố rằng họ đã thi hành nhưng, cũng như đi kèm với một chi phí đáng kể, tôi chưa bao giờ thấy việc thực thi hoàn hảo.

Thứ hai, tôi đọc về chúng là các quy tắc như thế này có thể khiến mọi thứ khó khai thác hơn nhưng chúng không ngăn chặn được. Chẳng hạn, việc không có quyền truy cập trực tiếp vào các bảng không thực sự thay đổi nhiều nếu các khung nhìn cho phép bạn truy cập cùng một dữ liệu. Nếu khách hàng cần làm một cái gì đó thì một khung nhìn cần phải tạo điều kiện cho điều đó và nếu một khung nhìn tạo điều kiện cho nó thì chức năng / dữ liệu tương tự có thể được sử dụng bởi kẻ tấn công.

Hãy nhớ rằng nó không chỉ là về việc cập nhật hoặc xóa dữ liệu. Một phần của lỗ hổng với SQL tiêm là thu thập thông tin và do đó bạn không quan tâm liệu dữ liệu đã được truyền trở lại qua chế độ xem vCustomers hay bảng Khách hàng bên dưới. Bạn có thể đã bảo vệ mình khỏi một số điểm yếu nhưng không phải tất cả. Tương tự nếu các bản cập nhật có thể được thực hiện bởi máy khách, ngay cả khi thông qua các kích hoạt, thì SQL có thể được viết để kích hoạt các kích hoạt và thực hiện cập nhật.

(Về tất cả các cập nhật được thực hiện thông qua kích hoạt, tôi sẽ nói hai điều: (1) khi tôi đọc điều này, tôi đã bị một chút bệnh trong miệng và (b) bạn không thích Thủ tục lưu trữ vì chúng ' lại "ít bảo trì hơn, ít kiểm tra hơn, kết nối cao và khóa hệ thống vào một nhà cung cấp" nhưng bạn sử dụng các kích hoạt về những điều tương tự về cơ bản có thể nói.)

Tất cả những gì bạn cần là một lỗ hổng cho phép thực thi các câu lệnh SQL (và tôi không thấy bất kỳ quy tắc nào ngăn chặn điều đó) và kẻ tấn công đang ở trong. Chúng có thể tìm thấy một cơ sở dữ liệu rất không trực quan đằng sau chúng nhưng nếu chúng được xác định thì sẽ chỉ làm chậm chúng chứ không dừng chúng).

Một điều khác ở đây là bạn cũng đang thêm độ phức tạp và (cũng như chi phí tạo ra), sự phức tạp có xu hướng dẫn đến các lỗ hổng có thể bị khai thác.

Tôi không nói rằng một bộ quy tắc như vậy không thể được tạo ra - nhiều hơn tại sao bạn lại bận tâm? Chúng có vẻ cồng kềnh và kém tin cậy hơn là chỉ sử dụng các phương pháp được chấp nhận rộng rãi để ngăn chặn kiểu tấn công này.