fix: X-Twilio-Signature validation when URL query parameters contain @ or : #621
Conversation
This file contains 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
|
Hello @adamj9431, Thank you for taking the time to share your fix! Could you please check the box next to "I acknowledge that all my contributions will be made under the project's license" that I've just added to the description? With best regards, Elmer |
thinkingserious
added
status: cla not signed
status: code review request
childish-sambino
changed the title
|
@thinkingserious done |
childish-sambino
removed
status: cla not signed
status: waiting for feedback
childish-sambino
approved these changes
Nov 5, 2020
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
X-Twilio-Signature validation appears to be broken in cases when Twilio sends query parameters containing
@or:. This affects SIP calls since GET calls (e.g. audio URLs) end up containing query parameters that look like...&Caller=sip%3A1234567890%40209.182.172.181&...It seems the signature header is calculated on the Twilio side without percent-escaping
@or:, but the actual request is then made by Twilio's infrastructure with those characters escaped.This PR fixes the issue for me, but the other (potentially more robust) fix is to ensure that Twilio infrastructure calculates the signature on the actual query string that is sent to the server after any escaping has occurred.
Note that, per RFC 3986
@and:do not need to be escaped in the query portion of the URI. They do need to be escaped in other parts of the URI, though. Go figure.