Công cụ dành cho nhà phát triển · Trình tạo UUID
ID tuần tự làm rò rỉ dữ liệu doanh nghiệp: Tại sao API công khai để lộ UUID
· Tại sao nó quan trọng
uuid mật mã browser-apis
ID tự động tăng cho người ngoài biết bạn nhận bao nhiêu đơn hàng và làm cho mọi bản ghi có thể đếm được. Bài đăng này giải thích những gì hiển thị UUID sẽ khắc phục, những gì không khắc phục được và cách giới thiệu chúng mà không cần di chuyển.
Số hóa đơn của bạn đang cho đối thủ cạnh tranh biết khối lượng của bạn — rò rỉ thông tin trong /orders/10482
Điểm cuối API trả về /orders/10482 cho người ngoài biết nhiều hơn chi tiết đơn hàng. Mã định danh dạng số báo hiệu rằng bạn đã xử lý ít nhất mười nghìn đơn hàng, hàm ý thông tin về tốc độ tăng trưởng của bạn và khiến mọi đơn hàng đều có thể đoán được. Một vòng lặp đơn giản thông qua các số liên tiếp sẽ truy xuất tất cả các bản ghi mà không cần kiểm tra xác thực hoặc quyền. Mẫu này xuất hiện ở mọi nơi—trong URL, khóa cơ sở dữ liệu, số hóa đơn và ID giao dịch—ngay cả khi hệ thống yêu cầu xác thực để xem bất kỳ bản ghi nào. Vấn đề phức tạp trong việc báo cáo và phân tích. Kẻ tấn công có thể tìm nạp /orders/1, /orders/2, và tiếp tục đến /orders/10482 sẽ có được cái nhìn toàn diện về lịch sử và xu hướng đặt hàng của bạn.
Liệt kê và quét - cách các ID tuần tự biến một bản ghi được hiển thị thành tất cả chúng
Mẫu tuần tự cho biết xu hướng về thời điểm đơn hàng đến, sản phẩm nào được đề cập và mẫu giá cả. Người quan sát sẽ biết tốc độ phát triển hoặc thu hẹp doanh nghiệp của bạn. Thông tin đó, chỉ bắt nguồn từ việc liệt kê ID, có thể cung cấp thông tin về chiến lược cạnh tranh, hướng dẫn kỹ nghệ xã hội hoặc thông báo thời gian cho các cuộc tấn công khác. Việc khám phá và xuất hiện trong URL, lịch sử trình duyệt, các trang được lưu trong bộ nhớ đệm và nhật ký máy chủ sẽ không mất phí. Đây không phải là lý thuyết: các công ty tình báo cạnh tranh và các kỹ sư tò mò thường xuyên trích xuất các số liệu kinh doanh từ các ID có thể đếm được công khai. Mẫu số đơn hàng tiết lộ tốc độ sản xuất và tổng khối lượng cho bất kỳ ai có đủ động lực để thu thập dữ liệu và thực hiện phân tích cơ bản.
Bài toán xe tăng Đức trong một đoạn văn - ước tính tổng số từ một mẫu số liên tiếp
Việc liệt kê áp dụng phân tích thống kê để ước tính tổng khối lượng và theo dõi các mô hình thời gian. Nếu đơn hàng đầu tiên xảy ra vào một ngày đã biết và bạn thu được bằng chứng về 10 đơn hàng trải dài trong một tuần thì khoảng thời gian trung bình sẽ ước tính tỷ lệ chung. Các đối thủ cạnh tranh, nhà đầu tư và kẻ tấn công có thể lấy được vận tốc của bạn mà không cần truy cập bất kỳ dữ liệu khách hàng nào ngoài ID. Số nhận dạng tuần tự đảm bảo rằng mọi ID lớn hơn số hiện tại sẽ dự đoán các đơn đặt hàng trong tương lai; mọi ID thấp hơn mức tối thiểu trong mẫu đều xác nhận hoạt động của bạn trước đây nhỏ hơn. Các điểm dữ liệu lịch sử tạo ra dòng thời gian tăng trưởng và cho phép dự báo. Nguyên tắc tương tự này được áp dụng trong các ngành: giao dịch tài chính, đơn đặt hàng vận chuyển, hồ sơ y tế và bất kỳ hệ thống nào hiển thị ID tuần tự.
UUID khắc phục những gì - các tham chiếu không thể đoán được và không có tín hiệu tăng trưởng trong chính ID
UUID được tạo ngẫu nhiên chứa 122 bits entropy khi được tạo từ nguồn bảo mật bằng mật mã vì RFC 9562 chỉ định cho phiên bản 4. Mã nhận dạng không thể đoán được, không thể đếm được và không tiết lộ gì về tốc độ tăng trưởng hoặc khối lượng cho những người quan sát bên ngoài. Kẻ tấn công biết /orders/9a1f4e2b-7c3e-4d1a-8a5f-1b2c3d4e5f60 không thể dự đoán UUID của đơn hàng tiếp theo hoặc xem ngược lại ID lịch sử của bạn với bất kỳ độ tin cậy hợp lý nào. Bản thân UUID trở thành một tham chiếu duy nhất nhưng hoàn toàn không rõ ràng. Phân phối ngẫu nhiên có nghĩa là nhiều truy vấn không tiết lộ mẫu, không tiến trình và không có thông tin vận tốc cho người quan sát bên ngoài đang theo dõi API của bạn.
Những gì UUID không khắc phục được - ID không thể đoán được không được ủy quyền và tính năng ẩn danh vẫn cần kiểm tra quyền truy cập đằng sau nó
Việc thay thế ID tuần tự bằng UUID trong API công khai rất đơn giản về mặt vận hành và không yêu cầu sự phối hợp phức tạp giữa các hệ thống. Thêm cột UUID vào bảng đơn đặt hàng của bạn, tạo một cột cho mỗi đơn đặt hàng mới, hiển thị UUID trong phản hồi và dần dần ngừng sử dụng phím số. Hệ thống nội bộ của bạn có thể tiếp tục sử dụng các khóa chính số nguyên để đạt được hiệu suất và sự đơn giản; chỉ có giao diện công cộng thay đổi. ID tuần tự cũ vẫn còn trong cơ sở dữ liệu để bạn tham khảo hoặc kiểm tra, nhưng khách hàng và bên thứ ba chỉ nhìn thấy UUID. Cách tiếp cận khóa kép này là phương pháp hay nhất để duy trì hiệu suất chỉ mục hiện có trong khi hiển thị các mã định danh không rõ ràng với thế giới bên ngoài.
Ví dụ đã hoạt động - thêm cột UUID công khai cùng với khóa số nguyên bên trong và chỉ hiển thị cột cũ
Cách tiếp cận này khác với ủy quyền thực tế vì UUID không phải là mật khẩu và tính ẩn danh không phải là biện pháp kiểm soát bảo mật. Khách hàng có quyền truy cập hợp pháp vào /orders/{their-uuid} sẽ có thể xem nội dung đó nhưng /orders/{someone-elses-uuid} vẫn phải bị từ chối bởi hoạt động kiểm tra quyền truy cập của bạn. UUID ẩn số đơn đặt hàng khỏi việc kiểm tra thông thường và ngăn phân tích thống kê thông qua bảng liệt kê, nhưng logic xác thực và ủy quyền vẫn thuộc trách nhiệm của mã ứng dụng của bạn. Biện pháp bảo vệ được phân lớp: UUID ngăn chặn rò rỉ thông tin trong chính mã định danh đó và kiểm soát quyền truy cập sẽ thực thi ai có thể hành động theo mã định danh đó.
Điều này không bao gồm những gì - sự đánh đổi hiệu suất chỉ mục của các khóa ngẫu nhiên, được thảo luận trong một bài riêng
Ranh giới hoạt động quan trọng vì UUID khắc phục sự cố rò rỉ thông tin trong chính ID nhưng không thay thế các cơ chế kiểm soát truy cập. Nếu khách hàng có khóa API và có đủ quyền thì họ vẫn có thể đưa ra yêu cầu đối với hệ thống của bạn. Phạm vi những gì họ có thể truy cập được xác định bởi mô hình quyền và định nghĩa vai trò của bạn chứ không phải định dạng ID. Lợi ích của UUID hoàn toàn là việc mã định danh ngừng phát dữ liệu về khối lượng, trình tự và mức tăng trưởng cho bất kỳ ai có thể quan sát nó. Một hệ thống được thiết kế tốt kết hợp độ mờ UUID với kiểm tra kiểm soát truy cập rõ ràng đối với mọi yêu cầu tới API.
Bài học rút ra: tách các tham chiếu công khai khỏi các khóa nội bộ — trình tạo ToolAcre cung cấp các UUID được hỗ trợ bởi CSPRNG cho phía công khai
Quá trình di chuyển thực tế sẽ tránh được ngày treo cờ bằng cách hỗ trợ dần dần cả hai định dạng. Nếu bạn phiên bản điểm cuối của mình, v1 API có thể tiếp tục trả về ID số nguyên trong khi v2 trả về UUID. Khách hàng chuyển đổi theo tốc độ riêng của họ mà không yêu cầu chuyển đổi phối hợp. Các truy vấn cơ sở dữ liệu nội bộ của bạn không thay đổi: chúng vẫn lọc theo id số nguyên vì các chỉ mục của bạn được xây dựng trên cột đó và các khóa ngoại của bạn tham chiếu nó. Chỉ có dữ liệu được trả về cho khách hàng mới thay đổi. Trình tạo ToolAcre UUID tạo ra định dạng phiên bản-4 mà bạn sẽ sử dụng; mỗi đầu ra là RFC 9562 UUID chính xác sẵn sàng cho các tình huống lưu trữ, triển khai và di chuyển dần dần.