5 Critical Vulnerabilities Found in Google’s Threadit Collaboration Tool

Threadit was a web-based platform developed by Google’s experimental division, Area 120, that enabled users to create and share brief video messages seamlessly. Launched in March 2021 and discontinued in December 2022, the tool aimed to enhance team collaboration through short video clips.

This article details five core security vulnerabilities discovered in Threadit, shedding light on their potential risks and discussing mitigation strategies. These vulnerabilities highlight common pitfalls in web application security, particularly for emerging collaboration tools.

Table of Contents

1. DOM-Based XSS Combined with Clickjacking
2. Removing the Post Owner from Access Control Lists (ACL)
3. Clickjacking to Delete User Accounts
4. Unauthorized Access to Viewers of Public Posts
5. Exposure of Logged-in User Information

DOM-Based XSS Combined with Clickjacking

Cross-Site Scripting (XSS) is a prevalent client-side vulnerability where malicious scripts are injected into trusted websites. Threadit’s interface allowed embedding links without stringent validation. An attacker could exploit this by altering a URL parameter to initiate JavaScript execution within the DOM, a form of DOM-based XSS.

Exploitation Steps

• Create a new Threadit post featuring a Call-To-Action (CTA) link.
• Intercept and modify the patch request to inject a javascript: URI in the link’s URL field.
• Publish the post, which now contains the malicious link.
• When a user clicks the CTA link, depending on the browser, the script may execute.

Notably, Chromium-based browsers block javascript: URIs from opening in new tabs (due to the target="_blank" attribute), but Firefox permits their execution. To bypass this and facilitate exploitation across browsers, attackers could manipulate user interactions such as forcing links to open in the same tab.

Adding Clickjacking Amplification

Threadit lacked the X-Frame-Options HTTP header, allowing pages to be embedded in frames or iframes on third-party sites. This omission led to effective clickjacking attacks, where a transparent iframe overlays a malicious link that users unknowingly click. Attackers use CSS and JavaScript to position the iframe’s interactive elements precisely under the cursor.

Preventive Measures:

• Enforce strict URL validation; allow only http:// or https:// schemes for links.
• Implement X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' headers to prevent framing.
• Set rel="noopener noreferrer" on links to mitigate window.opener API attacks.

Timeline of vulnerability handling:

Removing the Post Owner from Access Control Lists (ACL)

Access Control Lists govern user permissions for viewing and modifying content. In Threadit, a critical flaw allowed authorized viewers—not just the owner—to alter ACL entries improperly, including the removal of the post owner’s ownership privileges.

How the Vulnerability Worked

• Users with view permissions could add new viewers by their email addresses.
• Subsequently, those users could remove the newly added viewers.
• By exploiting this logic, an attacker could downgrade the owner’s role from ROLE_OWNER to ROLE_READ.
• Once downgraded, the attacker could remove the owner entirely, locking them out of their content.

Security Implications

This flaw essentially allowed any viewer to hijack ownership, preventing legitimate owners from accessing their own posts. This could result in substantial data loss or unauthorized censorship.

Recommended Fixes

• Backend validation to prevent ACL modifications to owner roles.
• Return descriptive errors like Owner scope cannot be updated when violations are attempted.
• Audit ACL logic to ensure only authorized roles can change ownership status.

Incident timeline:

Clickjacking Attack Leading to Account Deletion

Threadit’s user profile page included a feature to delete accounts. Coupled with the earlier iframe embedding vulnerability (lack of frame defense headers), attackers could mount a sophisticated clickjacking attack to stealthily delete users’ accounts.

Attack Methodology

• Embed the profile page within a hidden iframe on an attacker-controlled site.
• Use CSS and JavaScript to reposition the iframe, aligning the Delete Account button under the user’s click point.
• Listen for user clicks; after each click, programmatically shift iframe to the next UI element to be clicked.
• Sequential clicks on the victim’s site cause the iframe to ‘click’ through confirmation dialogs, ultimately deleting the user’s account.

Mitigation Strategies

• Apply strict frame-busting HTTP headers like X-Frame-Options: DENY or CSP frame-ancestors directives.
• Implement additional CSRF tokens and user interaction confirmations for critical actions.
• Use UI elements that are harder to automate, such as CAPTCHAs or biometric confirmation.

Significant dates:

Unauthorized Access to Viewers of Public Posts

Threadit posts displayed a list of users who viewed them, adding transparency for owners and collaborators. However, a backend flaw allowed any user accessing a public post link—even anonymous users—to retrieve the full list of viewers, including names, emails, and profile pictures.

Details

• The application UI hides the “viewers” icon for anonymous visitors, implying restricted access.
• Despite the UI restriction, unauthorized GET requests to /message/{messageId} returned full viewer lists.
• This led to inadvertent leakage of sensitive user data to the public.

Security Risks

This vulnerability exposed personally identifiable information (PII) violating privacy principles and potentially breaching legal compliance such as GDPR.

Remediation Recommendations

• Enforce backend access control on viewer lists, limiting visibility to authorized users only.
• Audit APIs to prevent information disclosure through unauthenticated endpoints.
• Regular penetration testing to uncover such inadvertent data leaks.

Vulnerability timeline:

Exposure of Logged-In User Information via Iframe Embedding

An additional issue related to iframe embedding allowed attackers to identify visiting users’ email addresses and profile data through a hidden Threadit post embedded on their own websites.

Mechanics of the Leak

• If a user is logged into Threadit and visits the attacker’s site with an invisible iframe of a Threadit post, their session automatically registers in the post’s viewer list.
• Attackers can then send API requests to retrieve the viewer list and extract the logged-in user’s details.

This form of cross-site information leakage exploits insufficient cross-origin protections and misuse of session information.

Outcome and Mitigation

Although marked as “Intended Behavior” by Threadit’s team, the threat highlights the importance of frame options to block unauthorized embedding.

• Implementation of X-Frame-Options: DENY prevented embedding, mitigating this against stealth attacks.
• Future designs should consider privacy implications of automatically logging and exposing viewer data.
• Users should be cautious about which sites they visit when logged in to avoid inadvertent data leaks.

Key dates:

Additional Notes: Threadit Chrome Extension XSS Vulnerability

Beyond the web app itself, the Threadit Chrome extension integrated Threadit functionality seamlessly with platforms like Gmail. The extension was similarly vulnerable to a DOM-based XSS via postMessage attack, enabling script execution within Gmail if the extension was installed.

This type of extension vulnerability highlights the ongoing risks of browser extensions handling inter-process messaging incorrectly.

Further analysis of the extension’s security issues will be released in a subsequent article.

Conclusion

The exploration of Google’s Threadit uncovers multiple significant vulnerabilities including DOM XSS, clickjacking, improper ACL controls, and privacy leaks. These findings underscore the complexity and critical importance of robust web security practices, especially in collaboration and communication platforms that handle sensitive user data.

Implementing foundational web security controls such as strict input validation, proper access management, frame-ancestors policies, and robust API authorization are essential to protect users from these attack vectors.

Such vulnerabilities, even in tools backed by industry leaders like Google, reflect the continuous challenge developers face ensuring security in evolving digital collaboration ecosystems.