HackerOne #4561 — Stored XSS via Slackbot Messages on Slack

Source: HackerOne Report #4561

Vulnerability Summary

A stored Cross-Site Scripting (XSS) vulnerability in Slack's Slackbot messaging feature allowed the injection of malicious JavaScript that would execute in the browsers of users viewing Slackbot messages.

Technical Details

Slackbot is Slack's automated messaging assistant that can send messages on behalf of applications and integrations. The vulnerability allowed an attacker to:

• Inject HTML/JavaScript content into Slackbot-generated messages
• Have the injected content stored on Slack's servers (stored XSS, not reflected)
• Execute the malicious script in the context of any user's browser who views the message

The XSS payload executed with the origin of the Slack web application, meaning it had access to:

• Cookies (including session tokens, if not HttpOnly)
• Local Storage data
• The ability to make requests to the Slack API on behalf of the victim
• Access to the DOM of the Slack web application

Why Stored XSS Is Particularly Dangerous

Unlike reflected XSS (which requires a victim to click a malicious link), stored XSS:

• Persists: The payload remains on the server and executes every time the content is viewed
• Affects multiple users: Anyone who views the compromised content is affected
• No user interaction needed: Simply viewing the page triggers the exploit
• Higher privilege potential: In application contexts like Slack, stored XSS can lead to account compromise

Impact

• Session hijacking: If session cookies are accessible via JavaScript, attackers can steal sessions
• Data theft: Attackers can read messages, files, and other data visible in the Slack web UI
• Account compromise: Combined with other vectors, XSS can lead to full account takeover
• Malware distribution: XSS can be used to redirect users or deliver malware

Remediation

Slack fixed the vulnerability by implementing proper output encoding and Content Security Policy:

1. All user-controlled content in Slackbot messages is now HTML-encoded before rendering
2. Content Security Policy (CSP) headers restrict script execution sources
3. Input validation rejects obviously malicious content

Lessons for Web Application XSS Defense

• Encode all user-supplied data based on context (HTML, attribute, JavaScript, URL)
• Implement Content Security Policy as a defense-in-depth layer
• Use HttpOnly and Secure flags on session cookies
• Validate input but encode output — output encoding is the primary defense
• Regular security testing including automated XSS scanners and manual review