Quartz 🪬

Port Swigger - OAuth Authentication

4 min read

What is It?

OAuth cho phép ứng dụng bên thứ ba truy cập dữ liệu user (ví dụ danh bạ) và đăng nhập bên thứ ba.

How it Works?

OAuth liên quan đến ba bên chính:

  1. Client application - Ứng dụng hoặc website yêu cầu truy cập dữ liệu user.
  2. Resource owner - User sở hữu dữ liệu được truy cập.
  3. OAuth service provider - Nền tảng giữ dữ liệu user và quản lý truy cập qua API.

Scopes

Ứng dụng khai báo dữ liệu và thao tác qua scope.

Trong OAuth cơ bản, scope tuỳ provider. Ví dụ yêu cầu đọc danh bạ có thể là:

scope=contacts
scope=contacts.read
scope=contact-list-r
scope=https://oauth-authorization-server.com/auth/scopes/user/contacts.readonly

Khi OAuth được dùng cho authentication, scope OpenID Connect (chuẩn hoá) thường được sử dụng.

Flows

  1. Client app yêu cầu truy cập; 2) user đăng nhập và cấp consent; 3) client nhận token; 4) dùng token gọi API.

Grant Types

Nhiều grant type định nghĩa trình tự và cách client giao tiếp với service (cách gửi token), nên còn gọi là “OAuth flow”.

Chúng ta tập trung vào grant type “authorization code” và “implicit”.

Authorization Code Grant Type

  1. Client application và OAuth service bắt đầu bằng cách redirect user để cấp permission cho access.
  2. Nếu user đồng ý, client app nhận “authorization code”.
  3. Client app trao đổi code này cho “access token” từ OAuth service, cho phép nó access dữ liệu của user.

Từ điểm này trở đi, giao tiếp xảy ra an toàn giữa client app và OAuth server, ẩn khỏi user. Kênh an toàn được set up khi client app đăng ký đầu tiên với OAuth service, nơi nó cũng nhận client_secret để verify chính nó trong các request server-to-server này.

Info

Authorization Code Grant Type còn được gọi là Explicit Flow.

Implicit Grant Type

Implicit đơn giản hơn: client nhận access token trực tiếp sau khi user consent, bỏ qua trao đổi code.

Chỉ dùng browser redirect, không có kênh server-to-server; hợp cho SPA/desktop (không lưu client_secret).

Nếu user cấp consent cho access yêu cầu, OAuth service sẽ redirect browser của user đến redirect_uri được chỉ định trong authorization request. Tuy nhiên, thay vì gửi query parameter chứa authorization code, nó sẽ gửi access token và data token-specific khác như URL fragment.

GET /callback#access_token=z0y9x8w7v6u5&token_type=Bearer&expires_in=5000&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: client-app.com

Vì token nằm trong URL fragment, client phải dùng script để trích và lưu.

OAuth Authentication

OAuth có thể được dùng để xác thực qua bên thứ ba.

Đối với cơ chế OAuth authentication, flow OAuth cơ bản vẫn giống; sự khác biệt chính là cách client application sử dụng data nó nhận.

OAuth authentication thường: 1) user chọn “Log in with social media”; 2) app lấy token và gọi API info; 3) app đăng nhập user bằng token.

Cách Lỗ Hổng Xác Thực OAuth Phát Sinh?

  • Đặc tả OAuth tương đối mơ hồ và flexible bằng design
  • Thiếu built-in security feature

Cách Nhận Biết OAuth Authentication

Chúng ta có thể nhận biết ứng dụng dùng OAuth nếu nó cho phép đăng nhập bằng tài khoản từ website khác. Nếu dùng external OAuth service, xác định provider qua hostname của authorization server, rồi gửi GET đến các endpoint chuẩn:

/.well-known/oauth-authorization-server
/.well-known/openid-configuration

Chúng thường trả về file JSON configuration chứa thông tin key, chẳng hạn chi tiết của các tính năng bổ sung có thể được hỗ trợ.

Exploiting OAuth Authentication Vulnerabilities

Extending OAuth with OpenID Connect

Cách Phòng Ngừa Lỗ Hổng Xác Thực OAuth

Cho OAuth Service Providers

  • Yêu cầu client app đăng ký whitelist redirect_uris và so khớp byte-to-byte (exact match).
  • Bắt buộc state, bind với session bằng giá trị khó đoán (ví dụ hash session cookie) để chống CSRF và ngăn dùng code bị đánh cắp.
  • Trên resource server, verify access token thuộc đúng client_id và scope khớp với scope gốc.

Cho OAuth Client Applications

  • Trước khi implement, đảm bảo chúng ta hiểu rõ quy trình OAuth và các điểm có thể bị khai thác.
  • Luôn sử dụng state để chống CSRF.
  • Bao gồm parameter redirect_uri không chỉ trong request /authorization, mà còn trong request /token.
  • Đối với client OAuth mobile hoặc desktop, nơi giữ client_secret private khó khăn, sử dụng PKCE (Proof Key for Code Exchange) để bảo vệ chống interception code.
  • Nếu chúng ta đang sử dụng id_token của OpenID Connect, validate nó đúng theo đặc tả JSON Web Signature và OpenID.
  • Cẩn thận với authorization code - chúng có thể bị expose trong header Referer khi load external content (image, script, v.v.), hoặc trong file JavaScript có thể được thực thi từ domain bên ngoài.

Resources