Phát hiện SQL Injection

Question

Tôi đã đến một công ty đã có một dự án phát triển đầy đủ ... nhưng các lập trình viên đã làm việc ở đây trước khi tôi không tuân theo các quy ước và không sử dụng các truy vấn SQL parametrized ... kết quả là đã kết thúc 1000 địa điểm trong một dự án rất lớn có thể dễ bị tấn công bởi SQL injection ...

Tôi cần tìm một giải pháp tự động phát hiện nếu có SQL injection trong mã. Vì vậy, ví dụ có một biểu mẫu cho phép người dùng nhập nhận xét về sản phẩm, sẽ được gửi đến cơ sở dữ liệu khi gửi ... làm cách nào để đảm bảo rằng người dùng không nhập truy vấn độc hại thay vì văn bản bình thường?

Có bất kỳ mã/biểu thức chính quy/biểu thức chính quy nào có thể phát hiện nếu văn bản này chứa một phần truy vấn SQL thay vì văn bản vô hại bình thường không? Tôi sẽ chấp nhận bất kỳ liên kết, phần mã trong bất kỳ ngôn ngữ hoặc thậm chí phần mềm thương mại sẽ làm điều đó cho tôi.

Cảm ơn bạn

Answer 1

Không có viên đạn bạc ở đây. Việc tiêm SQL có thể có nhiều dạng bị che khuất và cố gắng phát hiện chúng bằng cách sử dụng biểu thức chính quy hoặc dạng khác trong tường lửa của bạn hoặc ứng dụng có thể bảo vệ bạn khỏi các dạng SQL injection đơn giản nhất. Như AdaTheDev đã lưu ý, các công cụ tự động kiểm tra mã của bạn, chẳng hạn như Công cụ phân tích mã MS, có thể cung cấp cho bạn một khởi đầu, nhưng lại không có viên đạn bạc. Bạn sẽ cần phải trải qua toàn bộ ứng dụng của mình.

Khi điều này là rất nhiều công việc, bạn nên lập kế hoạch. Trước hết, hãy đưa ra một hướng dẫn cho biết các loại tấn công này có thể được giảm thiểu như thế nào. Cũng cố gắng chia ứng dụng của bạn thành nhiều phần, từ rất quan trọng đến ít quan trọng hơn. Bằng cách này bạn có thể ước tính tốt hơn chi phí sửa chữa các lỗi và có thể cho phép quản lý quyết định những gì nó có thể chi phí và do đó những gì họ có nguy cơ sẵn sàng để có. Các phần của ứng dụng của bạn mà người dùng chưa được xác thực có thể truy cập là quan trọng nhất. Nếu mọi người (trên thế giới) có thể tạo một tài khoản trong ứng dụng của bạn, tất cả các chức năng mà những người dùng này có thể truy cập là rất quan trọng. Dân số càng nhỏ và bạn càng tin tưởng những người dùng đó thì rủi ro càng nhỏ. Bạn có lẽ có thể lấy đi với sửa chữa những phần sau này. Nhưng đừng bao giờ đánh giá thấp một hacker tốt. Anh/cô ấy có thể thỏa hiệp tài khoản của người dùng có đặc quyền cao và bắt đầu thử nghiệm khả năng chèn SQL bằng tài khoản đó.

Luôn cố gắng bảo vệ chiến lược sâu, có nhiều (hoặc nhiều) lớp bảo vệ. Ví dụ, không bao giờ kết nối với cơ sở dữ liệu của bạn như SA từ bên trong ứng dụng của bạn. Tạo một tài khoản chỉ với các đặc quyền cần thiết và thậm chí có thể tạo nhiều tài khoản SQL, một tài khoản cho mỗi vai trò (hoặc cho mỗi nhóm vai trò). Trong khi hạn chế các đặc quyền đối với cơ sở dữ liệu giúp rất nhiều trong việc giảm thiểu rủi ro, một lần nữa, không đặt cược vào nó như là một lớp bảo vệ. Ví dụ: This article, giải thích cách một hacker có thể lạm dụng tài khoản đặc quyền thấp hơn khi cô ấy có thể thực hiện việc tiêm SQL. Thật đáng ngưỡng mộ khi bạn hỏi câu hỏi này ở đây, bởi vì tôi đã thấy nhiều nhà phát triển trong quá khứ, những người không muốn biết, điều này rất đáng sợ, bởi vì doanh nghiệp thường tin tưởng các nhà phát triển của nó (điều đáng sợ như tốt).

Chúc các bạn may mắn nhất.

Answer 2

Tôi hoan nghênh sự sẵn sàng của bạn để lặn ở và sửa chữa mọi thứ, và không chỉ nhún vai và nói, "ehh .. không ai sẽ tấn công trang web của chúng tôi nào".

Tôi nghĩ rằng có lẽ cách tiếp cận tốt nhất là vệ sinh đầu vào, giả sử họ vô tội, trên bảng. Vấn đề là, có thể có lý do chính đáng để ai đó nhập bất kỳ ký tự nào có thể kích hoạt SQL Injection.

Chỉ cố gắng phát hiện các mẫu như vậy sẽ phải chịu kết quả 'tấn công' dương tính giả; Có thể ai đó cố gắng tìm kiếm john's car, không biết chút nào rằng báo giá đơn có thể là 'xấu'. Và có lẽ họ thực sự cần phải tìm kiếm điều đó. Hoặc, bạn có những gì ...

Answer 3

Bạn cần kiểm tra bất kỳ biến nào được chuyển vào chuỗi SQL. Đối với các giá trị chuỗi, bạn phải thay thế mọi phiên bản của một trích dẫn đơn với một dấu ngoặc kép. Đối với các giá trị không phải chuỗi (những giá trị sẽ chuyển cho SQL không được kiểm soát), bạn phải đảm bảo chúng được nhập mạnh.

Ví dụ: không vượt qua một cái gì đó như "SELECT * FROM Users WHERE UserID = " + my_string_user_id. Thay vào đó, hãy sử dụng mã "SELECT * FROM Users WHERE UserID = " + userId_as_int.

Điều này đã hoạt động trở lại vào ngày mà tôi có một codebase tương tự mà không có truy vấn được tham số nào cả.

Answer 4

Để thực sự làm điều này đúng, bạn cần phải chỉ cần chia ứng dụng và đi qua nó một mô-đun/trang/lớp/bất cứ lúc nào.

Điều này sẽ cho phép bạn không chỉ khắc phục sự cố mà còn để trở nên quen thuộc hơn với cơ sở mã nói chung.

CẬP NHẬT
Dựa trên những nhận xét tôi muốn thêm điều thêm một:

Điều duy nhất một công cụ có thể làm là nói cái nhìn, đây là một số đầu vào unsanitized ... Trong đó, nhiều khả năng, là sẽ chỉ là về mọi truy vấn trong ứng dụng của bạn. Điều này có nghĩa là bạn sẽ có danh sách khoảng 3000 tệp để sửa chữa.

Tại thời điểm đó, điều duy nhất bạn có thể làm là chỉ định một ngày, như Thứ Sáu, là Ngày sửa lỗi Sql. Chia công việc và sau đó để mọi người dành một ngày (hoặc thậm chí chỉ một vài giờ) viết lại các truy vấn trên một vài trang.

Tại một thời điểm nào đó, bạn sẽ hoàn thành hoặc tìm đủ những thứ khác sai để xác định xem bắt đầu lại có phải là một ý tưởng hay không.

Answer 5

Bạn có thể cung cấp cho các MS Code Analysis Tool một whirl đó (báo giá):

CAT.NET là một mã nhị phân phân tích công cụ giúp xác định các biến thể phổ biến của nhất định lỗ hổng phổ biến có thể làm phát sinh tấn công phổ biến vectơ như Cross-Site Scripting (XSS), SQL Injection và XPath Tiêm.

Không bao giờ tự mình sử dụng, nhưng có thể đáng để thử.