2012-09-26 11 views
6

Gần đây tôi đã thừa hưởng cơ sở mã ASP.NET MVC 4. Một vấn đề tôi lưu ý là việc sử dụng một số id cơ sở dữ liệu (ints) trong các url cũng như trong việc gửi biểu mẫu html. Mã trong trạng thái hiện tại của nó là có thể khai thác thông qua cả hai URL tinkering và tạo các bài viết HTML tùy chỉnh với các số khác nhau.Làm cách nào để ngăn không cho HTML của tôi bị khai thác trong khi tránh GUID?

Bây giờ trong khi tôi có thể dễ dàng khắc phục sự cố URL bằng cách sử dụng trạng thái phiên hoặc kiểm tra auth bổ sung, tôi ít chắc chắn hơn về id cơ sở dữ liệu được nhúng vào HTML mà trang web thoát ra (tức là tôi cung cấp cho họ trình đơn thả xuống lấp đầy). Khi các id trở lại trong một bài viết như thế nào tôi có thể chắc chắn tôi đặt chúng ở đó như là các tùy chọn hợp lệ? Điều gì được coi là "thực hành tốt nhất" về giải quyết vấn đề này?

Trong khi tôi đánh giá cao tôi chỉ có thể "GUID nó lên" Tôi do dự để làm như vậy bởi vì tôi thấy họ một nỗi đau trong ass để làm việc với khi gỡ lỗi cơ sở dữ liệu.

Tôi có lựa chọn ở đây không? Tôi có phải GUID để ngăn chặn dễ đoán các id hoặc có một số loại cơ chế DRY mà tôi có thể sử dụng để xác thực việc sử dụng các id khi chúng quay trở lại trang web không?

CẬP NHẬT: Người nhận xét hỏi về các lần khai thác mà tôi đang mong đợi. Cho phép nói rằng tôi nhổ ra một hình thức HTML với một danh sách thả xuống của tất cả các địa điểm người ta có thể nhập khẩu "kho báu" từ. Id của các vị trí mà người dùng sở hữu là 1,2 và 3, những vị trí này được cung cấp trong HTML. Nhưng người dùng kiểm tra html, fiddles với nó và quyết định đặt cùng một POST với id của 4 được chọn. 4 không phải là vị trí của anh ta, của người khác.

+3

Bạn muốn khai thác cơ chế nào? Bạn đang ở đâu trong tình huống không thích hợp dữ liệu có thể ảnh hưởng đến hệ thống của bạn? Sử dụng GUID không làm bất cứ điều gì vốn an toàn hơn. – PhonicUK

+0

Cập nhật OP cho bạn. Các hướng dẫn an toàn hơn trong trường hợp này bởi vì bạn không thể đoán được chúng. – Quibblesome

Trả lời

9

Xác thực ID được chuyển dựa vào ID mà người dùng có thể sửa đổi.

Có vẻ như tẻ nhạt, nhưng đây thực sự là cách duy nhất để đảm bảo người dùng có quyền truy cập vào những gì họ đang cố sửa đổi. Sử dụng GUIDs mà không cần xác nhận là bảo mật bởi tối nghĩa: chắc chắn đoán chúng là khó, nhưng bạn có khả năng đoán chúng được cung cấp đủ tài nguyên.

Bạn có thể thực hiện việc này ở đầu bộ điều khiển trước khi thực hiện bất kỳ điều gì khác với dữ liệu đã đăng. Nếu có một sự vi phạm, chỉ cần ném một ngoại lệ và có xử lý ngoại lệ toàn cầu của bạn đối phó với nó; bạn không cần phải xử lý nó một cách tuyệt vời vì bạn có thể giả định một cách an toàn rằng người dùng đang giả mạo dữ liệu theo cách không được hỗ trợ.

+1

Một chỉnh sửa khác: _it có thể thấy ** m ** tedious_. ; p - Tôi sẽ làm điều đó, nhưng thấy bạn thực hiện các chỉnh sửa của riêng bạn và không muốn va chạm. ;-) –

+0

@BradChristie - đã hoàn tất! – Omar

+0

Vì vậy, nếu tôi nhận được điều này thẳng có nghĩa là những thuộc tính vai trò asp.net cung cấp trên API là (ít nhất là thiết kế khôn ngoan) ít nhiều vô giá trị (chắc chắn họ giúp một chút nhưng họ không có viên đạn bạc cho auth) chúng tôi cần phải xác thực hầu hết các hoạt động của người dùng. Tôi nói vô giá trị bởi vì nếu người ta sử dụng chúng thì một phần cơ bản là phân chia mã auth giữa các thuộc tính và mã ở đầu các API, nơi nó sẽ có khả năng để có tất cả các auth ở một nơi .... Tôi đoán những gì tôi hỏi là nếu bạn vẫn sử dụng chúng. – Quibblesome

4

Vấn đề bạn mô tả được gọi là "tài liệu tham khảo đối tượng trực tiếp không an toàn", và nhóm OWASP khuyến cáo hai chính sách để đối phó với vấn đề này:

  1. sử dụng tài liệu tham khảo đối tượng gián tiếp dựa trên phiên và
  2. xác nhận tất cả quyền truy cập vào tham chiếu đối tượng.

Ví dụ về đề xuất # 1 sẽ thay vì có tùy chọn thả xuống 1, 2 và 3, bạn chỉ định mỗi tùy chọn GUID được liên kết với ID ban đầu trong bản đồ trong phiên của người dùng. Khi bạn nhận được một POST từ người dùng đó, bạn kiểm tra xem đối tượng nào được gán cho ID được cho là được gắn với. ESAPI của OWASP có một số thư viện để trợ giúp điều này bằng nhiều ngôn ngữ khác nhau.

Nhưng trong nhiều trường hợp, đề xuất # 1 thực sự phản tác dụng. Ví dụ: trong nhiều trường hợp, bạn muốn có URL có thể được sao chép/dán từ người dùng này sang người dùng khác. Quy trình # 2 thường được xem là cách dễ dàng nhất để giải quyết vấn đề này.

2

Bạn đang mô tả Broken Access Control với Id không an toàn. Khi bạn đã xác định được mối đe dọa và quyết định Id nào được sở hữu bởi một số người dùng nhất định, hãy đảm bảo kiểm tra được thực hiện cho phía máy chủ này.

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