ID cơ sở dữ liệu phơi bày - rủi ro bảo mật?

Tôi đã nghe nói rằng việc lộ ID cơ sở dữ liệu (ví dụ: trong URL) là một rủi ro bảo mật, nhưng tôi gặp khó khăn để hiểu tại sao.

Bất kỳ ý kiến ​​hoặc liên kết về lý do tại sao nó là một rủi ro, hoặc tại sao nó không?

EDIT: tất nhiên quyền truy cập nằm trong phạm vi, ví dụ: nếu bạn không thể thấy tài nguyên, foo?id=123bạn sẽ gặp một trang lỗi. Nếu không, chính URL phải là bí mật.

EDIT: nếu URL là bí mật, có thể nó sẽ chứa mã thông báo được tạo có thời gian giới hạn, ví dụ: hợp lệ trong 1 giờ và chỉ có thể được sử dụng một lần.

EDIT (vài tháng sau): cách thực hành ưa thích hiện tại của tôi cho việc này là sử dụng UUIDS cho ID và phơi bày chúng. Nếu tôi đang sử dụng các số liên tiếp (thường để thực hiện trên một số DB) làm ID tôi thích tạo mã thông báo UUID cho mỗi mục nhập dưới dạng khóa thay thế và phơi bày điều đó.

Với các điều kiện thích hợp, việc lộ số nhận dạng không phải là rủi ro bảo mật. Và, trong thực tế, sẽ vô cùng nặng nề khi thiết kế một ứng dụng web mà không để lộ các định danh.

Dưới đây là một số quy tắc tốt để làm theo:

1. Sử dụng bảo mật dựa trên vai trò để kiểm soát quyền truy cập vào một hoạt động. Làm thế nào điều này được thực hiện tùy thuộc vào nền tảng và khung bạn đã chọn, nhưng nhiều người hỗ trợ mô hình bảo mật khai báo sẽ tự động chuyển hướng trình duyệt đến bước xác thực khi một hành động yêu cầu một số quyền.
2. Sử dụng bảo mật lập trình để kiểm soát truy cập vào một đối tượng. Điều này khó hơn để làm ở cấp độ khung. Thường xuyên hơn, đó là thứ bạn phải viết vào mã của mình và do đó dễ bị lỗi hơn. Kiểm tra này vượt ra ngoài kiểm tra dựa trên vai trò bằng cách đảm bảo không chỉ người dùng có thẩm quyền cho hoạt động, mà còn có các quyền cần thiết đối với đối tượng cụ thể được sửa đổi. Trong một hệ thống dựa trên vai trò, thật dễ dàng để kiểm tra rằng chỉ những người quản lý mới có thể tăng lương, nhưng ngoài ra, bạn cần đảm bảo rằng nhân viên đó thuộc về bộ phận quản lý cụ thể.
3. Đối với hầu hết các bản ghi cơ sở dữ liệu, điều kiện 1 và 2 là đủ. Nhưng việc thêm ID không thể đoán trước có thể được coi là một bảo hiểm bổ sung nhỏ hoặc "bảo mật chuyên sâu" nếu bạn mua vào khái niệm đó. Tuy nhiên, một nơi mà các định danh không thể đoán trước là một điều cần thiết, tuy nhiên, là trong ID phiên hoặc các mã xác thực khác, trong đó chính ID xác thực một yêu cầu. Chúng nên được tạo bởi một RNG mật mã.

Mặc dù không phải là rủi ro bảo mật dữ liệu nhưng đây hoàn toàn là rủi ro bảo mật thông tin kinh doanh vì nó phơi bày cả kích thước và tốc độ dữ liệu. Tôi đã thấy các doanh nghiệp bị tổn hại bởi điều này và đã viết về mô hình chống sâu này. Trừ khi bạn chỉ đang xây dựng một thử nghiệm chứ không phải là một doanh nghiệp, tôi rất khuyên bạn nên giữ id riêng tư của bạn ngoài tầm nhìn công khai. https://medium.com/lightrail/prevent-business-intellect-leaks-by-USE-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

Nó phụ thuộc vào những gì ID đại diện cho.

Hãy xem xét một trang web vì lý do cạnh tranh không muốn công khai số lượng thành viên họ có nhưng bằng cách sử dụng ID tuần tự sẽ tiết lộ nó trong URL: http://some.domain.name/user?id=3933

Mặt khác, nếu họ sử dụng tên đăng nhập của người dùng thay vào đó: http://some.domain.name/user?id=some họ sẽ không tiết lộ bất cứ điều gì mà người dùng chưa biết.

Suy nghĩ chung đi theo những dòng này: "Tiết lộ ít thông tin về hoạt động bên trong của ứng dụng của bạn cho bất kỳ ai."

Việc lộ ID cơ sở dữ liệu được tính là tiết lộ một số thông tin.

Lý do cho điều này là tin tặc có thể sử dụng bất kỳ thông tin nào về hoạt động bên trong ứng dụng của bạn để tấn công bạn hoặc người dùng có thể thay đổi URL để truy cập vào cơ sở dữ liệu mà họ không cho phép xem?

Chúng tôi sử dụng GUID cho id cơ sở dữ liệu. Rò rỉ chúng là rất ít nguy hiểm.

Nếu bạn đang sử dụng ID số nguyên trong db của mình, bạn có thể giúp người dùng dễ dàng xem dữ liệu họ không nên bằng cách thay đổi biến qs.

Ví dụ: người dùng có thể dễ dàng thay đổi tham số id trong qs này và xem / sửa đổi dữ liệu họ không nên http: // someurl? Id = 1

Khi bạn gửi id cơ sở dữ liệu đến máy khách của mình, bạn buộc phải kiểm tra bảo mật trong cả hai trường hợp. Nếu bạn giữ id trong phiên web của mình, bạn có thể chọn nếu bạn muốn / cần làm điều đó, nghĩa là có khả năng xử lý ít hơn.

Bạn liên tục cố gắng ủy thác mọi thứ cho kiểm soát truy cập của mình;) Đây có thể là trường hợp trong ứng dụng của bạn nhưng tôi chưa bao giờ thấy một hệ thống back-end nhất quán như vậy trong toàn bộ sự nghiệp của mình. Hầu hết trong số họ có các mô hình bảo mật được thiết kế để sử dụng không phải trên web và một số đã có các vai trò bổ sung được bổ sung sau đó, và một số trong số này đã được chốt bên ngoài mô hình bảo mật cốt lõi (vì vai trò đã được thêm vào trong bối cảnh hoạt động khác, nói trước web).

Vì vậy, chúng tôi sử dụng id cục bộ của phiên tổng hợp vì nó ẩn càng nhiều càng tốt.

Ngoài ra còn có vấn đề về các trường khóa không nguyên, có thể là trường hợp cho các giá trị được liệt kê và tương tự. Bạn có thể cố gắng vệ sinh dữ liệu đó, nhưng rất có thể bạn sẽ kết thúc giống như những chiếc bàn nhỏ bé .