Angular-ing for AuthZ, Problematic anti-patterns in Single Sign On Systems
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/66a9fd278d7857247f64c0f2_66a3678333c13bbf2c43bb87_Aspen%2520Labs.png)
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/668320753d974b9a8b020548_authz-sso-aspen-blog.png)
Angular-ing for AuthZ, Problematic anti-patterns in Single Sign On Systems
Authentication is one of the most crucial elements of any application. It is perhaps unsurprising that many choose to use Single Sign On (SSO) from Google, Microsoft, and others. Instead of managing an entire login flow, forgotten password flow and other authentication patterns, SSO offloads this workload to the SSO provider. While this has numerous advantages for development teams, these systems are built for third parties passing around tokens via APIs; if these tokens aren’t handled with care, the entire login system can be exploited.Using publicly available information and APIs, the ASPEN team identified a flaw in the SSO login flow of a Fortune 500 company in the health and wellbeing sector and promptly reported it. While this specific vulnerability has now been resolved and mitigated, it is important to recognize some of the flaws in login flows that could easily be replicated in other environments and applications.
Bypassing an SSO login flow
The ASPEN team initially identified this Angular application with SSO after performing subdomain reconnaissance on a well-known large healthcare brand. Angular websites are a goldmine for API research since these websites typically offer a highly interactive JavaScript front end that then calls REST API endpoints. A typical login flow would be:
- It would check for a logged in user (via Microsoft SSO) and redirect to the SSO page if there is not.
- It would call the Microsoft Graph API to retrieve the user’s information. In particular, it wanted the email address.
- The email address was used in a user search API to retrieve the user’s information. This included data like name, access role, and regions the user is allowed to access.
- This API (and all others) on the website used API key authentication, and that key was present in the client-side JavaScript.
- The login data is saved to session storage. The role and region are used later to control and present data.
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/667fa6c071414a358ee7c12d_image2.png)
We conducted research to find the best way to gain entry into the app with as little modification as possible. The user search API works by sending an email address, so we attempted to locate potentially valid company emails on LinkedIn and Google. We tried various emails and even some wildcard patterns. Nothing was successful in getting the API to reveal user information until a value of “all” was used. When that was used, it returned all the user information in the system:
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/667fa6c071414a358ee7c13b_image4.png)
We now know all the valid user emails and with this, we were ready to make changes to the Angular code.
Angular code modifications
The goal of our modifications was to trick the app into thinking that the SSO login succeeded, and set the logged in email to one that is known to be a Global Admin. The app had to be modified 3 different ways:First, a few changes had to be made to the login function to trick it into thinking a valid user is logged in:
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/667fa6c071414a358ee7c137_image5.png)
Second, there was an issue where some pages would redirect to SSO login, despite the user having the proper access role. The easiest way to fix and allow access to all pages was to simply short-circuit the Angular canActivate function and return true in all cases:
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/667fa6c071414a358ee7c128_image6.png)
Finally, we modified the Microsoft Angular Authentication Library’s activateHelper function to trick it into thinking an account is logged in. This stopped another case of being redirected to the SSO login:
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/667fa6c071414a358ee7c131_image3.png)
Once all that was done, we had Global Admin access to the entire app and could access the records of 7½ million users:
![](https://cdn.prod.website-files.com/65c5190e5dd9c9f6dde799df/667fa6c071414a358ee7c134_image1.png)
Reporting to the company
The Traceable ASPEN team put together a report and sent it through the company’s vulnerability disclosure program. The timeline is as follows:
- September 18, 2023: Report sent. 12 minutes later, the company responded confirming they received the report.
- September 20, 2023: The company confirmed the issue was valid and are working on fixing it. At this point the entire website had been taken offline, so the issue was essentially contained.
As seen from the timeline, the company's response to our report was exemplary. Often it takes weeks, if not months, to get an acknowledgement and remediation done. This was one of our best experiences engaging with a vulnerability disclosure team, and we believe that they are a great model for efficiency and others should strive for a similar response. We shared this blog with the company prior to publication for their approval. On their request, we have redacted their name.
Lessons & takeaways
The Traceable ASPEN team was able to identify this API security vulnerability before it could have been abused. Our recommendations for similar SSO Angular applications are:
- Stop and think before including any API keys in your code. Think about what could happen if you published the key for the world to see. If you must include them, make sure they are narrowly scoped to specific operations they are needed for. Remember that these keys provide long-term access to data. For APIs meant to be accessed by logged in users, API key authentication is not a good fit.
- Fully implement SSO login tokens and login. In this case, instead of using the OAuth token, they used API keys. All the company’s APIs should have used this SSO access token to authenticate instead of an API key. It is also important to check what permissions the user has and properly deny access to API resources the user is not allowed to use.
- Check to make sure that admin APIs are well protected. The user search API with the “email=all” query option seems to be an admin API, but it was accessible by a user API key. This is what is called a BFLA (Broken Function Level Authorization) vulnerability. Make sure all APIs implement proper access controls to avoid introducing backdoors into your websites.
How Traceable can help
Traceable ASPEN provides vendor neutral and threat driven research in API security, investigating the latest breaches with world leading expertise and analysis. We believe in securing the world’s APIs with actionable insights from across the industry. We are offensively minded, defensively driven, and focused on your protection. Get the ASPEN advantage, join the biggest names in finance and software and secure your most valuable API assets with Traceable’s complete API security platform. From attack surface discovery, advanced mitigation and blocking to threat intelligence, see how we can transform your API security across the API lifecycle and request a demo today.
The Inside Trace
Subscribe for expert insights on application security.