Tôi có nên xác minh HTTP Referer trong OAuth 2 Callback không?

Question

Tôi thành công có thể xác thực tài khoản Facebook và Google bằng cách sử dụng các servlet Oauth2 của tôi. Tôi đang sử dụng nhà nước với một bộ đếm thời gian và một cookie phiên để cố gắng xác minh rằng nó thực sự là một cuộc gọi lại Oauth hợp pháp.

1. Có lợi ích gì nếu tôi cũng kiểm tra tiêu đề HTTP Referer để đảm bảo rằng tôi đã được chuyển hướng từ trang OAuth của nhà cung cấp không?

2. Nếu không có lợi ích, có thể có vấn đề nếu tôi cũng kiểm tra trường Giới thiệu HTTP không?

Answer 1

Câu trả lời là:

No, you shouldn't use it, and there is NO valuable benefit of doing it. 

Servers Authorization rất ý thức điều này cũng có. Và here đã được nêu.

Từ mailing list of OAuth-WG:

Callback trang URL NÊN chuyển hướng đến một trang đáng tin cậy ngay lập tức sau khi nhận được mã uỷ quyền trong URL. Điều này ngăn chặn mã ủy quyền còn lại trong lịch sử trình duyệt hoặc từ vô tình bị rò rỉ trong tiêu đề người giới thiệu.

• Nếu bạn đang lo lắng về CSRF, bạn KHÔNG NÊN sử dụng HTTP Referer là một kỹ thuật để xác minh nguồn gốc của một ủy quyền, đó là lý do tại sao các tham số bang là (mà âm thanh bạn sử dụng).

• Nếu bạn lo lắng về mối quan tâm bảo mật cụ thể của giao thức oauth2, có full section inside the draft.

• Nếu bạn lo lắng về các cân nhắc bảo mật khác, this is the source.

Tôi khuyên bạn nên nỗ lực thực hiện tất cả các xác thực xung quanh thông số: trạng thái.

Edit:

Sau khi đọc các sắc thái của câu hỏi, you are really answered câu hỏi của riêng bạn. Việc sử dụng cookie (có thể là bộ nhớ cục bộ HTML5) cho cả hai trường hợp, là giải pháp tốt nhất mà chúng tôi biết cho đến nay.

• Các sắc thái đầu tiên là về CSRF và một trong những biện pháp đối phó có thể có sẵn là Checking the HTTP Referer header, và điều này là đã addressed in the protocol.

• Sắc thái thứ hai, tôi không hoàn toàn chắc chắn, nhưng có lẽ là trường hợp của Extension Grant, điều này là do bạn có thể làm việc như một "người yêu cầu proxy ủy quyền", giống như SAML oauth2 extension.

Answer 2

Không xác minh người giới thiệu HTTP; tham số "trạng thái" (mà bạn đang sử dụng) là approach OAuth 2.0 defines để bảo vệ chống lại các cuộc tấn công giả mạo yêu cầu chéo trang (CSRF).

Bạn có thể muốn xem cuốn sách O'Reilly mới Getting Started with OAuth 2.0 của Ryan Boyd. Nó mô tả các cân nhắc về an ninh và liên quan này.

Answer 3

số

1. tôi có thể mô phỏng bất kỳ tiêu đề tôi muốn là một âm mưu tấn công. Tôi có thể làm cho nó trông giống như tôi đang đến từ http://cia.fbi.gov.vpn/uber1337h4x. Điều này là rõ ràng và nổi tiếng.

2. Bất kỳ trang đến từ HTTPS không gửi một tham khảo tiêu đề theo RFC2616 sec15:

   Khách hàng KHÔNG NÊN bao gồm một header field Referer trong một yêu cầu HTTP (không an toàn) nếu trang đề cập đã được chuyển giao với một giao thức an toàn.

3. Breaks khả năng sử dụng theo RFC2616 sec15:

   Bởi vì nguồn gốc của một liên kết có thể là thông tin cá nhân hoặc có thể tiết lộ một nguồn thông tin khác tin, nó được khuyên rằng người dùng có thể chọn liệu hoặc không phải là trường Referer được gửi đi.

Nói tóm lại, bạn đang không được bảo mật cao hơn. Bảo mật của bạn không phải là kiểm tra giao thức truyền tải không an toàn, nó nằm trong lớp OAuth. Bạn cũng phá vỡ khả năng sử dụng.

Đừng làm điều đó.

Answer 4

an ninh Plain không phải là một mối quan tâm của câu hỏi vì tham số state đang được sử dụng.

Các mối quan tâm chính của tôi đã có trong tâm trí là:

1. Cho dù đó là cùng một trình duyệt mà ứng dụng của tôi gửi lên Facebook đó là quay trở lại để trình bày một mã thông báo ứng cử viên?
2. Cho dù tác nhân (đại lý giống như trình duyệt) hay đại lý liên tục thực hiện yêu cầu OAuth và hiển thị cho tôi mã thông báo OAuth xấu khiến ứng dụng của tôi liên tục liên lạc với Facebook bằng mã thông báo xấu dẫn đến việc xử lý bất lợi tiềm tàng của Facebook.

Giải pháp duy nhất có thể cho vấn đề đầu tiên cũng là đặt cookie ngoài việc sử dụng state. referer sẽ giúp ích nếu hầu hết các nhà cung cấp không sử dụng https.

Vấn đề thứ hai có một sắc thái. Các tác nhân hoạt động sai không cần được kiểm soát trực tiếp bởi một thực thể độc hại. Chúng có thể là trình duyệt người dùng bình thường được chuyển hướng thông qua một số phương tiện gián tiếp (một trang web bị tấn công phổ biến, kỹ thuật xã hội).

Do sắc thái có khả năng tiêu đề referer không được giả mạo. Tuy nhiên, https loại trừ mọi lợi ích có ý nghĩa.

Cookie chắc chắn sẽ trợ giúp trong trường hợp thứ hai cũng vì nếu bạn đang đặt cookie trong POST không có trang web của bên thứ ba có thể khiến chúng được đặt và bạn không thể bị tràn ngập phản hồi OAuth xấu do các trang web bị tấn công chuyển hướng người dùng OAuth bạn.

Đây không phải là câu trả lời rõ ràng (hoặc câu hỏi) nhưng hy vọng điều này cho thấy các sắc thái đằng sau câu hỏi.