Go client verification fails if svix-signature header is an array of strings

[arabello]

Bug Report

Version

v0.82.1

Platform

Darwin MacBook-Pro-di-buildo.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

Description

While verifying webhooks inside an AWS lambda, the standard approach to get an http.Request from the lambda's event, creates the svix-signature http.Request.Header by splitting the original signature.

http.Request.Header["svix-signature"] results in an array of two strings

{"v1" "doqUF7tykdkLqUxzXTUyeoc4JIxGtOjt6kDsomething"}

instead of an array of a single string

{"v1,doqUF7tykdkLqUxzXTUyeoc4JIxGtOjt6kDsomething"}

This causes the Verify method to fail as it uses calling the http.Request.Header.Get returns only first value (in this case v1) instead of the two strings array.

I expected this library to support this case as using AWS lambdas is a pretty popular.

I temporary workaround it by overriding the request header

req.Header.Set("Svix-Signature", strings.Join(req.Header["Svix-Signature"], ","))

but I expected the library to internally handle it. For example, inside the verify method there could be a check like:

msgSignature := headers.Get("svix-signature")
if reflect.SliceOf(reflect.TypeOf("")) == reflect.TypeOf(headers["svix-signature"]) {
    msgSignature := strings.Join(headers["svix-signature"], ","))
}

[tasn]

This feels like a bug with the AWS lambda library, as these headers are not defined as comma-separated headers, so they shouldn't be split as such.

What's the behavior in non lambda Go web frameworks? Any idea?

[arabello]

This feels like a bug with the AWS lambda library, as these headers are not defined as comma-separated headers

Yeah, I dug up into it: the API Gateway V2 client is splitting every header considering them as comma separated. Different behavior compared to V1, though.

What's the behavior in non lambda Go web frameworks? Any idea?

I don't have clues on other frameworks

I objectively agree that this is more an issue on the AWS client side as they are treating a custom header as a comma separated one. Actually, they are treating all headers as comma separated.

Thanks anyway, closing this

[tasn]

It's still a concern to be honest, it makes the lives of verifies more difficult if they have to workaround bad implementations. :|

[arabello]

Yeah, here the reference where I'm asking about it: awslabs/aws-lambda-go-api-proxy#171

[tasn]

Let's see what they say. Thanks for the link!