2015-01-04 12 views
6

Cũng giống như tiêu đề cho biết: Điều gì, nếu có, là những tác động an ninh cần được xem xét khi sử dụng và/hoặc đi qua các phương pháp ẩn danh (Action<>, Func<>) trong C#?Các tác động bảo mật cho việc chấp nhận các phương thức nặc danh (Action <>, Func <>) như các tham số là gì?

Phương thức chấp nhận Action<>/Func<> có vẻ là cách tiềm năng để mã ngoại được đưa vào chương trình. Đối với hồ sơ, tôi hiểu rằng phương pháp hoặc chức năng được tiêm không thể thực hiện những điều không an toàn vốn có trong ý nghĩa truy cập bộ nhớ tùy ý, nhưng tôi nghĩ rằng nó có thể cho phép mã gọi điện thoại, ví dụ: tùy ý các chức năng khung .Net, dữ liệu bị hỏng hoặc làm cho ứng dụng bị lỗi.

Giả định này có sai không?

Nếu không, bạn nên làm gì để khóa những thứ này? Ngoài ra, có cách nào để xác thực /Func<> được chuyển vào một phương thức hoặc chức năng để đảm bảo rằng nó có dạng mong muốn hoặc hạn chế quyền truy cập của nó đối với một số loại và không gian tên nhất định không?

Ngoài ra, hãy tha thứ cho tôi nếu tôi không sử dụng đúng thuật ngữ đúng, tôi vẫn đang học.

+0

Cũng lưu ý rằng bạn có thể tiêm mã độc thông qua kế thừa (bằng cách ghi đè các phương thức ảo và trừu tượng) và triển khai giao diện. Nhưng câu trả lời của SLaks cũng áp dụng cho những trường hợp này. Ví dụ, lớp 'System.String' bảo vệ chính nó khỏi bị niêm phong. –

+0

Kịch bản là gì?Mã đáng tin cậy và không đáng tin cậy trong cùng một quy trình được phân cách bởi CAS? – usr

+0

@usr Tôi thực sự hỏi nếu có * là * kịch bản trong đó có bất kỳ mối quan tâm nào. Tôi đã nhìn thấy một số giải pháp trên đây mà sử dụng như một cách để, ví dụ, vượt qua một getter tài sản hoặc setter đến một phương pháp được đặt tên bằng cách gói nó trong một trong những. Nhưng điều đó cảm thấy không chính xác bởi vì không có cách nào, theo như tôi biết, đối với phương thức được đặt tên để đảm bảo hoặc bảo đảm rằng Hành động được truyền <> hoặc Func <> đang hoạt động theo cách mong đợi. Có phải đó là thực hành xấu để sử dụng chúng như các tham số trừ khi phương pháp được đặt tên thực sự không quan tâm những gì nó làm? Ví dụ. Assert.ThrowsException (). –

Trả lời

9

Một phương pháp mà chấp nhận hành động <>/Func <> có vẻ là một cách tiềm năng cho mã nước ngoài được tiêm vào một chương trình

Đó là hoàn toàn sai. Bất cứ ai đang gọi chức năng của bạn và đi qua một đại biểu, theo định nghĩa, đã chạy mã trong chương trình của bạn.
Bất kỳ mã nào đi qua đại biểu đều có thể làm bất cứ điều gì nó muốn. Bạn không thể có ranh giới bảo mật trong cùng một AppDomain. (các phiên bản cũ hơn của .Net có Mã Truy Cập Bảo Mật, đã cố gắng thực hiện điều này, nhưng không phải là một ý tưởng hay)

Tuy nhiên, nó có thể tạo ra sự reentrancies bất ngờ, có thể gây ra vấn đề với mã an toàn chỉ.

+0

Tôi nghĩ rằng tôi hiểu. Bạn đang nói rằng bất cứ điều gì có thể chạy chỉ có thể gọi mã chính nó và không có gì có thể đạt được bởi các mã độc hại giả định khi làm như vậy? Hãy nói rằng có một lối vào lại cố ý gây ra. Điều đó có nguy cơ bảo mật hay chỉ có khả năng làm mất ổn định chương trình? Nếu tôi vượt qua trong một vòng lặp vô hạn, đó có thể là một vấn đề tôi sẽ tưởng tượng. Nếu có, có đề xuất thiết kế nào để giảm thiểu rủi ro không? Chẳng hạn như sử dụng ít, nội bộ, và nếu công khai, kiểm tra kỹ lưỡng để tái nhập cảnh và bất ổn? –

+0

@NickBauer: Một lần nữa, trừ khi bạn có ranh giới bảo mật thực sự, không có bảo mật để nói về. Xem http://blogs.msdn.com/b/oldnewthing/archive/2014/05/29/10529251.aspx và http://blogs.msdn.com/b/oldnewthing/archive/2007/08/07/4268706 .aspx # 4282521 – SLaks

+0

Được rồi, tôi ở bên bạn. Nhưng tôi vẫn tò mò về những gì bạn có ý nghĩa liên quan đến tái nhập cảnh, kể từ khi bạn đề cập đến nó. EDIT: Đó là, không phải là tái nhập cảnh là một vấn đề, nhưng nếu cho phép một cửa sổ để tái nhập cảnh theo cách này có thể là một vấn đề. –

2

Tôi thực sự yêu cầu nếu có kịch bản

Quay lại khi chính sách CAS vẫn đang được sử dụng (ví dụ vừa tin tưởng ASP.NET) một mảnh đáng tin cậy của mã có thể không an toàn gọi mã không tin cậy khi có xác nhận ngăn xếp. Ví dụ: khi

new SecurityPermission(Unrestricted).Assert() 

đang có hiệu lực, việc kiểm tra ngăn xếp kiểm tra bảo mật sẽ dừng lại tại thời điểm này. Điều đó có thể dẫn đến mã không đáng tin cậy không được phát hiện. See the docs for Assert.

Tôi hơi mơ hồ ở đây vì kịch bản khó có thể kéo ra được và nó đã lỗi thời.


Trong trường hợp không có ranh giới tin cậy bên trong cùng một quy trình, người gọi đã có tất cả sức mạnh ngay cả khi không có mã tiêm ở đâu đó. Không cần điều đó.

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