GHSA-pj2x-fjjr-q84c: 
Analyse et atténuation de la vulnérabilité

Summary

Admittedly this would be a pretty convoluted and improbable exploit, but I figured I'd submit via the vuln form just to be safe! It's possible for a signed request for one event to be replayed with an attacker-controlled "payload" smuggled in via the URL and accepted by InteractionCallbackParse since FormValue will fall back to the query params if the key doesn't exist in the body.

Details

An internal AI scanner helped find this, but I've manually validated and written this report by hand In the examples, and as recommended by Slack, signature validation is done with the form body: https://github.com/slack-go/slack/blob/6065d7ddad41ae0fffe26e32a4a9259118df8ba4/examples/parse_action_event/main.go#L148 However, FormValue, used by interaction callback parsing, can fall back to the (unsigned) query param: https://github.com/slack-go/slack/blob/6065d7ddad41ae0fffe26e32a4a9259118df8ba4/interactions.go#L85 Though incredibly unlikely, it's possible to use a signed request for a different event type (which doesn't include payload in its request body), and craft your own interactive payload. The interaction callback parsing should use ParseForm + PostForm instead, similar to SlashCommandParse: https://github.com/slack-go/slack/blob/6065d7ddad41ae0fffe26e32a4a9259118df8ba4/slash.go#L31 Interaction payloads are always sent in the HTTP POST, not in query params, so this should be compatible. I've already drafted a fix here: https://github.com/slack-go/slack-ghsa-pj2x-fjjr-q84c/commit/39a28d36df835cf1e3dca49b35589d1644b82b8c

Proof of concept

Set up

1. Configure a Slack app with both interactivity AND (event subscriptions and/or slash commands)
2. Configure your service to validate signatures as documented, and handle both actions e.g. /slack/event and /slack/interactive, using InteractionCallbackParse for /slack/interactive

Attack

1. Capture a valid signed event subscription or slash command request body
2. Replay that request body + signature header, but send it to the interactive event handler, and add a query param ?payload={...} with your own payload

Impact

1. This only affects interaction payloads, with apps that configure both interaction AND (event subscriptions and/or slash commands)
2. This also requires an existing way to sniff signed request (e.g. via bad logging) This is effectively a replay attack that lets you run arbitrary interaction commands rather than just replaying an existing request I'd consider this low likelihood + medium impact.