ASP.NET MVC có dễ bị tấn công bằng đệm oracle không?

Question

ASP.NET MVC 2 có bị ảnh hưởng đến số oracle padding attack không? Nếu vậy, giải pháp nào cần được thực hiện? Các hướng dẫn trên blog của Scott Gu dường như chỉ dành cho Webforms.

Tôi cố gắng này:

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="/Home/ErrorPage" /> 

Tuy nhiên, http://www.example.com/PageThatDoesNotExist vẫn trả về một trang báo lỗi 404 tiêu chuẩn.

EDIT: Tôi thấy Scott Gu đã đăng trong nhận xét dưới bài đăng trên blog của mình rằng MVC dễ bị tổn thương, nhưng vẫn chưa rõ chính xác cách triển khai giải pháp thay thế.

Answer 1

Yes - liên kết với nhận xét của Scott Guthrie.

Thứ 7 18 Tháng 9, 2010 9:00 bởi ScottGu

@Vijay,

Liệu ASP.NET MVC quá bị ảnh hưởng?

Có - tất cả các phiên bản ASP.NET đều bị ảnh hưởng, kể cả ASP.NET MVC.

Cảm ơn,

Scott

Tôi thấy rằng bạn đã nhìn thấy những bình luận, nhưng nếu bạn chạy các script vbs trên máy chủ của bạn, nó sẽ cho bạn biết nếu nó vẫn còn là một vấn đề.

Chỉnh sửa: Ngoài ra, Scott đã thảo luận Câu hỏi thường gặp trong một bài đăng mới here.

Answer 2

Theo tuyến đường mặc định của bạn, bạn có thể/nên thêm này cho người mới bắt đầu

routes.MapRoute("Catch All", "{*path}", new { controller = "Home", action = "ErrorPage" }); 

Chỉnh sửa 2

vấn đề nằm ở phần redirectMode="ResponseRewrite" không có điều này, nó hoạt động.

sử dụng các tuyến đường mặc dù sẽ khắc phục 1 phần của vấn đề, nơi con đường không thể được tìm thấy (404)

phần tiếp theo, giống như những con đường hiện có với ID xấu hoặc dữ liệu khác, có thể được cố định với

<customErrors mode="On" defaultRedirect="/Home/ErrorPage" /> 

chính xác thì redirectMode="ResponseRewrite" làm gì?

Chỉnh sửa: những gì nó làm.

redirectMode

• ResponseRedirect: Chỉ định rằng URL chỉ đạo trình duyệt để phải khác với URL yêu cầu Web gốc.
• ResponseRewrite: Chỉ định URL để hướng trình duyệt đến phải là URL yêu cầu ban đầu URL yêu cầu.

Nó chỉ quan trọng đối với .NET 3.5 SP1 và .NET 4.0.

Chỉnh sửa 101:

Đối redirectMode = "ResponseRewrite" các ASP.NET gọi Server.Execute (...) trong nội bộ, mà không làm việc với các tuyến đường MVC, vì vậy cho MVC này chỉ làm việc với một tệp HTML tĩnh.

<customErrors mode="On" defaultRedirect="~/Views/Shared/error.htm" redirectMode="ResponseRewrite" /> 

hoạt động.

Answer 3

Bạn có thiết lập hành động/bộ điều khiển tuyến đường để trả về trang lỗi cho tuyến đường /Home/ErrorPage không?

Answer 4

Câu hỏi này được bao gồm trong Scott Gu của Frequently Asked Questions about the ASP.NET Security Vulnerability:

Điều này ảnh hưởng đến cả ASP.NET Web Forms và ASP.NET MVC?

Có - khai thác được tiết lộ công khai có thể được sử dụng đối với tất cả các loại ứng dụng ASP.NET (bao gồm cả biểu mẫu web và MVC).

Answer 5

Tôi đã đăng toàn bộ nội dung này (sau khi nghiên cứu thêm) trên my blog.

Cập nhật lưu ý: di chuyển liên kết đến một bài cụ thể để ASP.NET MVC

---

Tôi tin chắc rằng các vấn đề với 404s có liên quan đến WebResources và ScriptResources (có thể vô hiệu hóa cho asp.net MVC btw), vì chúng có thể cung cấp cho 404 khi tài nguyên tương ứng không được tìm thấy (đây sẽ là phản hồi bình thường đối với một padding hợp lệ cung cấp tên/tên tài nguyên không hợp lệ).

Các mã lỗi khác & thư có thể là vấn đề đối với các tính năng asp.net khác, nhưng kết thúc bằng 404 chỉ vì bạn nhấn url không liên quan đến bất kỳ trình xử lý đặc biệt nào không gây ra sự cố.

Cũng lưu ý những gì tôi đã đề cập trong câu trả lời này: How serious is this new ASP.NET security vulnerability and how can I workaround it?

nếu ứng dụng là asp.net MVC, chúng tôi không thực sự cần webresources.axd và/hoặc scriptresources.axd, vì vậy những người có thể được bật tắt. Chúng tôi cũng không sử dụng viewstate.

nhà cung cấp tư cách thành viên asp.net 'lưu trữ vai trò' trong cookie, tắt tính năng đó.

Cookie xác thực được ký và từ thông tin trong giấy, chúng không thể tạo cookie đã ký nếu chúng không nhận được khóa thực (như chúng đã làm trong video trước khi giả mạo cookie xác thực).

Như Aristos đã đề cập, cho id phiên trong cookie, đó là ngẫu nhiên cho phiên người dùng, vì vậy nó sẽ phải được đánh hơi từ người dùng với mức độ bảo mật đích và bị nứt trong khi phiên đó đang hoạt động. Thậm chí sau đó nếu bạn đang dựa vào xác thực để gán/ủy quyền cho các hoạt động của người dùng, thì tác động sẽ là tối thiểu/nó phụ thuộc rất nhiều vào phiên nào được sử dụng trong ứng dụng đó.

Answer 6

Bản vá lỗi này đã được phát hành trên Windows Update.

http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx