2009-01-20 45 views
5

Gần đây tôi đã tham gia một công ty và khi phân tích môi trường của họ, tôi nhận thấy rằng SharePoint web.config có mức độ tin cậy được đặt thành Đầy đủ. Tôi biết đây là một thực tế khủng khiếp và hy vọng cộng đồng stackoverflow có thể giúp tôi vạch ra những sai sót trong quyết định này.ASP.NET - Cấp độ tin cậy = Đầy đủ?

Oh, dường như quyết định này được đưa ra để cho phép các nhà phát triển để triển khai dlls vào thư mục Bin mà không cần tạo các chính sách CAS. Thở dài.

Chỉ muốn làm rõ và làm cho vấn đề tồi tệ hơn, chúng tôi cũng đang triển khai mã của bên thứ ba vào ứng dụng web này.

Trả lời

1

Lỗi? Nhiều người. Nhưng điều nguy hiểm nhất là trực tiếp từ tiện ích CAS:

"... nó cho phép truy cập đầy đủ vào tài nguyên của máy tính như hệ thống tệp hoặc truy cập mạng, có khả năng hoạt động ngoài tầm kiểm soát của hệ thống bảo mật".

Điều đó có nghĩa là mã được cấp Full Trust có thể thực thi bất kỳ đoạn mã nào khác (được quản lý hoặc cách khác) trên hệ thống, có thể gọi qua mạng đến bất kỳ máy nào, có thể thực hiện bất kỳ điều gì trong hệ thống tệp. - ngay cả các tệp OS).

Hầu hết các lập trình viên web đều nói "đó không phải là vấn đề, nó chỉ là mã của tôi", đó là tốt .... cho đến khi một lỗ hổng bảo mật tạo ra trong mã của họ cho phép kẻ tấn công sử dụng nó để làm những điều không thích. Sau đó, Full Trust được cấp trước đó trở nên khá đáng tiếc.

+7

Đừng nhầm lẫn khái niệm bảo mật mã .NET của Full Trust với ủy quyền Windows. Đặt Full Trust không cấp bất kỳ quyền mới nào cho tài khoản của quy trình công nhân ASP.NET. Windows sẽ vẫn như vậy giới hạn quyền truy cập vào hệ thống tập tin theo DACLs vv –

+0

Đúng, nhưng với Full Trust một hội đồng có đủ thông tin Windows (được cho là chính sách CAS lỏng lẻo, đó là điều đầu tiên tôi tìm kiếm nếu tôi đang xem xét ứng dụng này ....) đơn giản có thể bắt đầu thay đổi DACL. – TheSmurf

+2

Eh ... no. Bạn có nghĩ rằng, ví dụ tài khoản khách chỉ có thể sửa đổi quyền trên các tệp OS và bắt đầu viết ngẫu nhiên? Bạn đã bao giờ gặp phải vấn đề trong thực tế với tài khoản iusr chưa? –

2

Nếu họ bỏ qua các chính sách CAS, có thể sẽ là một việc khó khăn để khiến họ quay lại, vì nó khiến công việc của họ khó khăn hơn một chút (hoặc ít nhất, ít được tha thứ hơn). Thay đổi các thực hành bảo mật luôn luôn khó khăn - như khi tôi phải thuyết phục sếp rằng việc sử dụng các tài khoản SA trong chuỗi kết nối SQL của các ứng dụng web của chúng tôi là một ý tưởng tồi - nhưng treo ở đó.

Tin cậy đầy đủ cho phép ứng dụng leo thang để kiểm soát bất kỳ tài nguyên nào trên máy tính. Mặc dù bạn phải có lỗ hổng bảo mật trong ứng dụng của mình để cho phép những điều này và có thể họ cho rằng họ đã ngăn chặn bất kỳ sự leo thang nào thông qua lập trình sắc sảo, nhắc nhở họ rằng ứng dụng web không có quyền kiểm soát toàn bộ máy tính? Ý tôi là, chỉ trong trường hợp?

EDIT: Tôi hơi quá hăng hái với ngôn ngữ của tôi ở đây. Full Trust sẽ cho phép ứng dụng kiểm soát bất cứ điều gì nó muốn, nhưng chỉ khi quá trình Hồ bơi ứng dụng có đủ quyền để làm điều đó. Vì vậy, nếu bạn đang chạy như một người dùng hạn chế không có quyền trên máy chủ ngoại trừ những gì các ứng dụng cần, sau đó tôi cho rằng về cơ bản không có rủi ro để "Full Trust". Thực tế là chủ sở hữu hồ bơi ứng dụng có nhiều khả năng bạn không muốn ứng dụng của mình có (và trong một số trường hợp, nhiều, nhiều hơn thế nữa), vì vậy an toàn hơn nhiều để hạn chế bảo mật ứng dụng và cấp quyền bổ sung cho ứng dụng. Cảm ơn vì đã sửa, Barry.

+2

"leo thang để kiểm soát bất kỳ tài nguyên nào" là ngôn ngữ quá mạnh. Bảo mật mã Full Trust độc lập và phụ thuộc vào bảo mật Windows. Các quyền của tiến trình công nhân ASP.NET được giới hạn trong các quyền của người dùng sở hữu quy trình. Tin cậy hoàn toàn không thể và không cấp quyền bổ sung ở đây. –

1

Tôi thành thật đã tìm thấy điểm cộng thêm quá hạn chế.

Hãy nhìn vào các trang sau để xem những gì có thể và không thể được thực hiện dựa trên mức tín nhiệm http://msdn.microsoft.com/en-us/library/ms916855.aspx

Một vấn đề tôi chạy vào ngay là tôi không thể sử dụng Caching Application Block. Chúng tôi đã sử dụng khối ứng dụng này thay vì bộ nhớ đệm ASP.NET vì chúng tôi đã sử dụng mẫu MVP và có thể mở ứng dụng biểu mẫu giành chiến thắng.

Một vấn đề khác không phản ánh, điều này khiến trang Giới thiệu thất bại vì số phiên bản được lấy từ siêu dữ liệu của hội đồng.

Tôi nghĩ giải pháp tốt nhất là không sử dụng Sharepoint làm ứng dụng lưu trữ. Tôi sẽ chỉ sử dụng Sharepoint như một máy chủ ứng dụng nếu số lượng mã hóa quá nhỏ đến nỗi nó không ảnh hưởng đến mức độ tin cậy và nó sẽ ít hoạt động hơn sau đó thiết lập một ứng dụng mới. Nếu bạn đang làm một số loại mã hóa mà đang bắt đầu để đạt các bức tường của mức độ tin tưởng, di chuyển ứng dụng của bạn vào một môi trường ASP.NET thích hợp. Nhưng đó chỉ là tôi, và tôi thiên vị. Có lẽ bạn nên cố gắng nhằm mục đích cho một sự tin tưởng mức độ trung bình thỏa hiệp.

+0

Nếu bạn làm việc với SharePoint lại, mức độ tin tưởng mặc định củaSharePoint có thể được thay đổi trong web.config của ứng dụng web. Mặc định là như vậy, mặc định. –

+0

Đôi khi, khi làm việc với các tổ chức lớn với các trang trại lớn hơn, họ sẽ có chính sách riêng của họ ngăn chặn bất kỳ thay đổi nào về mặc định. Lý do điển hình cho điều này là họ đang chạy rất nhiều trường hợp, họ muốn tất cả mọi thứ được cấu hình theo cùng một cách và với thiết lập ít nhất có thể. Vì vậy, thay đổi mặc định không phải lúc nào cũng là một tùy chọn. – Bob

4

Todd, Cuốn sách

, "Programming Microsoft ASP.Net 3.5", bởi Dino Espisito đưa ra một số lập luận vững chắc cho không cho phép toàn Trust trong các ứng dụng ASP.Net.

Trong số các lý do khác, Dino nói rằng các ứng dụng web tiếp xúc với internet là "một trong những môi trường thù địch nhất cho bảo mật máy tính bạn có thể tưởng tượng." Và:

ứng dụng được hiển thị công khai hoàn toàn đáng tin cậy là một nền tảng tiềm năng để tin tặc khởi động các cuộc tấn công. Ứng dụng ít được tin cậy hơn, an toàn hơn khi ứng dụng xảy ra .

Tôi ngạc nhiên khi cộng đồng StackOverflow không phác thảo vấn đề với Full Trust tốt hơn. Tôi đã hy vọng cho điều tương tự vì vậy tôi không phải đi đào qua đống sách của tôi để tìm câu trả lời, lười biếng tôi.

+0

Nó không chỉ là cộng đồng SO. thiếu 'lo lắng' về vấn đề FullTrust là phổ biến (và rất buồn) –

1

Tôi sử dụng toàn bộ niềm tin vào các máy phát triển của mình .. vì vậy tôi có thể triển khai vào BIN khi tạo mã mới. Tôi tin tưởng mã của riêng tôi và chạy nó trong GAC về sản xuất vì việc tạo ra các chính sách CAS là một nỗi đau.

Điều bên thứ ba sẽ phải tôi lo lắng .. tuy nhiên:

giải pháp của bên thứ 3 Hầu hết tìm thấy trên web cũng triển khai GAC (giả sử vì những lý do tương tự). Điều này mang lại cho họ tất cả các quyền bất kể mức độ tin cậy. Cảm thấy như nó có nhiều việc phải làm nếu bạn tin tưởng bên thứ ba hay không .. và bạn có thực sự tin tưởng các nhà phát triển của riêng mình không?

Hacker sẽ làm gì? Kịch bản mà một hacker đánh rơi một dll tà ác trong thư mục BIN của bạn, tôi không thấy là rất thực tế .. bất kể nếu anh ta có thể làm điều đó anh ta cũng có thể thay đổi mức độ tin cậy.

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