MongoDB: có an toàn khi sử dụng ID của tài liệu "ở nơi công cộng" không?

Question

Tôi thực sự thích các id được tạo tự động của MongoDB. Chúng thực sự hữu ích.

Tuy nhiên, nó có được lưu để sử dụng chúng công khai không?

Giả sử có một bộ sưu tập bài đăng và trang/bài đăng có tham số id (như/posts/4d901acd8df94c1fe600009b) và hiển thị thông tin về bài đăng đó.

Bằng cách này, người dùng/hacker sẽ biết id đối tượng thực của tài liệu. Có ổn không hoặc nó có an toàn không?

Cảm ơn

Answer 1

Sez here, ID được tạo tự động bao gồm ID máy 3 byte (có thể là băm của địa chỉ MAC). Nó không phải là không thể nghĩ rằng ai đó có thể tìm ra những thứ về mạng nội bộ của bạn bằng cách so sánh ba byte trong các id khác nhau, nhưng trừ khi bạn đang làm việc cho Lầu Năm Góc mà dường như không đáng lo ngại (bạn có nhiều khả năng dễ bị tổn thương hơn một cái gì đó nhàm chán hơn như một Apache bị định cấu hình sai).

Khác hơn thế, quyền của Epcylon; không có gì vốn không an toàn về việc hiển thị id thông qua URL. Dù là xấu xí cũng là một vấn đề khác. Bạn có thể base64 chúng để làm cho chúng ngắn hơn (được suy nghĩ về điều này bản thân mình), nhưng sau đó có thực tế kỳ lạ mà họ đang tất cả về một nửa giống nhau ...

Answer 2

Tôi không có kinh nghiệm với MongoDB trong một môi trường sản xuất, vì vậy đừng lấy câu trả lời của tôi là sự thật, nhưng tôi không thể tưởng tượng được tại sao nó không phải là an toàn.

So sánh với cột loại ID tự động trong RDBMS. Bạn tiếp xúc với những người bên ngoài tất cả các thời gian, tôi không biết lý do nào để không làm tương tự với id MongoDB.

Như mọi khi, bảo mật phải xác thực đầu vào của bạn và không cho phép bất kỳ ai ở gần cơ sở dữ liệu của bạn mà không được bảo vệ thích hợp. Làm điều đó đúng và nó không quan trọng nếu họ biết làm thế nào để chọn một đối tượng cụ thể trong cơ sở dữ liệu của bạn, vì họ vẫn không thể làm bất cứ điều gì với nó.

Answer 3

Nó không phải bất kỳ an toàn hơn bằng cách sử dụng giá trị của id tăng tự động từ MySql. Nó không phải là một vi phạm an ninh trong bất kỳ cách nào.

Answer 4

Có thể nghĩ về điều này là một sự riêng tư riêng tư hơn security.

Tôi đang đối mặt chính xác cùng một vấn đề. Khi lưu trữ nội dung do người dùng đóng góp trong các thư mục có thể truy cập web dựa trên ID do Mongo tạo, có nguy cơ nếu những ID đó có thể dự đoán được rằng một người dùng có thể truy cập nội dung của người dùng khác.

Tôi nghĩ lời khuyên của người khác là đúng tuyến đường: biết URL của nội dung cá nhân dành riêng cho người dùng không đủ để truy cập vào. Nỗ lực truy cập nên kiểm tra người dùng phù hợp đang đưa ra yêu cầu.

Tôi dự định thực hiện điều này trong Symfony2 bằng cách lưu trữ nội dung người dùng bên ngoài của gốc web, sau đó cho phép truy cập thông qua tuyến mới/Bộ điều khiển trước khi vượt qua phản hồi sẽ xác thực một số thông tin nhận dạng về người dùng.

Answer 5

Tôi nghĩ mongodb _id được dựa trên một dấu thời gian và địa chỉ ngắt và những thứ khác bạn có thể muốn giữ riêng tư.

Nếu bạn lo lắng nó có thể đáng giá trị mã hóa nội dung mong muốn và sử dụng kết quả dưới dạng mã định danh phía máy khách (và sau đó bỏ mã hóa khi yêu cầu quay lại).

Nếu khóa mã hóa một phần dựa trên một số thuộc tính duy nhất của người dùng hoặc phiên được đề cập, khiến người dùng khó truy cập nội dung khi họ không nên.

Rõ ràng là vẫn quan trọng để xác thực người dùng bằng các phương tiện khác!

Answer 6

1. Nếu id cung cấp liên kết đến nội dung "không công khai" chỉ yêu cầu liên kết - đó là vấn đề riêng tư.

2. Nếu id cung cấp liên kết đến nội dung dưới đăng nhập của người dùng - không phải là vấn đề.

Cho dù đó là MongoDb, SQL hay bất kỳ id nào khác. Id là chìa khóa cho dữ liệu. Nếu phím này chỉ là thứ bạn cần xem nội dung mà bạn không nên - đó là một vấn đề. Đối với tình huống như vậy - tạo id không có khả năng.