fix(x): harden CRC challenge token validation - #775
Merged
Conversation
The CRC challenge endpoint returned an HMAC over any caller-supplied `crc_token`, sharing the same construction and secret as POST webhook signature verification. A caller could have an arbitrary webhook body signed via the public GET challenge and replay the response as `x-twitter-webhooks-signature` on a forged POST. Reject any `crc_token` outside X's opaque token shape before signing. A webhook event body is JSON and can never match, so a CRC response can no longer double as a POST event signature. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Accept both base64 and base64url alphabets so a legitimate token is never rejected, and trim the comments. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dnukumamras
changed the title
dancer
approved these changes
Aug 3, 2026
bensabic
pushed a commit
that referenced
this pull request
Aug 4, 2026
Follow-up and hardening for two inbound parsers. - **Teams** — HTML-to-text conversion now strips tags until the output is stable, so nested or malformed markup can't leave a partial tag behind. A shared `stripHtmlTags` helper backs both the format converter and the Graph message converter (was three inline single-pass regexes). - **Slack** — the link-unfurl fallback bounds the length of bracketed URLs parsed from message text, avoiding a quadratic scan on adversarial input. Valid links are unaffected. Two changesets (`@chat-adapter/teams`, `@chat-adapter/slack`); no public-type change. Independent of #774/#775.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up hardening for the X webhook CRC challenge.
The CRC challenge endpoint returned an HMAC over any caller-supplied
crc_token, using the same construction and secret as POST webhook signature verification. That let a caller have an arbitrary body signed via the public GET challenge and replay the response asx-twitter-webhooks-signatureon a forged POST.crc_tokenis now restricted to X's opaque token shape before signing. A webhook event body is JSON and can never match, so a CRC response can no longer double as a POST event signature. Both base64 and base64url alphabets are accepted so a legitimate token is never rejected.verifySignatureis unchanged.Regression tests: a webhook-shaped
crc_tokenis rejected with 400 and noresponse_token; a signature the challenge can produce (for a valid token) verifies only against a body equal to that token, which is not event JSON, so no handler is dispatched. 216 adapter-x tests pass.