Access Token Verification
Khi nhận token từ các third-party service chẳng hạn như Facebook, application nên kiểm tra xem token này có hợp lệ hay không bằng cách gọi API để kiểm tra danh tính của chủ sở hữu token.
Nếu không, attacker có thể dùng token giả mạo để thực hiện account takeover (ATO).
Lack of Token Verification on Vidio
Luồng OAuth của Vidio:
Khi applicatiom được đăng ký với developers.facebook.com, Facebook sẽ tạo ra một unique random App ID. Bằng cách này, Facebook sẽ biết được app nào đang thực hiện OAuth flow.
Sau khi log in vào Facebook bằng bước 3, Facebook sẽ tạo ra một access token đại diện cho danh tính của người dùng. Theo tài liệu mô tả của Facebook, sau khi nhận được access token thì application nên gửi API đến Facebook để thực hiện xác thực.
Tuy nhiên, Vidio không thực hiện việc này và attacker có thể sử dụng access token của application khác (có App ID khác) để gửi đến trang web của Vidio.
Creating a Malicious Website for Collecting Tokens - YourTimePlanner.com
Giả sử attacker tạo ra một malicious website có tên là YourTimePlanner.com và đăng ký nó với Facebook hoặc Google.
Sau đó. attacker dụ người dùng truy cập website này (có thể là một website shopping có nhiều discount) và dụ họ đăng nhập vào sử dụng các tài khoản social media. Việc đăng nhập vào một website sử dụng social media account chỉ để lộ email và điều này không gây rủi ro quá nhiều nên người dùng có thể sẽ sign-in.
Khi người dùng sign-in thì attacker sẽ có access token được tạo ra bởi Facebook dành cho ứng dụng của attacker.
Cuối cùng, nếu người dùng cũng có tài khoản ở trên Vidio thì attacker sẽ thế access token vào request cuối cùng để thực hiện account takeover:
Lack of Token Verification on Bukalapak.com via Facebook Login
Login flow của Bukalapak tương tự như Vidio:
Endpoint /fb_login ở accounts.bukalapak.com sẽ nhận access token thông qua query param và sẽ trả về credentials cho người dùng.
Tuy nhiên, Bukalapak không thực hiện việc verify token và nếu insert token từ một app khác thì Bukalapak vẫn trả về credentials cho người dùng. Với credentials có được, attacker có thể take over account của nạn nhân.
Finding OAuth Vulnerabilities on Grammarly - and Gaining Full account Access
Flow OAuth của Grammarly:
Ở bước 1, user click vào nút “Sign in with Facebook” thì sẽ dẫn đến URL sau:
https://www.facebook.com/v9.0/dialog/oauth?client_id=945246385586366&redirect_uri=https://www.grammarly.com%2Fsocial%2Fredirect&response_type=code&state=[random]&scope=email&auth_type= Chú ý rằng client_id (App ID) là 945246385586366.
Sau đó, Facebook redirect về Grammarly để cung cấp secret code:
https://www.grammarly.com/social/redirect?code=[code]User gửi code này đến https://auth.grammarly.com sử dụng một POST request:
Cuối cùng, ở bước 4, https://auth.grammarly.com sẽ xác thực người dùng dựa trên code và trả về user credentials (Grammarly đổi code để lấy access token ở backend). Khi exchange code để lấy token, Facebook sẽ thực hiện validate App ID và việc tái sử dụng token như ở Vidio và Bukalapak là không được.
Tuy nhiên, khi nhìn vào POST request ta thấy rằng nó có chứa trường code. Tác giả thử thay thành một số từ khác chẳng hạn như token, Token, … và thực hiện brute-force. Cuối cùng, tìm thấy tên field là access_token:
Attacker chỉ việc thay vào token thu được từ malicious app là có thể thực hiện account takeover:
