Tại sao chúng tôi cần bảo mật dịch vụ REST nếu chúng tôi có HTTPS

Tôi đề cập đến bài viết tuyệt vời này http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ nói về amazon như bảo mật cho dịch vụ web. Tuy nhiên tôi đã được hỏi một câu hỏi trong nhóm tại sao chúng ta cần nó nếu chúng ta đã sử dụng HTTPS. Tôi không thể trả lời vì dường như thực sự với tôi họ có thể đúng mặc dù ruột nói với tôi khác.

Ngoài ra có nơi nào khi cung cấp dịch vụ REST mà HTTPS có thể không hoạt động không? Giống như các trang web của bên thứ 3?

Nếu bất cứ ai có kinh nghiệm trong việc bảo mật Dịch vụ Web qua các mạng công cộng, vui lòng làm sáng tỏ kinh nghiệm của bạn.

Cảm ơn trước.

EDIT: Để làm rõ tôi không nói về xác thực người dùng mà nhiều hơn về xác thực ứng dụng khách. Xác thực người dùng có thể được coi là văn bản thuần túy qua HTTPS + REST.

Điều tôi lo lắng là điều này vẫn cho phép mọi người sử dụng dịch vụ web mà không cần khách hàng của tôi truy cập vì mọi thứ đều là văn bản mặc dù trên HTTPS, điểm cuối của máy khách vẫn có thể sử dụng dịch vụ web của tôi mà không cần ứng dụng khách.

Tại sao chúng tôi cần cung cấp cho Gmail - hoặc bất kỳ trang web nào khác có tài khoản người dùng - tên người dùng và mật khẩu của chúng tôi nếu nó đã sử dụng HTTPS? Câu trả lời giống như câu trả lời cho câu hỏi của bạn.

HTTPS cung cấp, đầu tiên và quan trọng nhất, một kết nối được mã hóa giữa máy chủ và máy khách.

Sự tin cậy vốn có trong HTTPS dựa trên các cơ quan cấp chứng chỉ chính được cài đặt sẵn trong phần mềm trình duyệt (điều này tương đương với câu nói "Tôi tin tưởng cơ quan cấp chứng chỉ (ví dụ VeriSign / Microsoft / v.v.) để cho tôi biết tôi nên tin ai").

Trừ khi máy chủ cấp cho mỗi người dùng một chứng chỉ , máy chủ không thể tin tưởng khách hàng mà không có một số phương thức xác thực khác.

HTTPS rất giỏi trong việc ngăn chặn các cuộc tấn công nghe lén và tấn công "người ở giữa". Vì nó mã hóa tất cả lưu lượng truy cập cho một phiên.

Nhưng vì hầu hết mọi người đang sử dụng các chứng chỉ mặc định đi kèm với trình duyệt của họ và không biết làm thế nào để tạo chứng chỉ cá nhân của riêng họ hoặc định cấu hình trình duyệt để sử dụng nó.

Điều này làm cho HTTPS trở nên vô dụng đối với xác thực người dùng ngoài việc bảo vệ hộp thoại xác thực khỏi nghe lén, v.v.

HTTPS là về việc bảo mật kênh, không chứng minh người gọi là ai, hoặc nhiều điều khác bạn cần xem xét. Xác thực, ủy quyền và mã hóa lớp vận chuyển chỉ là một phần nhỏ trong những gì bạn cần xem xét. Nhiều lỗ hổng đã biết liên quan đến các ứng dụng web áp dụng rất nhiều cho apis REST. Bạn phải xem xét xác nhận đầu vào, bẻ khóa phiên, thông báo lỗi không phù hợp, lỗ hổng nhân viên nội bộ, v.v. Đây là một chủ đề lớn.

Robert

Bạn có thể sử dụng cách tiếp cận chứng chỉ SSL của máy khách và tách bảo mật khỏi api. Nhược điểm lớn của phương pháp này là chi phí hoạt động sẽ tốn kém khi ngày càng nhiều khách hàng tiêu thụ api của bạn.

Ở bất kỳ giá nào, xác thực cơ bản HTTP chỉ tốt cho phần lớn các dịch vụ được tiêu thụ công khai.