Quartz 🪬

Common OAuth Vulnerabilities

3 min read

Bài viết này đề cập đến một số luồng phân quyền sử dụng OAuth và các tấn công phổ biến. Ngoài Implicit Flow và Authorization Code Flow thì còn có  Authorization Code Flow with PKCE, Client Credentials Flow, Device Authorization Flow và Resource Owner Password Credentials Flow.
 
Về các cách tấn công, ngoài CSRF trong chức năng liên kết tài khoản với third-party account, Open Redirect sử dụng `redirect_uri` và Scope Upgrade Attack thì còn có Mutable Claims Attack, Client Confusion Attack và Redirect Scheme Hijacking.

Ngoại trừ Implicit Flow và Resource Owner Password Credentials Flow thì các flow còn lại đều đã được đề cập ở OAuth.

Mutable Claims Attack

Theo đặc tả của OAuth thì người dùng sẽ được định danh bởi sub claim ID token trả về bởi OpenID Connect provider. Ví dụ:

{
  "iss": "https://example.com/",
  "aud": "client_id_123",
  "exp": 1714823900,
  "iat": 1714820300,
  "sub": "abc123def456ghi789"
}

Tuy nhiên, không có định dạng chung cho giá trị của claim này. Để cố gắng thống nhất giữa các authorization server khác nhau, các client application sử dụng email làm định danh. Điều này có thể gây ra vấn đề vì một số authorization server cho phép người dùng được thay đổi email (ta gọi nó là một mutable claim) và dẫn đến là kẻ tấn công có thể mạo danh email của nạn nhân để thực hiện chiếm tài khoản.

According to the OAuth specification, the user is uniquely identified by the "sub" (subject) claim. Most IdPs provide the common (yet non-standard) "email" claim. Using the email claim as the user identifier becomes an issue when this claim is mutable, which is why most IdPs advise against using email as an identifier. **In Microsoft Azure AD, the email claim is both mutable and unverified so it should never be trusted** **or used as an identifier**.
 
A bad actor can change the Email attribute under "Contact Information" in the Azure AD account to control the "email" claim in the returned identity JWT.

Client Confusion Attack

Khi ứng dụng sử dụng Implicit Flow thì nên client application verify xem token nhận được có phải tương ứng với client ID của nó hay không. Nếu không, attacker có thể dùng token của một ứng dụng mà hắn kiểm soát rồi gửi đến client application nhằm đăng nhập dưới danh nghĩa của nạn nhân.

Cụ thể hơn, attacker sẽ tạo ra một ứng dụng có sử dụng Implicit Flow. Nếu người dùng đăng nhập vào ứng dụng này có tài khoản ở một client application không verify token thì kẻ tấn công có thể tái sử dụng token ở ứng dụng của hắn để đăng nhập vào client application.

Minh họa:

OAuth Client Confusion Attack

Luồng an toàn:

OAuth Secure Implicit Flow

Một ví dụ thực tế: Oh-Auth - Abusing OAuth to Take over Millions of Accounts

Redirect Scheme Hijacking later

Để có thể nhận được callback request kèm theo Authorization Code từ OAuth server, các mobile developer thường triển khai các custom scheme. Nếu có một ứng dụng độc hại khác được cài đặt và cũng sử dụng scheme này và không có các validation hợp lệ, kẻ tấn công có thể redirect đến ứng dụng độc hại để đánh cắp Authorization Code.

Do cách tấn công này liên quan nhiều đến mobile applicatioon nên tạm thời không đề cập nhiều ở đây.

[Common OAuth Vulnerabilities · Doyensec's Blog](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html#Redirect%20Scheme%20Hijacking)
list
from outgoing([[Common OAuth Vulnerabilities]])
sort file.ctime asc

Resources