[BUG] Slack attachment download has no host allowlist (Discord's downloader does)

[larsspinetta12]

Summary

gateway/slack/attachments.py downloads Slack files with follow_redirects=True
and no host allowlist, so the bot token is sent to whatever host url_private
names. Discord's downloader (gateway/discord/attachments.py) rejects non-Discord
hosts before the request. Slack should have the same check.

Scope correction from the original report: the bot token does not leak across
a redirect. httpx strips the Authorization header whenever a redirect leaves the
origin (_client.py::_redirect_headers, present in the pinned httpx>=0.27); the
only exception is a same-host http→https upgrade, and url_private is already
https. The original "observe the Bearer header is re-sent to the redirect target"
step does not reproduce, and the original "Done when" was already satisfied by the
library. What is missing is the host check itself.

This is defense in depth, not a live exploit — see the threat model below.

Expected vs actual behavior

Expected: reject a url_private whose host is not a known Slack file host
before sending the bearer token, and re-check the host on every redirect hop.

Actual: download_file (L106–114) sends Authorization: Bearer {token} to
whatever host url_private names, with follow_redirects=True and no allowlist.

Steps to reproduce

1. Build a SlackInboundFile whose url_private points at a non-Slack host.
2. Call download_file(file, token).
3. The request goes out. Nothing rejects the host.

There is no user-facing repro — the threat model below explains why.

Can you reproduce it consistently?

Yes

How often does it occur?

Under specific conditions (only reachable if url_private is ever attacker-influenced,
which it is not today)

Operating system

Other (server/gateway)

Additional context

Threat model — why this is hardening, not an incident.

The Slack gateway runs over Socket Mode (gateway/slack/socket_mode_worker.py).
There is no HTTP Slack events route in gateway/http/, so url_private arrives
only over Slack's authenticated WebSocket and is minted by Slack, not by the
message sender. An external attacker cannot set it as the code stands.

The check is worth adding anyway because it guards the invariant if an HTTP Events
API route is added later, if the files.info fallback noted in
gateway/slack/events.py L118 starts supplying the URL, or if httpx changes its
redirect handling. It also closes a second-order gap that stripping Authorization
does not: a redirect chain currently lets the gateway issue outbound GETs to
arbitrary hosts, and the response body is decoded and inlined into the model turn
(extract_text → _budgeted_section).

Implementation note — do not just copy Discord.

Discord sets follow_redirects=False. Slack cannot: url_private legitimately
307/308-redirects to the file CDN, so disabling redirects breaks every download.
The Slack fix needs a manual hop loop — follow_redirects=False, then re-request
the Location only when its host passes the allowlist, bounded to a few hops.

• Add SLACK_ATTACHMENT_HOST_SUFFIXES to config/constants/slack.py, mirroring
  DISCORD_ATTACHMENT_HOST_SUFFIXES in config/constants/discord.py.
• Reuse the shape of is_allowed_attachment_url (https-only, exact host or
  dot-suffix match).
• Confirm the current documented Slack file hosts before pinning the tuple;
  files.slack.com is the one in use today.
• Keep the existing 10s timeout and the 256 KiB _MAX_FILE_BYTES cap.

Tests:

• non-allowlisted initial host → no request issued, None returned
• allowlisted host that redirects to a non-allowlisted host → chain stops, None
• allowlisted host redirecting within the allowlist → bytes returned, cap still enforced
• hop limit → a redirect loop terminates

Done when: download_file will not send the bot token to a host outside the
Slack file-host allowlist, on the initial request or on any redirect hop.

[DevSars24]

Hey @Davidson3556, I'd like on this issue.
Could you please assign this to me? Thanks!

[sanskar-singh-2403]

hey @larsspinetta12 Can i pick this up?

I traced the current code to ground the fix. One note first: the paths in the
issue have shifted since the "package by surface" refactor (#4768). The Slack
downloader now lives at gateway/transports/slack/attachments.py (the
download_file function), and the Discord reference is at
gateway/transports/discord/attachments.py. The bug is unchanged, just relocated.

The Slack download_file currently does:

with httpx.stream(
    "GET",
    file.url_private,
    headers={"Authorization": f"Bearer {token}"},
    follow_redirects=True,
    timeout=_DOWNLOAD_TIMEOUT_SECONDS,
) as response:

so a url_private that redirects off Slack re-sends Authorization: Bearer <bot token>
to the redirect target, with no host allowlist. Discord's _download already does
this correctly (is_allowed_attachment_url + follow_redirects=False).

Plan, mirroring Discord's intent:

• Add a SLACK_ATTACHMENT_HOST_SUFFIXES constant (files.slack.com plus the
  currently documented Slack file hosts) alongside the existing Discord constant.
• Add an is_allowed_attachment_url-style guard and reject non-allowlisted /
  non-https hosts before the request.
• Set follow_redirects=False so a redirect off Slack cannot carry the bearer token.
• Keep the existing 256 KiB byte cap and the download timeout as-is.
• Tests (extending gateway/tests/slack/test_attachments.py): a redirect to a
  non-allowlisted host must not send the Bearer header and returns None; the
  happy-path Slack host still downloads within the cap.

One decision for you: do you want the strict allowlist approach (reject the
non-Slack host outright, matching Discord), or the softer "strip Authorization on
cross-host redirects" variant the issue mentions as an alternative? I'll go with
the allowlist to stay consistent with Discord unless you'd prefer otherwise.

Happy to open a draft PR early for direction.

[AniketR10]

@muddlebee @larsspinetta12 would like to work on this

[Davidson3556]

Re-scoped the title and body. Recording why here so the change isn't silent.

The original premise was that the bearer token rides the redirect off Slack. It doesn't. httpx already drops Authorization when a redirect leaves the origin — _client.py::_redirect_headers in the pinned httpx>=0.27:

if not _same_origin(url, request.url):
    if not _is_https_redirect(request.url, url):
        headers.pop("Authorization", None)

The one carve-out is a same-host http→https upgrade, and url_private is https already. So step 2 of the old repro doesn't reproduce, and the old "Done when" was true before the issue was filed.

The missing host allowlist is still real, so the fix survives — the justification changes. Also worth flagging for whoever picks it up: Slack's url_private legitimately 307/308-redirects, so copying Discord's follow_redirects=False breaks downloads outright. It needs a manual hop loop with a per-hop host check.

Nothing here is attacker-reachable today: the gateway is Socket Mode only, so url_private comes from Slack, not from the message sender. I'd drop the security label for that reason — happy to leave it if you'd rather keep it visible during triage.

Taking this one along with #4770.