Thiết kế và bảo mật API: Tại sao ẩn id nội bộ?

Question

Tôi đã nghe một vài người nói rằng bạn không bao giờ nên để lộ các id nội bộ của bạn với thế giới bên ngoài (ví dụ: một khóa chính auto_increment'ng).

Một số đề xuất có một số loại cột uuid mà bạn sử dụng thay cho tra cứu.

Tôi tự hỏi tại sao điều này sẽ được đề xuất và nếu điều đó thực sự quan trọng.

Sử dụng uuid thay thế về cơ bản chỉ làm xáo trộn id. Vấn đề ở đây là gì? Điều duy nhất tôi có thể nghĩ đến là các số nguyên auto_incrementing rõ ràng chỉ ra thứ tự của các đối tượng db của tôi. Có vấn đề gì nếu một người dùng bên ngoài biết rằng một thứ đã được tạo trước/sau một thứ khác?

Hoặc là hoàn toàn là làm xáo trộn các id sẽ ngăn "đoán" tại các hoạt động khác nhau trên các đối tượng cụ thể?

Đây có phải là vấn đề tôi nên nghĩ đến khi thiết kế API đối mặt bên ngoài không?

Answer 1

Mọi thông tin mà bạn cung cấp cho người dùng độc hại về ứng dụng của bạn và bố cục của ứng dụng có thể và sẽ được sử dụng đối với ứng dụng của bạn. Một trong những vấn đề chúng ta gặp phải trong bảo mật ứng dụng (web) là các quyết định thiết kế dường như vô hại được đưa ra ở giai đoạn trứng nước của dự án trở thành gót chân achilles khi dự án có quy mô lớn hơn. Cho một đoán kẻ tấn công làm cho thông báo về việc đặt hàng của các đơn vị có thể quay lại ám ảnh bạn trong những điều sau đây, cách nào không liên quan:

1. ID của tổ chức chắc chắn sẽ được thông qua như một tham số tại một số điểm trong ứng dụng của bạn . Điều này sẽ dẫn đến tin tặc cuối cùng có thể cung cấp các đối số ứng dụng của bạn mà thông thường họ không có quyền truy cập. Cá nhân tôi đã có thể xem chi tiết đơn đặt hàng (trên trang web của một nhà bán lẻ rất phổ biến) mà tôi không có doanh nghiệp đang xem, như một đối số URL không kém. Tôi chỉ đơn giản là cho ăn các số thứ tự ứng dụng từ thứ tự hợp pháp của riêng tôi.

2. Biết giới hạn hoặc ít nhất là sự tiến triển của giá trị trường khóa chính là giá trị vô giá đối với các cuộc tấn công SQL injection, phạm vi mà tôi không thể đề cập ở đây.

3. Giá trị khóa không chỉ được sử dụng trong các hệ thống RDBMS mà còn được sử dụng cho các hệ thống ánh xạ khóa-giá trị khác. Hãy tưởng tượng nếu thứ tự cookie JSESSION_ID có thể được xác định trước hoặc được đoán? Mọi người có ngón tay cái đối lập sẽ được phát lại các phiên trong ứng dụng web.

Và nhiều hơn nữa tôi chắc chắn rằng ppl khác ở đây sẽ xuất hiện.

Nhóm SEAL 6 không nhất thiết có nghĩa là có 6 nhóm con dấu. Chỉ cần giữ kẻ thù đoán. Và thời gian mà một kẻ tấn công tiềm năng đoán được là nhiều tiền hơn trong túi của bạn theo bất kỳ cách nào bạn cắt nó.

Answer 2

Cũng như nhiều vấn đề liên quan đến bảo mật, đó là câu trả lời tinh tế - kolossus cung cấp một cái nhìn tổng quan tốt.

Điều này giúp hiểu cách kẻ tấn công có thể làm ảnh hưởng đến API của bạn và có bao nhiêu vi phạm bảo mật xảy ra.

Hầu hết các vi phạm bảo mật là do lỗi hoặc sự giám sát và kẻ tấn công tìm kiếm những lỗi đó. Kẻ tấn công đang cố gắng xâm phạm API của bạn trước tiên sẽ cố gắng thu thập thông tin về nó - vì đó là API, có lẽ bạn xuất bản tài liệu sử dụng chi tiết.Kẻ tấn công sẽ sử dụng tài liệu này và thử nhiều cách khác nhau để làm cho trang web của bạn bị lỗi (và do đó hiển thị thêm thông tin, nếu anh ta may mắn) hoặc phản ứng theo cách bạn không lường trước được.

Bạn phải thừa nhận kẻ tấn công có rất nhiều thời gian, và sẽ tấn công họ để thử mọi đại lộ duy nhất - giống như tên trộm với thời gian vô hạn, người đi quanh nhà bạn đang thử mọi cửa sổ và cửa sổ, từ mọi nỗ lực. Vì vậy, nếu API của bạn hiển thị một phương thức như getUserInfo(userid) và userID là số nguyên, kẻ tấn công sẽ viết một tập lệnh để lặp lại từ 0 trở lên để tìm hiểu xem bạn có bao nhiêu người dùng. Họ sẽ thử số âm và max(INT) + 1. Ứng dụng của bạn có thể rò rỉ thông tin trong tất cả các trường hợp đó và - nếu nhà phát triển quên xử lý các lỗi nhất định - có thể hiển thị nhiều dữ liệu hơn bạn dự định.

Nếu API của bạn bao gồm logic để hạn chế quyền truy cập vào dữ liệu nhất định - ví dụ: bạn được phép thực thi getUserInfo cho người dùng trong danh sách bạn bè của mình - kẻ tấn công có thể gặp may với một số con số do lỗi hoặc giám sát và anh ta sẽ biết rằng thông tin mà anh ta đang nhận được liên quan đến người dùng hợp lệ, vì vậy họ có thể xây dựng mô hình cách ứng dụng của bạn được thiết kế. Đó là tương đương với một tên trộm biết rằng tất cả các ổ khóa của bạn đến từ một nhà sản xuất duy nhất, vì vậy họ chỉ cần mang theo lựa chọn khóa đó.

Chính nó, điều này có thể không có lợi cho kẻ tấn công - nhưng nó làm cho cuộc sống của họ trở nên dễ dàng hơn một chút.

Với nỗ lực của việc sử dụng UUID hoặc một số nhận dạng vô nghĩa khác, điều này có thể khiến mọi thứ trở nên khó khăn hơn cho kẻ tấn công. Dĩ nhiên, đây không phải là điều quan trọng nhất - nó có thể không làm cho 5 điều hàng đầu bạn nên làm để bảo vệ API của bạn khỏi những kẻ tấn công - nhưng nó giúp ích.

Answer 3

Câu trả lời hay, tôi sẽ thêm một lý do khác để giải thích lý do bạn không muốn hiển thị ID tăng dần tự động nội bộ của mình.
Là một công ty cạnh tranh, tôi có thể dễ dàng xác định số lượng người dùng/đơn đặt hàng mới/v.v mà bạn nhận được mỗi tuần/ngày/giờ. Tôi chỉ cần tạo người dùng và/hoặc đặt hàng và trừ ID mới từ những gì tôi nhận được lần trước.
Vì vậy, không chỉ vì lý do bảo mật, đó cũng là lý do kinh doanh.