sábado, 27 de janeiro de 2024

Security And Privacy Of Social Logins (III): Privacy In Single Sign-On Protocols

 This post is the second out of three blog posts summarizing my (Louis Jannett) research on the design, security, and privacy of real-world Single Sign-On (SSO) implementations. It is based on my master's thesis that I wrote between April and October 2020 at the Chair for Network and Data Security.

We structured this blog post series into three parts according to the research questions of my master's thesis: Single Sign-On Protocols in the Wild, PostMessage Security in Single Sign-On, and Privacy in Single Sign-On Protocols.

Overview

Part I: Single Sign-On Protocols in the Wild

Although previous work uncovered various security flaws in SSO, it did not work out uniform protocol descriptions of real-world SSO implementations. We summarize our in-depth analyses of Apple, Google, and Facebook SSO. We also refer to the sections of the thesis that provide more detailed insights into the protocol flows and messages.
It turned out that the postMessage API is commonly used in real-world SSO implementations. We introduce the reasons for this and propose security best practices on how to implement postMessage in SSO. Further, we present vulnerabilities on top-visited websites that caused DOM-based XSS and account takeovers due to insecure use of postMessage in SSO.

Part III: Privacy in Single Sign-On Protocols

Identity Providers (IdPs) use "zero-click" authentication flows to automatically sign in the user on the Service Provider (SP) once it is logged in on the IdP and has consented. We show that these flows can harm user privacy and enable new targeted deanonymization attacks of the user's identity.

Introduction to XS-Leaks in Single Sign-On

Cross-site leak (XS-Leak) refers to a family of browser side-channel techniques that can be used to infer and gather information about users [...]. While the deanonymization capabilities of XS-Leak attacks are only just being realized, some researchers have said the technique will soon be in the OWASP Top 10. 

In SSO setups, redirects can leak private information about the user. Thus, we focused on XS-Leaks that detect cross-origin redirects, i.e., whether a cross-origin request returns an `HTTP/200` or `HTTP/302` response. In this post, we present an XS-Leak that is based on the Fetch API and detects cross-origin redirects with 100% accuracy. The following method expects a URL, sends a GET request, and finally returns `true` if the response is a redirect or `false` if the response is no redirect:
// let is_redirect = await xs_leak_redirect("<URL>");  async function xs_leak_redirect(url) { 	let res = await fetch(url, { 		mode: "cors", 		credentials: "include", 		redirect: "manual" 	}).then( (response) => { 		if (response.type == "opaqueredirect") { 			return true; 		} 	}).catch( (error) => { 		return false; 	}); 	return res; } 

More details are provided in Section 5.1.4.1 of the thesis.

XS-Leaks in Single Sign-On: Account Leakage Attack

With the account leakage attack, the attacker can determine whether the victim has an account on a targeted SP with a certain IdP. Specifically, the attacker checks whether the victim has granted consent to the targeted SP with the IdP. This attack is scalable: The attacker can test multiple (SP, IdP) pairs and check for which pair the victim has an account on the SP. The following prerequisites must hold:
  • The victim visits an attacker-controlled website.
  • The victim is signed-in on the IdP (i.e., in Google Chrome with its Google account).
  • The IdP supports the standardized `prompt=none` parameter.
The attack idea is simple: Let's assume the attacker wants to know whether the victim has an account on SP `sp.com` with the IdP `idp.com`. The attacker first tricks the victim into visiting its malicious website `attacker.com`. We further assume that the victim has an active session on the IdP. Then, the attacker constructs an Authentication Request URL, as shown in the figure below. Note that the SP `sp.com` has the `client_id=superSecretClient` on the IdP, the `redirect_uri` is set to `sp.com/redirect`, and the `prompt=none` parameter is set. 
From the attacker's website, a cross-origin `Fetch` request is sent to that URL as shown before. If the `prompt=none` flow is requested with established consent on the SP, the IdP returns the Authentication Response as an `HTTP/302` redirect to the `redirect_uri`. If the victim has not granted the SP's consent, the IdP returns the consent page with an `HTTP/200` response and asks the user to grant the consent. Thus, based on whether the victim has or has not an account on `sp.com`, the IdP returns an `HTTP/302` redirect or an `HTTP/200` response. Although the Same Origin Policy prevents us from viewing the response from `idp.com`, we can use the XS-Leak to detect whether a redirect was performed or not. If a redirect was performed, the victim has an account on `sp.com` with the IdP. If no redirect was performed, the victim has no account.

We tested this attack with the Apple, Google, and Facebook IdP. It only works for Google and Facebook since Apple requires user interaction in each flow. A working PoC is provided on https://xsleak.sso.louisjannett.de. If the "Start" button is clicked, the website checks if you have an account on adobe.com, ebay.com, imdb.com, medium.com, or vimeo.com using either the Google or Facebook IdP. Make sure that you are signed in at Google and Facebook before testing and enable third-party cookies.

To circumvent this attack, the IdP must return an error as `HTTP/302` redirect if the `prompt=none` flow is requested, but no consent is given. This mitigation is described in the OpenID Connect specification, but as shown, not adopted by real-world IdPs.

More details are provided in Section 5.1 of the thesis.

XS-Leaks in Single Sign-On: Identity Leakage Attack

The identity leakage attack extends the account leakage attack by the `login_hint` parameter. The attacker can determine whether the victim has a certain identity on a targeted IdP. The attacker can use this information to check if a certain person is visiting its website. Therefore, all prerequisites of the account leakage attack must hold and the IdP must support the standardized `login_hint` parameter.

Once a victim visits the malicious website, the attacker must initially guess an (SP, IdP) pair that the victim most likely gave consent to, i.e., that causes the IdP in the `prompt=none` flow to return a redirect to `sp.com/redirect`. The attacker can use the account leakage attack to determine such a pair by testing the most-popular SPs and IdPs. Then, a new Authentication Request is created, and the `login_hint` parameter is set to the email address of the victim, i.e., `alice@example.com`. The attacker sends the Fetch request and determines whether the IdP returns an `HTTP/302` redirect or an `HTTP/200` response. If a redirect was performed, the attacker knows that the Authentication Request was valid, and thus the victim is `alice@example.com`. If no redirect was performed, the victim is not `alice@example.com`. The success of this attack depends on whether the attacker can guess (or eventually knows) an (SP, IdP) pair that the targeted victim gave consent to.

We tested this attack with the Apple, Google, and Facebook IdP. It only works for Google since Apple does not support the `prompt=none` flow, and Facebook does not support the `login_hint` parameter. We discovered that the `login_hint` parameter must contain a valid email address registered at Google. Otherwise, this parameter is ignored.


To mitigate this leakage, the IdP must return an error as `HTTP/302` redirect if a `login_hint` parameter is queried that the user does not own. We did not find any information about the `login_hint` parameter in the OpenID Connect specification that proposes guidelines for this scenario.

More details are provided in Sections 5.1 of the thesis.

Automatic Sign-In and Session Management Practices in the Wild

Following the observations of the account leakage and identity leakage attacks, we analyzed "zero-click" SSO flows in terms of automatic sign-in features provided by the IdPs with their SDKs. We found that under certain assumptions, the SDKs can be configured to automatically sign in the user on the SP even though the user did not click on the sign-in button and may not notice the sign-in process.

Google and Facebook support automatic sign-in with their SSO SDKs: Google Sign-In, Google One Tap, and Facebook Login. They follow a similar approach: The user visits the SP website that integrates and initializes the SDK with automatic sign-in enabled. Suppose the user has an active session on the IdP, valid consent for the SP, and third-party cookies enabled. In that case, the SDK first retrieves a logout state from browser storage to determine whether the user signed out previously using the SDK's sign-out method. If the logout state is set to false or does not exist, the SDK returns the Authentication Response to the SP website, i.e., to a registered callback. If it is set to true, the SDK does not proceed with the automatic sign-in and instead requires the user to click on the sign-in button. Thus, the execution of the automatic sign-in flow depends on the stored logout state. If the browser storage is cleared (i.e., cookies are deleted or a private window is opened), the logout state does not exist, and thus the automatic sign-in is enabled.

Note that the logout state is only a feature provided by the SDKs to stop unwanted sign-in operations on the SP. They do not prevent the SP from secretly receiving tokens from the IdP. If the SP does not use the SDK's sign-out method, the logout state will never be set to true. Alternatively, the SP may manually request the tokens from the IdP in the background without paying attention to any logout state. Note that this automatic sign-in flow is different than the standardized `prompt=none` flow because it returns the tokens in the background (i.e., via Fetch requests), whereas the `prompt=none` flow requires a redirect that is in some form visible to the user.

Google and Facebook use different approaches to receive the Authentication Response in the background. Google sends a `getTokenResponse` RPC from the SP website to its proxy iframe and receives the tokens with postMessage. Facebook issues a simple CORS request and receives the tokens in the CORS response.

For instance, SPs can send the following CORS request with the Fetch API to Facebook:
GET /x/oauth/status?client_id=<CLIENT_ID> HTTP/1.1 Host: www.facebook.com Origin: https://sp.com Cookie: c_user=REDACTED; xs=REDACTED; 

If the user has an active session at Facebook (i.e., cookies are set) and valid consent, Facebook responds with a CORS response and explicitly allows the SP to read the `fb-ar` header that contains the tokens:
HTTP/1.1 200 OK Access-Control-Allow-Origin: https://sp.com Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: fb-ar,fb-s fb-s: connected fb-ar: {"user_id": "REDACTED", "access_token": "REDACTED", "signed_request": "REDACTED"} 

We tested the automatic sign-in on top-visited SPs and found that some of them implement it as expected. For instance, `change.org` supports automatic sign-in with Facebook: First, we open `change.org` without being logged in on Facebook. Thus, we are not signed-in automatically. Then, we log in on Facebook and reload `change.org`. As shown, `change.org` uses the CORS request to receive the tokens from Facebook and finally logs us in. The user interface does not indicate that we were just signed in. Only the small profile picture in the top right corner is added to the UI.


More details and examples of automatic sign-in flows are provided in Section 5.3 of the thesis.

Acknowledgments

My thesis was supervised by Christian MainkaVladislav Mladenov, and Jörg Schwenk. Huge "thank you" for your continuous support, advice, and dozens of helpful tips. 
Also, special thanks to Lauritz for his feedback on this post and valuable discussions during the research. Check out his blog post series on Real-life OIDC Security as well.

Authors of this Post

Louis Jannett
More articles
  1. Hack And Tools
  2. Hacker Tools 2020
  3. How To Install Pentest Tools In Ubuntu
  4. Hacking Tools Free Download
  5. Hacking Tools Usb
  6. Wifi Hacker Tools For Windows
  7. Hacker Tools Mac
  8. Pentest Tools Url Fuzzer
  9. Hacker Tools 2020
  10. Tools 4 Hack
  11. Best Hacking Tools 2019
  12. Pentest Tools Download
  13. Pentest Tools Download
  14. Pentest Tools Download
  15. Hacker Tools Free Download
  16. Hack Apps
  17. Hacking Tools Online
  18. Hacking Tools Download
  19. Hack Tools
  20. Pentest Tools
  21. Hack Tools
  22. Pentest Tools Find Subdomains
  23. Pentest Tools Website
  24. Hacker Tools 2020
  25. Pentest Tools Apk
  26. Hacker Tools Linux
  27. Hack Tools Github
  28. Hacker Tools For Windows
  29. Hacking Tools Github
  30. Hacking Tools For Windows 7
  31. Pentest Tools Nmap
  32. Nsa Hack Tools
  33. Hack Tools Github
  34. Pentest Recon Tools
  35. Hack Tools Online
  36. Pentest Tools Android
  37. Install Pentest Tools Ubuntu
  38. Best Hacking Tools 2020
  39. Hack Tools Mac
  40. Pentest Tools For Mac
  41. Hack Rom Tools
  42. Hacker Tools Github
  43. Bluetooth Hacking Tools Kali
  44. Pentest Reporting Tools
  45. Hacker Tools 2019
  46. Hacker Tools Online
  47. Github Hacking Tools
  48. Hacker Tools Mac
  49. Hacking Tools Mac
  50. Hacking Tools For Games
  51. Hacker Security Tools
  52. Usb Pentest Tools
  53. New Hack Tools
  54. Hacking Tools Online
  55. Android Hack Tools Github
  56. Pentest Automation Tools
  57. Pentest Tools Apk
  58. Hacking Tools Kit
  59. Hacking Tools Kit
  60. Blackhat Hacker Tools
  61. Hacker Tools 2020
  62. Physical Pentest Tools
  63. Hack Tools Download
  64. Pentest Tools Url Fuzzer
  65. What Is Hacking Tools
  66. Underground Hacker Sites
  67. Hacking Tools Online
  68. Hacker Security Tools
  69. Hacker Tools Apk Download
  70. Hacker Tools Github
  71. Hacking Tools Windows 10
  72. Hacker Tool Kit
  73. How To Make Hacking Tools
  74. Hack Website Online Tool
  75. Tools Used For Hacking
  76. Hacking App
  77. Nsa Hack Tools
  78. Free Pentest Tools For Windows
  79. Tools 4 Hack
  80. What Is Hacking Tools
  81. Game Hacking
  82. Hacker Tools Github
  83. Hacking Tools And Software
  84. Hack And Tools
  85. Blackhat Hacker Tools
  86. Black Hat Hacker Tools
  87. Pentest Tools Url Fuzzer
  88. Easy Hack Tools
  89. Hacker Tools Mac
  90. Hacking Tools For Beginners
  91. Free Pentest Tools For Windows
  92. World No 1 Hacker Software
  93. Pentest Reporting Tools
  94. Pentest Tools For Android
  95. Pentest Reporting Tools
  96. Pentest Tools Tcp Port Scanner
  97. Hacker Security Tools
  98. Pentest Tools Framework
  99. Blackhat Hacker Tools
  100. Blackhat Hacker Tools
  101. Best Pentesting Tools 2018
  102. Pentest Tools Url Fuzzer
  103. What Is Hacking Tools
  104. Hacking Tools 2019
  105. Pentest Tools Nmap
  106. Hack And Tools
  107. Best Pentesting Tools 2018
  108. Pentest Tools Url Fuzzer
  109. Hacker Tools Windows
  110. Hacking Tools Kit
  111. How To Install Pentest Tools In Ubuntu
  112. Hacker Tools Mac
  113. Pentest Automation Tools
  114. Hacker Tools List
  115. Pentest Tools For Ubuntu
  116. Pentest Tools Linux
  117. Pentest Tools Android
  118. Pentest Tools Kali Linux
  119. Best Hacking Tools 2019
  120. Hack Tool Apk
  121. Hacker Tools Apk Download
  122. Hacking Tools Windows
  123. Hack And Tools
  124. Pentest Tools Linux
  125. Best Hacking Tools 2020
  126. Hacker Techniques Tools And Incident Handling
  127. What Is Hacking Tools
  128. Pentest Tools Kali Linux
  129. Hacking Tools For Windows Free Download
  130. Hacking Tools For Mac
  131. Game Hacking
  132. Hacker Tools For Mac
  133. Hacker Tools Online
  134. How To Install Pentest Tools In Ubuntu
  135. Hack Tools
  136. Pentest Tools Website
  137. Growth Hacker Tools
  138. What Are Hacking Tools
  139. Pentest Box Tools Download
  140. Ethical Hacker Tools
  141. Hack App
  142. Nsa Hacker Tools
  143. Hacker Tools Free Download
  144. Pentest Tools Online
  145. Pentest Tools
  146. New Hack Tools
  147. Hacking Tools
  148. Physical Pentest Tools
  149. Hacker Tools List
  150. Hacking Tools And Software
  151. Hacker Tools Free
  152. Hacking Tools Mac
  153. World No 1 Hacker Software
  154. Hack Tools Pc
  155. Hacking Tools 2020
  156. Android Hack Tools Github
  157. Hacking Tools Online
  158. Usb Pentest Tools
  159. Easy Hack Tools
  160. Hacker Tools Github
  161. Game Hacking
  162. Pentest Tools Review
  163. Pentest Reporting Tools
  164. Hack And Tools
  165. Hacking Tools 2020
  166. Hack Rom Tools
  167. Pentest Tools Open Source
  168. New Hacker Tools
  169. Pentest Tools Open Source
  170. Hacker Tools
  171. Hacker Tools For Mac
  172. Hacking Tools Online
  173. Hack Rom Tools
  174. Hacker Tools For Pc
  175. Hack Tools 2019
  176. Physical Pentest Tools

Nenhum comentário: