Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Implementing safe and secure LINE Login

Implementing safe and secure LINE Login

LINE DevDay 2020

November 27, 2020
Tweet

More Decks by LINE DevDay 2020

Other Decks in Technology

Transcript

  1. • Social Login Service • OAuth2 compliant • OpenID Connect

    certified What's LINE Login • and many useful features • Password-less Login • QR Code Login on PC • Auto Login on Smart phone/PC
  2. • Social Login Service • OAuth2 compliant • OpenID Connect

    certified What's LINE Login • and many useful features • Password-less Login • QR Code Login on PC • Auto Login on Smart phone/PC • Bot link • Profile+ • etc.
  3. › All LINE app users can login without ID/password What's

    Auto Login › You need not to add additional implementation
  4. › All LINE app users can login without ID/password What's

    Auto Login › Authentication information is passed from LINE client app and server to your web site or native application securely. › PKCE like mechanism is used › You need not to add additional implementation
  5. Agenda › Introduction to LINE Login › Case Study of

    Actual Security Incidents › Target of This Presentation › case 1 › case 2 › case 3 › case 4
  6. Case Study of Actual Security Incidents › Vulnerability caused by

    wrong implementation of user services › Vulnerability in LINE Login / LIFF Platform itself
  7. Case Study of Actual Security Incidents › Vulnerability caused by

    wrong implementation of user services › Even if LINE Login platform has no vulnerability, wrong implementation by user service will lead to vulnerability, such as information leak, identity theft. › Vulnerability of LINE Login Platform itself › LINE Login platform developers fix them with the highest priority. 5BSHFUPGUIJTQSFTFOUBUJPO
  8. Social Login LINE Login yoursite.com 1. login request 2. redirected

    to LINE Login server 3. ID/password input etc. end user
  9. Social Login LINE Login yoursite.com 1. login request 2. redirected

    to LINE Login server 3. ID/password input etc. 4. allow data access by yousite.com end user
  10. Social Login LINE Login yoursite.com 1. login request 2. redirected

    to LINE Login server 3. ID/password input etc. 5. redirected to yoursite.com with access right to the login user's data 4. allow data access by yousite.com end user
  11. Social Login LINE Login yoursite.com 1. login request 2. redirected

    to LINE Login server 3. ID/password input etc. 5. redirected to yoursite.com with access right to the login user's data 4. allow data access by yousite.com end user 6. access the user's data
  12. Case 1 - Access Token in Query Parameter BDDFTT@UPLFO ›

    Query parameter value can be exposed easily. › Evil attacker can get user information with the access token.
  13. Case 1 - Access Token in Query Parameter 1. An

    attacker posts a link to evil.com LINE Login server
  14. Case 1 - Access Token in Query Parameter 1. An

    attacker posts a link to evil.com 2. A victim clicks the link LINE Login server
  15. Case 1 - Access Token in Query Parameter 1. An

    attacker posts a link to evil.com 2. A victim clicks the link 3. The access_token is sent to the attacker's web server in Referrer header LINE Login server
  16. Case 1 - Access Token in Query Parameter 1. An

    attacker posts a link to evil.com 2. A victim clicks the link 3. The access_token is sent to the attacker's web server in Referrer header 4. The Attacker can get user information by the access token LINE Login server
  17. Case 1 - Access Token in Query Parameter Solution ›

    Do not expose access token. Instead use, for example, › Server storage › Browser storage with same origin policy, like session storage › Native app storage
  18. Case 2 - Fixed State Value https://access.line.me/oauth2/v2.1/authorize ?client_id=987654321 &scope=profile &response_type=code

    &redirect_uri=https%3A%2F%2Fexample.com%2Flogin%2Fcallback &state=GsdtJnrabFMWcHsq2Od8 https://access.line.me/oauth2/v2.1/authorize ?client_id=987654321 &scope=profile &response_type=code &redirect_uri=https%3A%2F%2Fexample.com%2Flogin%2Fcallback &state=GsdtJnrabFMWcHsq2Od8 Another login attempts
  19. Case 2 - Fixed State Value LINE Login yoursite.com 1.

    yoursite.com issues a state for an user and redirects a request to LINE Login How 'state' works
  20. Case 2 - Fixed State Value 2. The user do

    'LINE Login' LINE Login yoursite.com 1. yoursite.com issues a state for an user and redirects a request to LINE Login How 'state' works
  21. Case 2 - Fixed State Value 2. The user do

    'LINE Login' LINE Login yoursite.com 1. yoursite.com issues a state for an user and redirects a request to LINE Login How 'state' works 3. LINE Login redirects the request to yoursite.com w/ the state value
  22. Case 2 - Fixed State Value 2. The user do

    'LINE Login' LINE Login yoursite.com 1. yoursite.com issues a state for an user and redirects a request to LINE Login 4. The user is redirected to yoursite.com How 'state' works 3. LINE Login redirects the request to yoursite.com w/ the state value
  23. Case 2 - Fixed State Value 2. The user do

    'LINE Login' LINE Login yoursite.com 1. yoursite.com issues a state for an user and redirects a request to LINE Login 4. The user is redirected to yoursite.com 5. yoursite.com can reject the request if state value is different from the one issued for the user How 'state' works 3. LINE Login redirects the request to yoursite.com w/ the state value
  24. Case 2 - Fixed State Value LINE Login yoursite.com If

    'state' is fixed value, CSRF attack can be possible.
  25. Case 2 - Fixed State Value 1. An attacker try

    LINE Login for yoursite.com LINE Login yoursite.com If 'state' is fixed value, CSRF attack can be possible.
  26. Case 2 - Fixed State Value 1. An attacker try

    LINE Login for yoursite.com LINE Login 2. The attacker stops to redirect to yoursite.com yoursite.com If 'state' is fixed value, CSRF attack can be possible.
  27. Case 2 - Fixed State Value 1. An attacker try

    LINE Login for yoursite.com LINE Login 2. The attacker stops to redirect to yoursite.com yoursite.com 3. The attacker sends a victim the redirect link in some website or e-mail etc. If 'state' is fixed value, CSRF attack can be possible.
  28. Case 2 - Fixed State Value 1. An attacker try

    LINE Login for yoursite.com LINE Login 2. The attacker stops to redirect to yoursite.com yoursite.com 3. The attacker sends a victim the redirect link in some website or e-mail etc. 4. The victim clicks the link and login to yoursite.com as the attacker If 'state' is fixed value, CSRF attack can be possible.
  29. Case 2 - Fixed State Value 1. An attacker try

    LINE Login for yoursite.com LINE Login 2. The attacker stops to redirect to yoursite.com yoursite.com 5. The victim uploads sensitive data. The date is stored as the attacker's data since the victim is logging in as the attacker. 3. The attacker sends a victim the redirect link in some website or e-mail etc. 4. The victim clicks the link and login to yoursite.com as the attacker If 'state' is fixed value, CSRF attack can be possible.
  30. Case 2 - Fixed State Value Solution Summary What yoursite.com

    should do is 1. Issue a random value as state for each login attempts. 2. Store it securely, for example, as browser cookie. 3. Redirect the login request to LINE Login authorization endpoint with the state parameter. 4. Reject if a state value returned from LINE Login is different from the value issued at step 1.
  31. Case 3 LINE Login yoursite.com 1. do 'LINE Login' &

    get the user ID 2. call some server API
  32. Case 3 - User ID as Credential 2. call some

    server API LINE Login 1. do 'LINE Login' for a native app or SPA & get the user ID yoursite.com
  33. Case 3 - User ID as Credential 1. An attacker

    does 'LINE Login' & get the attacker's user ID LINE Login yoursite.com
  34. Case 3 - User ID as Credential 1. An attacker

    does 'LINE Login' & get the attacker's user ID LINE Login yoursite.com 2. call some server API w/ another user ID AAAAAAA
  35. Case 3 - User ID as Credential 1. An attacker

    does 'LINE Login' & get the attacker's user ID 3. The attacker can get/update a victim's data LINE Login yoursite.com 2. call some server API w/ another user ID AAAAAAA
  36. Case 3 - User ID as Credential Actually it's difficult

    for an attacker to find a valid LINE user ID. 1. LINE User ID is random value generated by cryptographically secure way. 2. LINE User ID is PPID. The ID value for service provider A is different from the ID value for service provider B even if the IDs are for same user.
  37. Case 3 - User ID as Credential Actually it's difficult

    for an attacker to find a valid LINE user ID. 1. LINE User ID is random value generated by cryptographically secure way. 2. LINE User ID is PPID. The ID value for service provider A is different from the ID value for service provider B even if the IDs are for same user. But this does not mean no risk.
  38. Case 3 - User ID as Credential Solution * Stop

    using user ID as credential * Use ID Token / Access Token instead
  39. Case 3 - User ID as Credential Solution * Stop

    using user ID as credential * Use ID Token / Access Token instead NOT enough!!!
  40. Case 4 2. call some server API 1. do 'LINE

    Login' & get an access token LINE Login yoursite.com
  41. Case 4 - No Token validation 2. call some server

    API 1. do 'LINE Login' & get an access token Validate the token received! LINE Login yoursite.com
  42. Case 4 - No Token validation 1. A victim does

    'LINE Login' & get an access token for an attacker's service seems.safe.but.evil.com LINE Login yoursite.com
  43. Case 4 - No Token validation 1. A victim does

    'LINE Login' & get an access token for an attacker's service seems.safe.but.evil.com 2. The attacker's service get the token LINE Login yoursite.com
  44. Case 4 - No Token validation 1. A victim does

    'LINE Login' & get an access token for an attacker's service seems.safe.but.evil.com 2. The attacker's service get the token 3. The attacker calls yoursite.com with the access token LINE Login yoursite.com
  45. Case 4 - No Token validation 1. A victim does

    'LINE Login' & get an access token for an attacker's service seems.safe.but.evil.com 2. The attacker's service get the token 3. The attacker calls yoursite.com with the access token LINE Login yoursite.com 4. LINE API is called as the victim & the victim's user ID is returned
  46. Case 4 - No Token validation 2. The attacker's service

    get the token 1. A victim does 'LINE Login' & get an access token for an attacker's service 3. The attacker calls yoursite.com with the access token 4. Call Token Validation API before other API call Solution seems.safe.but.evil.com LINE Login yoursite.com
  47. Case 4 - No Token validation Call Verify Access Token

    API and confirm that returned client_id is your service's client ID curl -v -X GET \ 'https://api.line.me/oauth2/v2.1/verify?access_token=eyJhbGciOiJIUzI1NiJ9.UnQ_o-GP0VtnwDjbK0C8E_NvK...' { "scope":"profile", "client_id":"1440057261", "expires_in":2591659 } https://developers.line.biz/en/reference/social-api/#verify-access-token
  48. Case 4 - No Token validation If you use ID

    Token, you can validate it by yourself. https://developers.line.biz/en/docs/line-login/integrate-line-login/#write-original-code
  49. Case 4 - No Token validation If you use ID

    Token, you can validate it by yourself. https://developers.line.biz/en/docs/line-login/integrate-line-login/#write-original-code LINE Login provides a utility API and you can use it to verify ID Token. https://developers.line.biz/en/reference/social-api/#verify-id-token curl -v -X POST 'https://api.line.me/oauth2/v2.1/verify' \ -d 'id_token=eyJraWQiOiIxNmUwNGQ0ZTU2NzgzYTc5MmRjYjQ2ODRkOD...&client_id=1440057261' { "iss": "https://access.line.me", "sub": "U1234567890abcdef1234567890abcdef", "aud": "1234567890", "exp": 1504169092, "iat": 1504263657, "nonce": "0987654asdf", "amr": [ "pwd", "linesso", "lineqr" ], "name": "Taro Line", "picture": "https://sample_line.me/aBcdefg123456", "email": "[email protected]" }