Description
The Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio POSTs to an application's webhook endpoint. Its doParse(Request $request, #[\SensitiveParameter] string $secret) method receives the configured webhook secret but never reads it; it decodes and returns the payload unconditionally, ignoring the X-Twilio-Signature HMAC header Twilio sends with each request.
As a result, an application that wires up the Twilio webhook endpoint accepts any POST to that URL, even when a signing secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged status payloads, fake delivered / failed / undelivered events, leading to delivery-metrics fraud, downstream automation triggers, etc.
Resolution
TwilioRequestParser::doParse() now requires and verifies the X-Twilio-Signature header (HMAC-SHA1 over the full request URL concatenated with the alphabetically-sorted POST parameters, base64-encoded, keyed with the Twilio account auth token) before further processing, using a constant-time comparison.
When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.
Applications behind a TLS-terminating reverse proxy must configure framework.trusted_proxies and framework.trusted_headers so that Request::getUri() returns the public URL Twilio signed.
The patch for this issue is available here for branch 6.4.
Credits
We would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.
nicolas-grekas Remediation developer
Description
The Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio POSTs to an application's webhook endpoint. Its
doParse(Request $request, #[\SensitiveParameter] string $secret)method receives the configured webhook secret but never reads it; it decodes and returns the payload unconditionally, ignoring theX-Twilio-SignatureHMAC header Twilio sends with each request.As a result, an application that wires up the Twilio webhook endpoint accepts any POST to that URL, even when a signing secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged status payloads, fake delivered / failed / undelivered events, leading to delivery-metrics fraud, downstream automation triggers, etc.
Resolution
TwilioRequestParser::doParse()now requires and verifies theX-Twilio-Signatureheader (HMAC-SHA1 over the full request URL concatenated with the alphabetically-sorted POST parameters, base64-encoded, keyed with the Twilio account auth token) before further processing, using a constant-time comparison.When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.
Applications behind a TLS-terminating reverse proxy must configure
framework.trusted_proxiesandframework.trusted_headersso thatRequest::getUri()returns the public URL Twilio signed.The patch for this issue is available here for branch 6.4.
Credits
We would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.