Lỗ hổng kiểm soát truy cập - OAuth2.0

Vấn đáp

#

1. OAuth là gì, và nó hỗ trợ quá trình ủy quyền trong các ứng dụng web hiện đại như thế nào?

• OAuth là khung xác thực được sử dụng phổ biến, cho phép các trang web và ứng dụng yêu cầu quyền truy cập hạn chế vào tài khoản người dùng trên ứng dụng khác.
• Nó cho phép ứng dụng bên thứ ba truy cập vào dữ liệu vào dữ liệu của người dùng trên nền tảng khác thông qua việc cấp Acess Token mà không cần người dùng phải nhập username, password của họ cho úng dụng đó.
  1. Ứng dụng client yêu cầu truy cập vào một tập dữ liệu con của người dùng, chỉ định quyền hạn và quyền truy cập muốn được cấp phép.
  2. Người dùng được yêu cầu đăng nhập vào dịch vụ OAuth và đồng ý các quyền truy cập được yêu cầu.
  3. Ứng dụng client được cấp một token duy nhất chứng minh rằng ứng dụng đã được người dùng cho phép truy cập dữ liệu được yêu cầu.
  4. Ứng dụng client sử dụng chuỗi token này để gọi API lấy dữ liệu liên quan trong máy chủ tài nguyên.

2. Mô tả cách thức tấn công consent phishing có thể được thực hiện trong môi trường OAuth. Kẻ tấn công có thể lợi dụng các quyền hạn của OAuth để truy cập trái phép vào dữ liệu người dùng như thế nào? Thảo luận về các chiến lược có thể được triển khai để phát hiện và ngăn chặn tình trạng lừa đảo cấp quyền trong các hệ thống sử dụng OAuth.

• Cách thực hiện: Kẻ tấn công tạo ra một ứng dụng web mạo danh các phần mềm hợp pháp và lừa nạn nhân bấm vào link liên kết. Một màn hình bật lên yêu cầu nạn nhân “Cấp quyền” (Consent) cho ứng dụng. Nếu nạn nhân bấm “Đồng ý”, ứng dụng độc hại sẽ nhận được Access Token hợp lệ.
• Lợi dụng token: Kẻ tấn công có thể trực tiếp lấy cắp dữ liệu (đọc email, tải file, thay đổi thông tin) mà không cần biết mật khẩu của nạn nhân, đồng thời vượt qua luôn cả lớp Xác thực đa yếu tố (MFA).
• Chiến lược ngăn chặn:
  • Nhà cung cấp dịch vụ OAuth:
    • Kiểm soát chặt chẽ danh sách redirect_uris: Bắt buộc các ứng dụng client phải đăng ký whitelist chứa các URI chuyển hướng hợp lệ. Áp dụng phương thức so sánh đối chiếu chính xác từng byte một thay vì chỉ khớp theo pattern. Điều này giúp ngăn chặn kẻ tấn công lợi dụng lỗ hổng để truy cập vào các trang không được phép trên cùng một tên miền đã được đưa vào whitelist.
    • Bắt buộc sử dụng tham số state: Giá trị của state phải được liên kết chặt chẽ với session của người dùng bằng cách chứa các dữ liệu ngẫu nhiên, không thể đoán trước được. Kỹ thuật này vừa chống lại các cuộc tấn công CSRF, vừa vô hiệu hóa việc sử dụng các mã ủy quyền bị đánh cắp.
    • Xác thực định danh tại Resource Server: Khi nhận yêu cầu, máy chủ tài nguyên phải kiểm tra xem Access Token có thực sự được cấp cho đúng client_id đang gọi yêu cầu hay không. Đồng thời, phải đối chiếu phạm vi quyền đang được yêu cầu với phạm vi quyền đã được phê duyệt ban đầu của Token đó.
  • Ứng dụng máy khách OAuth:
    • Nắm vững giao thức trước khi code: Phần lớn lỗ hổng sinh ra do lập trình viên không thực sự hiểu rõ điều gì xảy ra ở từng bước của luồng OAuth. Phải đảm bảo hiểu tường tận cơ chế hoạt động, các rủi ro tiềm ẩn trước khi bắt tay triển khai.
    • Chủ động sử dụng tham số state: Ngay cả khi nhà cung cấp dịch vụ không bắt buộc, ứng dụng của bạn vẫn phải luôn tạo và kiểm chứng tham số state.
    • Đồng bộ redirect_uri trên các Endpoints: Đảm bảo tham số redirect_uri gửi đi không những đến endpoint /authorization mà còn phải gửi cả đến endpoint /token.
    • Áp dụng cơ chế PKCE cho Mobile/Native App: Với các ứng dụng di động hoặc ứng dụng trên máy tính cá nhân, bắt buộc triển khai cơ chế PKCE (RFC 7636). Lớp bảo vệ bổ sung này sẽ ngăn chặn triệt để việc đánh cắp hoặc nghe lén mã truy cập.
    • Xác thực chạt chẽ id_token: Nếu ứng dụng của bạn có sử dụng id_token của OpenID Connect, hãy đảm bảo token đó được xác thực nghiêm ngặt theo đúng tiêu chuẩn của JSON Web Signature (JWS), JSON Web Encryption (JWE) và OpenID.
    • Tránh rò rỉ mã ủy quyền:
      • Ngăn chặn việc rò rỉ mã thông qua các header Referer khi trang web tải các tài nguyên bên ngoài như hình ảnh, tệp CSS hoặc Script.
      • Tuyệt đối không nhúng mã ủy quyền vào bên trong các tệp JavaScript được tạo động, vì kẻ tấn công có thể lợi dụng thẻ <script> để gọi và thực thi chúng từ một tên miền bên ngoài.

Vượt qua xác thực thông qua luồng OAuth ngầm định

#

1. Để giải bài lab này, chúng ta cần phải đăng nhập được vào tài khoản của Carlos. Các thông tin được cung cấp:

• Email của Carlos: carlos@carlos-montoya.net.
• Tài khoản được cung cấp: wiener:peter.

Sau đó, chúng ta hãy truy cập vào trang chủ bài lab.

2. Thử truy cập trang ‘My account` và quan sất hành vi của trang web.

3. Quan sát các gói request, chúng ta có thể dễ dàng nhận thấy rằng: “Ở trang web này, khi click vào chúc năng “My account”, trang web sẽ chuyển hướng chúng ta đến đường dẫn /social-login. Sau khi truy cập vào trang social-login, trang web sẽ tự động điều hướng chúng ta đến trang xác thực oauth

1

<meta http-equiv=refresh content='3;url=https://oauth-0a7900370454795b805b015a02cc004b.oauth-server.net/auth?client_id=yoa4ft02xf6bn2hxgkvij&redirect_uri=https://0a1500fe04f0792880f8030a000c007a.web-security-academy.net/oauth-callback&response_type=token&nonce=-2038040152&scope=openid%20profile%20email'>

Nhìn vào đây, chúng ta biết được sau khi trang web xác thực OAuth thành công, nó sẽ được chuyển hướng lại trang web gốc của chúng ta: redirect_uri=https://0a1500fe04f0792880f8030a000c007a.web-security-academy.net/oauth-callback. Chúng ta sẽ thử nhập tiếp tài khoản đăng nhập và quan sát hành vi của trang web.

4. Nhìn vào luồng xác thực, token trả về từ phía nhà cung cấp dịch vụ OAuth chỉ có nhiệm vụ xác minh quyền hạn mà ứng dụng client được phép truy cập. Còn xác thực danh tính người dùng đăng nhập thì dựa vào thông tin email và username. Vậy chúng ta có thể thay dổi thông tin email, ussername thành thông tin của Carlos và mượn token oauth của wiener để đăng nhập (token không có ràng buộc với danh tính người dùng trên ứng dụng client).