Bất cứ điều gì an toàn hơn các trường biểu mẫu ẩn trong ASP.NET MVC?

Question

Trong ASP.NET MVC (mặc định định tuyến), tôi muốn sử dụng một URL như thế này để trả về một View với một hình thức để chỉnh sửa một khách hàng:

/Customers/Edit/5 

tôi cần phải tận dụng CustomerId=5, nhưng Tôi không muốn cho phép một khách hàng thay đổi nó. Bây giờ tôi đã làm cho id bị ẩn bằng cách sử dụng:

<%= Html.Hidden("CustomerId") %> 

Điều này hoàn thành những gì tôi muốn, nhưng tôi cảm thấy rằng các biến dạng ẩn không an toàn và có thể được điều khiển bởi người dùng cuối.

Vì vậy, cách tốt nhất để cho phép khách hàng chỉnh sửa thông tin của họ chứ không phải ID của họ là gì?

Answer 1

Giải pháp của tôi là sử dụng mã Tamper Proofing từ Steven Sanderson's ASP.NET MVC book. Ý tưởng là bạn nên tạo một hash của bất kỳ hình thức lĩnh vực tiềm ẩn mà bạn muốn làm xáo trộn bằng chứng:

<%= Html.Hidden("CustomerId") %> 
<%= Html.Hidden("CustomerIdHash") %> 

Khi biểu mẫu được gửi, mã của Steven sau đó tính khác hash của ID khách hàng và làm cho chắc chắn nó bằng CustomerIdHash. Nếu có, thì không có sự giả mạo nào xảy ra. Đó là mã tuyệt vời, và đáng giá của cuốn sách.

Answer 2

Bạn không thực hiện bất kỳ bảo mật thực nào ở phía trình duyệt. Bạn có thể đặt ID khách hàng trong chuỗi truy vấn, nhưng máy chủ phải xác thực xem chúng có thực sự được phép chỉnh sửa khách hàng đó hay không. Nếu không, hãy trả lại lỗi.

Answer 3

Kiểm tra quyền trong hành động điều khiển của bạn (/ Khách hàng/Chỉnh sửa) trước khi bạn hiển thị chế độ xem theo dõi. Lưu ý rằng vấn đề ở đây không phải với trường ẩn của bạn chút nào: người dùng chỉ có thể nhập "http://yoursite.com/Customers/Edit/10" trong trình duyệt của mình. Vì vậy, bạn phải kiểm tra hành động của mình cho dù người dùng có thực sự được phép chỉnh sửa chi tiết của khách hàng được yêu cầu hay không, bất kể anh ta đã thực hiện hành động như thế nào.

Answer 4

Có hai khía cạnh. Tôi không chắc chắn bạn trực tiếp hỏi về điều gì, nhưng cả hai đều quan trọng:

• Đối với bất kỳ người dùng nào, họ không được phép chỉnh sửa tất cả khách hàng. Vì vậy, như Dmitry gợi ý, hành động điều khiển của bạn cho bài đăng biểu mẫu cần xem xét khách hàng mà họ đang cố chỉnh sửa và xác minh rằng người dùng đã đăng nhập thực sự được phép chỉnh sửa khách hàng đó. Bạn có thể cũng muốn thực hiện kiểm tra tương tự trong hành động điều khiển tạo biểu mẫu chỉnh sửa ngay từ đầu và thậm chí không cho phép họ vào biểu mẫu nếu họ không được phép chỉnh sửa khách hàng được yêu cầu.
• Đối với một người dùng nhất định và một khách hàng nhất định, có thể bạn không muốn người dùng có thể thay đổi ID khách hàng. Nếu bạn đang sử dụng phương thức UpdateModel trong hành động của trình điều khiển POST, bạn cần phải sử dụng tham số danh sách trắng thuộc tính và loại trừ thuộc tính ID để người dùng không thay đổi ID. Ngay cả khi chúng thay đổi giá trị của trường ẩn, giá trị thay đổi sẽ bị UpdateModel bỏ qua thông qua danh sách trắng.

Answer 5

Tôi gặp vấn đề tương tự và tôi tin rằng giải pháp liên quan đến việc sử dụng khóa thay thế. Trong mỗi bảng mà tôi có một cột ID, tôi cũng thêm một cột Key là một Guid (uniqueidentifier trong SQL server). Bây giờ, khi tham gia hoặc bất kỳ logic nội bộ nào tôi sử dụng ID nhưng bộ điều khiển đều sử dụng Khóa. Vì đó là một Guid, thật khó để đoán được Guid của một bản thu khác là gì.

Ngoài ra (hoặc bổ sung cho ở trên), bạn có thể mã hóa các lĩnh vực tiềm ẩn theo This article

Answer 6

Trường ẩn chống giả mạo là tất cả tốt và tốt nhưng đó vẫn là bảo mật thông qua sự tối tăm. Nó luôn luôn là tốt nhất để bảo đảm một trang web, cụ thể hơn MVC, bằng cách đảm bảo các bộ điều khiển và hành động. Sau đó, người dùng có thể giả mạo tất cả những gì họ muốn và họ sẽ không đi đâu cả.