Một số chức năng của Google OAuth gặp sự cố

 (trufflesecurity.com)
1 điểm bởi GN⁺ 2023-12-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • Với các dịch vụ dựa vào email claim của Google OAuth để xác định quyền đăng nhập, nhân viên đã nghỉ việc vẫn có thể tiếp tục truy cập các ứng dụng như Slack và Zoom ngay cả sau khi bị xóa khỏi tổ chức Google của công ty
  • Có thể tạo tài khoản Google bằng email không phải Gmail, và bằng cách dùng bí danh email hoặc chuyển tiếp địa chỉ cộng (+) của email công ty, một tài khoản Google không thuộc tổ chức vẫn có thể gửi email claim mang địa chỉ thuộc domain công ty
  • Tài khoản không phải Gmail này không xuất hiện trong giao diện quản trị hay danh sách người dùng của tổ chức Google công ty, nhưng nhiều dịch vụ chỉ nhìn vào domain ở cuối email để cho phép đăng nhập
  • Tổ chức có thể giảm thiểu bằng cách tắt đăng nhập Google và áp dụng nghiêm ngặt SAML, nhưng một số dịch vụ hoặc ứng dụng nội bộ có thể không cung cấp tùy chọn này hoặc không hỗ trợ SAML
  • Vấn đề đã được báo cho Google vào ngày 4 tháng 8, khoản thưởng $1337 được chi trả vào ngày 5 tháng 10, và được công khai sau 134 ngày vào ngày 16 tháng 12, nhưng đến thời điểm công bố Google vẫn chưa triển khai thay đổi giảm thiểu nào

Công bố lỗ hổng và mốc thời gian

  • Một lỗ hổng trong Google OAuth có thể khiến nhân viên đã bị offboarding và bị xóa khỏi tổ chức Google của công ty vẫn giữ quyền truy cập vô thời hạn vào các ứng dụng như Slack và Zoom
  • Tính đến thời điểm công bố, Google vẫn chưa triển khai thay đổi nào để giảm thiểu rủi ro này
  • Mốc thời gian như sau
    • 4 tháng 8: Báo cho Google và thông tin rằng hàng trăm ứng dụng có thể bị ảnh hưởng
    • 7 tháng 8: Vấn đề được triage
    • 5 tháng 10: Google chi trả $1337 cho vấn đề này
    • 25 tháng 11: Gửi báo cáo riêng tư hàng loạt tới hàng chục ứng dụng bị ảnh hưởng, gồm cả Zoom và Slack
    • 16 tháng 12: Công khai sau 134 ngày kể từ khi thông báo cho Google

Rủi ro khi dùng email claim làm định danh

  • Đăng nhập Forager của Truffle Security trước đây từng bị ảnh hưởng bởi lỗ hổng Microsoft OAuth của Descope
  • Khi đó, người ta xác nhận rằng Microsoft có thể gửi Email claim mà họ không trực tiếp tạo ra hoặc xác minh, và email claim nói chung không phải là định danh đáng tin cậy
  • Tài liệu OIDC của Google cũng cảnh báo không nên dùng Email làm định danh mặc định
  • Claim email_verified cũng được xem là một điểm bất thường, nhưng không xác nhận được cách tạo email claim từ email chưa được xác minh
  • Tuy vậy, việc lạm dụng chính email claim thì đã được xác nhận đầy đủ

Tài khoản Google không phải Gmail và email claim trùng lặp

  • Có thể tạo tài khoản Google bằng một địa chỉ email sẵn có, không nhất thiết phải là địa chỉ Gmail
    • Ví dụ, có thể tạo tài khoản Google bằng địa chỉ email Yahoo
    • Tài khoản này có thể được cấu hình với email không phải Gmail và gửi email claim của chính địa chỉ đó
  • Một trong những lý do Google khuyên không dùng email làm định danh mặc định là vì hai tài khoản Google khác nhau có thể gửi cùng một email claim
    • Sau khi chỉnh sửa email không phải Gmail trong phần cài đặt
    • Có thể tạo tài khoản mới bằng địa chỉ email trước khi chỉnh sửa để tạo ra cùng một email claim

Tài khoản tồn tại ngoài tổ chức Google của công ty

  • Lỗ hổng cốt lõi là có thể dùng bí danh email và chuyển tiếp địa chỉ cộng (+) cho email thuộc tổ chức Google của công ty để tạo tài khoản Google nằm ngoài tổ chức
  • Địa chỉ cộng (+) của email công ty có thể được chuyển tiếp về hộp thư đến của người dùng gốc
  • Theo luồng này, có thể tạo một tài khoản Google không phải Gmail dựa trên địa chỉ cộng (+) dùng email của tổ chức Google công ty, và tài khoản đó không thể bị xóa khỏi tổ chức hay offboarding
  • Nhiều dịch vụ phân tích địa chỉ email này rồi quyết định khả năng đăng nhập dựa trên domain ở cuối địa chỉ
    • Có thể đăng ký Zoom bằng tài khoản này
    • Có thể đăng ký Slack bằng tài khoản này
  • Vì các tài khoản Google không phải Gmail này không phải thành viên thực sự của tổ chức Google, chúng không xuất hiện trong cấu hình quản trị hoặc danh sách người dùng Google

Biện pháp giảm thiểu của tổ chức, nhà cung cấp dịch vụ và Google

  • Tổ chức có thể giảm thiểu bằng cách vô hiệu hóa đăng nhập Google và bắt buộc dùng SAML một cách nghiêm ngặt
    • Cách này hoạt động với phần lớn nhà cung cấp dịch vụ
    • Một số dịch vụ không cung cấp tùy chọn đó
    • Các ứng dụng nội bộ tự phát triển có thể bị ảnh hưởng nhưng không hỗ trợ SAML
  • Nhà cung cấp dịch vụ có thể sử dụng HD claim của Google OAuth
    • HD claim gửi domain của tổ chức Google mà tài khoản được liên kết tới
    • Các tài khoản không phải thành viên của tổ chức Google sẽ không có HD claim
    • Phần lớn nhà cung cấp dịch vụ được thử nghiệm đã dùng email claim thay vì HD
  • HD claim vẫn có những hạn chế quan trọng
    • HD không phải định danh duy nhất mà chỉ là một domain
    • Nếu một tổ chức Google bị xóa và domain bị bỏ mặc, người khác có thể chiếm domain đó để tạo tổ chức Google mới
    • Ví dụ, công ty A bị công ty B mua lại, B đóng dịch vụ của A và không gia hạn domain cũ
    • Nếu một ai đó trên internet mua lại domain của công ty A, họ có thể đăng nhập vào các tài khoản dịch vụ cũ của công ty A
  • Nhà cung cấp dịch vụ có thể không cho phép JIT account creation như một tính năng mặc định, mà chuyển sang cấp phát tài khoản theo kiểu chỉ mời hoặc dựa trên nhóm LDAP
  • Google có thể giảm thiểu trên diện rộng bằng cách cấm tạo tài khoản Google bằng domain của các tổ chức Google hiện có
    • Google hiện đã tự cấm tài khoản google.com
    • Họ có thể mở rộng cùng cơ chế bảo vệ này cho các tổ chức khác
  • Các biện pháp khác phía Google gồm cấm đăng ký tài khoản Google bằng địa chỉ cộng (+), cấm đăng ký bằng bí danh email Google, và cung cấp cài đặt quản trị tốt hơn để tổ chức có thể cấu hình các thiết lập liên quan

Ảnh hưởng bổ sung: email hỗ trợ và luồng magic link

  • Ngay cả khi không có quyền truy cập ban đầu, về mặt kỹ thuật vẫn có thể truy cập Zoom hoặc Slack của tổ chức
  • Luồng này tận dụng nghiên cứu lỗ hổng mà các nhà nghiên cứu khác đã tìm thấy trong magic link sign-in flows
  • Một số hệ thống hỗ trợ và ticket như Zendesk có thể tạo ticket hỗ trợ qua email
    • Có thể tạo tài khoản Google bằng địa chỉ email ticket hỗ trợ
    • Có khả năng hoàn tất tạo tài khoản bằng cách xem nội dung ticket
    • Sau đó có thể thử đăng nhập OAuth bằng chính địa chỉ email hỗ trợ đó
  • Việc giữ tính năng email to support trên domain chính là không an toàn, và một cách làm khác là cấu hình email hỗ trợ của Zendesk làm địa chỉ email thay thế

Mục đích công bố và vấn đề còn lại

  • Vấn đề nhân viên cũ vẫn giữ được quyền truy cập trên các nền tảng như Slack và Zoom bắt nguồn từ lỗ hổng trong hệ thống Google OAuth
  • Google có khả năng thực hiện các thay đổi trên diện rộng để giảm thiểu vấn đề này
  • Mục tiêu của việc công bố là thúc đẩy thay đổi thực tế thay vì chỉ chỉnh sửa tài liệu nhỏ lẻ
  • Google đã triage vấn đề nhanh chóng, nhưng trái với thông lệ cải thiện trong 90 ngày của chính họ, vấn đề này được công khai vào ngày thứ 134

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-22
Các ý kiến trên Hacker News

  • Tôi làm trong lĩnh vực này và trong 3–4 năm qua đã xử lý hơn 20 biến thể của lỗ hổng này ở nhiều nhà cung cấp đăng nhập và công ty SaaS. Bài blog nói đúng, nhưng tôi nghĩ vấn đề cốt lõi đã đi quá xa để có thể sửa. Xác thực ủy quyền trên toàn Internet là một mớ hỗn độn hoàn toàn, và vì tôi đã nói chuyện nhiều với các kỹ sư Google, Microsoft nên tôi chắc chắn họ đã biết nhóm vấn đề này. Chỉ là nếu thay đổi hành vi hiện tại thì sẽ làm hỏng quá nhiều dịch vụ hiện có và các triển khai đăng nhập doanh nghiệp đã tồn tại hàng chục năm
    “Cách sửa” ở thời điểm này rất đơn giản. Nếu trang web dùng “Sign in with XYZ”, đừng tin địa chỉ email mà nhà cung cấp gửi về. Đừng cấp quyền đặc biệt chỉ dựa trên miền email; trước khi đánh dấu là đã xác minh trong cơ sở dữ liệu, hãy luôn gửi email xác minh riêng của chính mình. Các nhà cung cấp OAuth lớn cũng đã cập nhật tài liệu để nêu rõ điều này, và bài viết cũng chỉ ra điểm đó. Vì vậy việc có tiền thưởng thực ra lại khiến tôi ngạc nhiên

    • Có cảm giác đây là kết quả của việc các tổ chức không hiểu đúng mức độ phức tạp thực sự của lĩnh vực này. Nhìn cách OAuth2 + OIDC được đưa vào ở nhiều công ty, nó luôn được bán như một tính năng kiểu “đăng nhập bằng x”, chứ không phải từ góc nhìn ưu tiên bảo mật. Ngay cả khi cố làm luồng an toàn hơn như PKCE, việc mỗi nền tảng xử lý cookie chia sẻ hay redirect một cách lộn xộn lại biến nó thành trò đập chuột chũi. Nền tảng của OAuth2 ba bên là vững chắc và cũng có nhiều tiền lệ như CAS, nhưng OpenID Foundation đáng bị chỉ trích nặng nề vì cách họ tiếp thị và bán OIDC
    • Cách “đừng cấp quyền đặc biệt chỉ dựa trên miền email; trước khi đánh dấu là đã xác minh trong cơ sở dữ liệu, hãy luôn gửi email xác minh riêng” chẳng phải sẽ thất bại nếu người dùng đăng ký tài khoản trên Google bằng địa chỉ có dấu cộng, rồi trước khi bị đuổi đã đăng nhập vào dịch vụ bằng tài khoản Google đó sao? Trừ khi gửi email xác minh ở mỗi lần đăng nhập
    • Trong trường hợp cụ thể này, kẻ tấn công thực sự có thể nhận email xác minh, nên tôi không hiểu quy trình xác minh đó có ý nghĩa gì
    • “Trước khi đánh dấu là đã xác minh trong cơ sở dữ liệu, hãy luôn gửi email xác minh riêng” về phía người dùng sẽ khiến tính năng đăng nhập bằng x trở nên vô dụng
    • Google không thể chặn việc đăng ký bằng miền của khách hàng Google Apps sao? Điều đó có vẻ không làm hỏng thứ gì đặc biệt

  • Liên quan đến chuyện này, nhiều nhà cung cấp dịch vụ hơn nên ngừng dùng email làm định danh chính như khuyến nghị trong tài liệu của Google. Khi đổi tên người dùng trong Google Apps, tôi đã mất rất nhiều thời gian xử lý vấn đề ở Slack, Datadog, GoLinks, v.v.

    • Vậy các nhà cung cấp nên dùng gì? Tôi luôn nghĩ email là định danh toàn cục ổn định nhất cho người dùng, nhưng có vẻ giả định đó sai
    • Khó đồng ý. Những hướng dẫn kiểu này chỉ đẩy trách nhiệm sang nhà phát triển ứng dụng, và phần lớn có khả năng sẽ không làm gì hoặc mỗi bên triển khai một kiểu
      Hướng đúng ở đây là cung cấp API phù hợp với nhu cầu của ứng dụng sẽ sử dụng và giảm thiểu trách nhiệm bổ sung. Trong trường hợp này, tôi nghĩ Google lẽ ra nên đặt email_verified thành false để ứng dụng hoặc IdP cấp dưới biết rằng cần xác minh bổ sung

  • Nếu user@domain đã được xử lý bởi máy chủ thư của Google và vì thế các quy tắc định tuyến dấu cộng được áp dụng, tôi không hiểu vì sao lại có thể tạo tài khoản Google mới bằng email như user+suffix@domain. Ngay cả khi không bị lạm dụng, nó có vẻ rất dễ tạo ra cấu hình email gây nhầm lẫn

    • Miền có thể tự do chuyển máy chủ thư. Google xử lý a+b@domain.com theo một cách cụ thể, nhưng máy chủ khác có thể không như vậy. Rốt cuộc đây là hai địa chỉ email duy nhất khác nhau và trên toàn Internet cũng nên được đối xử như vậy
    • Tính năng bí danh này có vẻ đã trở nên quá phức tạp so với giá trị của nó. Đặc biệt ở quy mô của Google thì càng như vậy
    • Còn tệ hơn user+suffix@domain. Ít nhất +XYZ còn được nêu trong RFC về email. Google còn đi xa hơn khi quyết định rằng dấu chấm trong tên cũng được xem là email chính quy. Ví dụ hi.my.name@google.com giống với himyname@google.com, và mọi thư đều được định tuyến tới địa chỉ sau
    • Vì hệ thống xác thực của Google là legacy rất cũ. “Tài khoản Google” chỉ là một chuỗi

  • Về đoạn “Tôi ngạc nhiên khi biết Microsoft gửi các claim email mà Microsoft không tạo ra hay xác minh, và nói chung claim email không được coi là đáng tin cậy”, dù ý định ban đầu có thể là vậy, tôi thấy việc OIDC có thể linh hoạt hơn là rất hữu ích. Ví dụ, tôi vận hành một nhà cung cấp đăng nhập miễn phí[0]; dịch vụ này xác minh danh tính thông qua OIDC cấp trên hoặc email trực tiếp với nhà cung cấp danh tính (IdP) là bên thứ tư, và tạo một bức tường chắn quyền riêng tư giữa ứng dụng và IdP đó. Nói cách khác, nó ngăn Google theo dõi mọi ứng dụng mà người dùng đăng nhập
    Việc có thể mang email của mình vào Google nghĩa là bạn có được bảo mật và trải nghiệm người dùng của Google OIDC cùng với quyền riêng tư của email+mật khẩu, nhưng có một điều kiện lớn là giờ bạn phải tin LastLogin thay vì Google. Chúng tôi cũng đang làm một giao thức để giảm sự phụ thuộc đó. Tôi hoàn toàn phản đối đoạn “Tài liệu của Google thực ra đã cảnh báo không dùng email làm định danh”. Email là danh tính liên kết thực sự duy nhất mà mọi người thật sự dùng. Cho đến khi có một lựa chọn tốt hơn được triển khai rộng rãi, tôi tin rằng địa chỉ email phải được xem như danh tính
    [0]: https://lastlogin.io

    • Tôi phản đối quan điểm “địa chỉ email phải được xem như danh tính”. Có hai lý do
      Bên ngoài phương Tây, điện thoại di động phổ biến hơn máy tính và UI thường cũng dễ dùng hơn, nên số điện thoại nhiều khả năng mới là danh tính. Ngoài ra, làm vậy đồng nghĩa với việc giao hoàn toàn danh tính cho nhà cung cấp email. Những tổ chức vô danh như Google có thể chặn truy cập mà không báo trước hay có quy trình khiếu nại, và thực tế họ làm vậy, nên bạn có thể mất tất cả. Nói thêm bối cảnh: tôi đã ra mắt các sản phẩm OAuth và OIDC của Okta, tạo khóa học liên quan trên LinkedIn, và hiện đang làm lại việc đó ở Pangea Cyber
    • “Địa chỉ email phải được xem như danh tính” ư, giả định là không ai chia sẻ địa chỉ email và email rất an toàn sao
      Bạn có thể chờ mãi, hoặc có thể bắt đầu xây dựng giải pháp
    • Có một khác biệt quan trọng giữa định danh email trong hệ thống của chính bạn và email với tư cách là định danh của tài khoản Google được liên kết. Tôi đồng ý rằng trong một hệ thống bạn kiểm soát, email hoạt động tạm ổn như danh tính, nhưng khi liên kết với hệ thống bên ngoài thì, như Google nói, đó là một cách rất tệ. Nó mang tính tạm thời, có thể gắn với nhiều tài khoản, và khi đã có một ID thực sự có thể dùng thì không có lý do gì phải dùng email
    • Sẽ rất tuyệt nếu có so sánh LastLogin với Dex. Cả hai đều viết bằng Go nên tôi đặc biệt tò mò. Tôi cũng muốn biết liệu bạn đã đánh giá Dex chưa
      Tôi từng thử qua Portier và Mozilla Persona ngày trước, nhưng cuối cùng việc xử lý vấn đề chuẩn hóa email trông như một cuộc chiến thua sẵn hoặc quá khó. Tôi gần như chấp nhận rằng mình sẽ chết trước khi có một giải pháp tốt được mở đường, rồi chuyển sự quan tâm sang chỗ khác

  • Đây thật sự là vấn đề của Google OAuth, hay là thất bại của nhiều nhà cung cấp dịch vụ trong việc xác minh đúng các assertion trong token OAuth trước khi cho phép truy cập? Trông giống vế sau hơn

    • Nghe như vấn đề là các nhà cung cấp dịch vụ này tuân theo quy tắc alias của Google, nhưng lại bỏ qua việc không nên dùng email làm định danh chính [1]. Điều thú vị là nếu họ tuân thủ đặc tả tốt hơn thì đã ổn, và ngược lại nếu họ tuân thủ đặc tả kém hơn, xem alias là các email khác nhau, thì ít nhất cũng đã an toàn hơn
      [1] https://developers.google.com/identity/openid-connect/openid...
    • Tôi cho rằng OAuth đang hoạt động đúng như kỳ vọng. user@domain và user+wildcard@domain vẫn được xác minh là địa chỉ email mà người dùng “sở hữu”, nên chúng cung cấp xác thực và danh tính hợp lệ cho địa chỉ email đó
      Vấn đề nằm ở phía website tổ chức Google. Quản trị viên không thể thu hồi chứng thực của các tài khoản hoặc email mà họ không nhìn thấy. Đoạn mấu chốt là “những tài khoản Google không phải Gmail này thực ra không phải là thành viên của tổ chức Google, nên chúng không xuất hiện trong cài đặt quản trị hay danh sách người dùng Google”

  • Theo luồng này, có thể tạo tài khoản Google bằng địa chỉ email ticket hỗ trợ, có khả năng xem nội dung ticket để hoàn tất việc tạo tài khoản, rồi dùng địa chỉ email hỗ trợ đó để đăng nhập OAuth vào nhiều dịch vụ. Điều này có thể ảnh hưởng đến nhiều công ty nhỏ

  • Kết luận lớn nhất ở đây là xác thực web vẫn là một mớ hỗn độn kinh khủng

    • Vì mọi người không đọc tài liệu, mà chỉ giả định nó hoạt động theo cách họ nghĩ
    • Nếu hỏi tại sao những người tỉnh táo và thực tế vẫn dùng và yêu cầu xác thực bằng mật khẩu đơn giản, thì đó là vì mật khẩu hoạt động đúng

  • Đặc tả OIDC nói rằng không được dùng email làm định danh duy nhất. Với tên người dùng của ứng dụng, nên dùng các trường iss và sub
    Lý do trước hết là rõ ràng địa chỉ email của người dùng có thể được tái sử dụng. Nếu một nhà thầu làm việc cho cả Business A và Business B, và cả hai đều tạo tài khoản người dùng cho người đó trong dịch vụ xác thực, thì từ phía nền tảng SaaS, không thể ánh xạ một địa chỉ email vào một khách hàng B2B duy nhất. Thứ hai, địa chỉ email thay đổi. Doanh nghiệp bị mua lại, đổi tên, sáp nhập; tên người cũng thay đổi vì kết hôn, ly hôn hoặc lựa chọn cá nhân. Việc triển khai SSO ở startup ban đầu thật sự rất khó. Làm cho đúng rất khó, và trước khi dùng cần hiểu rõ các khái niệm chung cũng như OIDC, OAuth2. Auth0 có một cuốn sách hay. Nếu không hiểu điều này, bạn rất có thể sẽ triển khai xác thực password grant khắp nơi rồi khiến ứng dụng trở nên không an toàn

    • Đôi khi đọc những bài như thế này giúp giảm bớt chút hội chứng kẻ mạo danh tích tụ. Nó khiến tôi nghĩ rằng “nếu tích hợp với hệ thống bên thứ ba cho một thứ đại diện cho một tác nhân trừu tượng, thì phải có một định danh đáng tin cậy, ổn định và không mang tính chuỗi thuần túy chứ”. Thực ra đặc tả cũng rất rõ ràng ở điểm này, và đó là mức vượt xa những cân nhắc cơ bản khi xây dựng một hệ thống dù chỉ cần tương đối vững chắc

  • Giống như một thumbnail nhỏ. Thứ gọi là OAuth2 thực ra không tồn tại. OAuth2 chỉ là một cách để các tập đoàn lớn triển khai các hệ thống xác thực tùy ý, độc quyền của riêng họ. Nó không phải là một hệ thống xác thực, mà là một hộp công cụ để tạo ra hệ thống xác thực. Vì vậy OAuth2 từng được dự định trở thành một tiêu chuẩn, nhưng trên thực tế chúng ta lại có một thế giới nơi mỗi tập đoàn lớn có các triển khai không tương thích với nhau. Tất nhiên mọi người sẽ phát triển theo các use case của các tập đoàn lớn, và khi đó “tiêu chuẩn” rốt cuộc sẽ trở thành thứ giống như cách Google làm
    Và mỗi bên đều có những lỗi nhỏ như thế này. Nên quay lại OAuth1. Đó mới là một tiêu chuẩn thật sự, không phải một hộp công cụ để tạo ra tiêu chuẩn

    • Đây giống một tác dụng phụ không may do sự kết hợp của các thành phần cụ thể hơn là một bug. Đó là kết quả của việc tên miền có thể đổi chủ sở hữu, khả năng mang email của mình đi, email dự phòng và nguồn gốc email, việc cho phép rộng rãi alias dấu cộng, cùng với những người triển khai dịch vụ không đọc tài liệu. Có lẽ họ đã sao chép giải pháp từ một video hoặc một ví dụ bị lược bớt vì muốn ngắn gọn
      Nếu bạn thiết kế một mạch bằng vài linh kiện PCB và cần thêm điện trở, transistor cho phù hợp yêu cầu điện áp/dòng điện, chẳng phải ta nên kỳ vọng bạn sẽ đọc datasheet sao? Nếu chỉ đoán mò từ một ví dụ đơn giản rồi làm tới, trong nhiều trường hợp mạch có thể vẫn hoạt động, và với chút bench test cùng probing thì có thể chạy được. Nhưng nó có thể kém hiệu quả, hoặc linh kiện bị chập khiến thời gian hỏng trung bình giảm xuống và khách hàng không hài lòng. Trường hợp xấu nhất, pin có thể bắt lửa và gây thiệt hại thực tế. Vậy việc thiết bị hỏng sớm là lỗi của nhà sản xuất module PCB, hay trách nhiệm thuộc về nhà sản xuất thiết bị lẽ ra phải đọc datasheet? Tôi không đặt kỳ vọng nghiêm ngặt như vậy cho toàn bộ phần mềm, nhưng nếu xử lý xác thực và phân quyền thì tôi nghĩ chủ sở hữu dịch vụ phải thật kỹ lưỡng. Bài gốc cũng nói rằng nếu làm theo tài liệu thì vấn đề không tồn tại. Alphabet đã trả bug bounty nên đã thừa nhận điểm yếu; vì vậy họ cũng có thể cung cấp cho quản trị viên công ty một cơ chế kiểm soát để quản lý danh sách cho phép/từ chối alias dấu cộng hoặc các vai trò không tồn tại, hoặc hạn chế việc email liên quan đến Apps được chuyển thành claim bên ngoài tổ chức. Có lẽ họ đang đo lường mức độ ảnh hưởng này, hoặc đang ưu tiên việc đo lường, nhưng vì đây là vấn đề phía client khi giả định rằng claim email có tính thẩm quyền và lâu dài hơn thực tế, nên tôi nghĩ mức ưu tiên sẽ thấp. Định nghĩa “bug” phụ thuộc nhiều vào việc định nghĩa “hành vi mong đợi” như thế nào và ai là người mong đợi, nhưng ít nhất tôi cho rằng nó không lệch khỏi hành vi được dự định, và cũng không bất ngờ với những người hiểu đúng tài liệu
    • Ừm... cứ cho là vậy đi. Khả năng tương thích giữa các provider có liên quan gì đến bài viết này về bảo mật Google OAuth2 không?

  • Tôi đang bỏ sót điều gì à? Ngoài hệ thống hỗ trợ/Zendesk và cách dùng các tên miền cũ bị bỏ mặc được nhắc trong bài, khi tạo tài khoản Google mới bằng whatever@mydomain.com thì sẽ bị yêu cầu xác minh. Vậy khả năng bị khai thác thực tế là đến mức nào?

    • Điểm mấu chốt là làm sẵn khi còn có quyền truy cập hợp pháp, rồi sau đó mất quyền truy cập đó
      Ví dụ giả sử bạn có hợp pháp tài khoản Google egamirorrim@mydomain.com. Bạn có thể tạo một tài khoản Google mới với địa chỉ email đã được xác minh kiểu alias như egamirorrim+woopsie@mydomain.com, và khi “Đăng nhập bằng Google”, Google sẽ gửi claim email là egamirorrim+woopsie@mydomain.com. Sau đó, nếu bạn bị sa thải khỏi mydomain.com, tài khoản gắn với egamirorrim@mydomain.com thật sẽ không còn đăng nhập được vì quản trị viên đã vô hiệu hóa nó. Nhưng tài khoản Google mới egamirorrim+woopsie@mydomain.com không gắn với tổ chức nên vẫn có thể tiếp tục đăng nhập. Tuy nhiên theo tôi, chuyện này chỉ thành vấn đề khi provider thực hiện phân quyền chỉ dựa trên claim email. Trước đây tôi từng dùng OIDC, và bạn không nên phân tích văn bản của claim địa chỉ email để cấp quyền truy cập tài nguyên. Tôi hiểu vì sao tác giả thấy chuyện này phản trực giác, nhưng trong bài cũng viết rằng tài liệu cảnh báo không nên làm vậy. Bài gốc nói “phần lớn nhà cung cấp dịch vụ mà tôi thử nghiệm không dùng HD mà dùng claim email”; được thôi, nhưng “dùng” nó để làm gì? Mánh này có hoạt động trên các dịch vụ thực tế ngoài đời không? Nếu có, nên nêu tên để họ bị phê bình. Ngay cả khi họ giả định sai rằng giá trị này là duy nhất và bất biến, chỉ riêng điều đó không nhất thiết tạo ra bất kỳ quyền truy cập nào