API Security Weekly: Issue 168

This week, we have news of a vulnerability in the IndexedDB API in Safari 15 that exposed user information, a pair of vulnerabilities in AWS affecting AWS Glue and AWS CloudFormation, and a podcast featuring Rinki Sethi and Alissa Knight discussing API security.

Last week, we featured an “awesome API security” guide from a 3rd-party site with good intentions. Subsequently, we’ve discovered that this guide is a direct and unattributed copy of the excellent guide by André Rainho previously featured in this newsletter. Our apologies to Andre for this oversight, and we strongly advise readers to check out his original Awesome API Security guide.

Vulnerability: Safari 15 Leaks Information Through IndexedDB API

First up this week, we have news of a vulnerability in the IndexedDB API of the Safari 15 browser, disclosed by the team at FingerprintJS. The vulnerability potentially allows any website to track a user’s internet activity and potentially reveal their identity. At the time of writing, Apple engineers have been working on the issues identified and have marked the issue as resolved, although this has not yet been independently confirmed.

IndexedDB is a universal browser API for client-side storage that is exposed to developers through a low-level API. To enforce security, IndexedDB enforces the same-origin policy, which attempts to ensure that information is only shared with the "owner" by virtue of their origin (based on elements like the URL, hostname, and protocol). The bug in Safari 15 resulted from a violation of the same-origin policy: each time a website interacted with the database, a new blank database with the same name is created in all other active frames, tabs, and windows within the same session.

The fact that the database names were available across origin boundaries meant that websites could discover what other websites had been accessed within that browser session because database names are typically unique and website-specific. As an example, the Google User ID identifies a user of the Google platform upon authentication — examining databases for well-known names in a format unique to a Google User ID could allow websites to determine authenticated users on Google.

Currently, there is no specific user protection or mitigation that can be taken other than to wait for Apple to release a fix or update.

Vulnerability: AWS CloudFormation

Orca Security’s vulnerability researcher, Tzah Pahima, revealed the first of two AWS vulnerabilities we have this week: a vulnerability affecting the AWS CloudFormation API. After the vulnerability was disclosed to AWS, they released a fix for it within six days, across all regions. The vulnerability was caused by an XML External Entity (XXE) vulnerability in the CloudFormation service API.

The attack vector was through an anomaly in the way that CloudFormation renders templates, which allowed Pahima to trigger the XXE vulnerability. This in turn could be used to read files and perform HTTP requests on behalf of the server, potentially allowing connection to internal AWS endpoints and services. Most worryingly, Pahima believes that abuse of this vulnerability could allow an attacker to bypass tenant boundaries, giving them access to any resource within AWS.

Vulnerability: AWS Glue

The second of the AWS vulnerabilities this week, also discovered by Orca Security, is a vulnerability within the AWS Glue service. This one allowed a user to potentially create resources and access the data of other AWS Glue customers. The vulnerability was disclosed to AWS who reproduced the findings within hours. By the following morning, AWS had deployed partial mitigation globally, with the full mitigation following a few days later.

The vulnerability allowed attackers to use AWS Glue accounts to obtain credentials for roles within the AWS service’s own account. This in turn could have allowed full access to the internal service API fabric. With a privilege escalation at that point, attackers could have effectively gained elevated privileges on the AWS backbone in the region.

As stated in the Orca Security post, the researchers were able to perform the following actions: 

1. Assume roles in AWS customer accounts that were trusted by the Glue service. In every account that uses Glue, there’s at least one role of this kind.
2. Query and modify AWS Glue service-related resources in a region. This includes — but is not limited to — metadata for Glue jobs, dev endpoints, workflows, crawlers, and triggers.

Podcast: Rinki Sethi and Alissa Knight on API Security

Finally, this week is a podcast with BriefingsDirect host Dana Gardner in conversation with Rinki Sethi (Vice President and Chief Information Security Officer (CISO) at Twitter,) and Alissa Knight (familiar to readers of this newsletter) on the topic of API security.

For me, the key takeaways included:

• Securing APIs is a multi-layered approach — APIs are meant to be exposed.
• Traditional security products don’t protect us against business logic flaws.
• “APIs are the foundational plumbing for everything in our lives today. So, rightfully so, they are attracting a lot of attention — by both black hats and white hats.”
• “There’s no context in WAF security — and that’s what we need. We need to focus more on context in security.”
• “I think developers generally want to be better and do better”.
• Finding out what the environment looks like is the first step.
• “You should form a partnership and relationship with your chief technology officer (CTO), and have that partnership with infrastructure and operations, too.”

This is a great listen for anyone involved with the business or the technology around API security.