API 게이트웨이 정렬 쿼리 문자열

Question

현재 API 게이트웨이 + 람다에 Serverless 프레임 워크를 사용하여 Express 응용 프로그램을 구현하려고합니다. 우리의 요구 사항 서명을 시작할 때까지 모든 것이 예상대로 작동했습니다. 서명은 비밀 토큰을 사용하여 쿼리 문자열을 포함한 전체 URL에 서명하는 방식으로 작동합니다. 불행히도 API 게이트웨이 나 Cloudfront 중 하나가 쿼리 문자열을 사전 순으로 정렬하여 클라이언트에서 생성 된 것과 다른 측면에서 생성 된 체크섬으로 이어지는 것으로 보입니다.

우리 익스프레스 서버는보고 무엇 :

https://example.com/endpoint?build_number=1&platform=ios

클라이언트가 전송 한 것 :

https://example.com/endpoint?platform=ios &build_number=1

쿼리 매개 변수가 어떤 동작입니다없는 알파벳 순으로 재 분류되었다 볼 수 있듯이 나는 기대할 것이다.

아이디어가 있으십니까?

Answer 1

쿼리 문자열은 내장 주문이없는 키/값 쌍의 집합이므로 문제를 제기 할 수있는 알고리즘을 제안 할 것입니다.

특정 순서로 특정 시스템을 통과 할 것으로 예상해서는 안됩니다. 요청 헤더에 대해서도 마찬가지입니다. HTTP 요청을 빌드하는 일부 라이브러리는 중급 사전/해시 구조에 쿼리 문자열 매개 변수를 저장하므로 여기에서 볼 수있는 문제 (CloudFront claims 이후로 API 게이트웨이로 의심되는 부분) ?color=red&size=large이 최적의 디자인이기 때문에 은 정확히이고, ?size=large&color=red과 똑같은 것을 알 수 있습니다.

내 생각에 API 게이트웨이는 쿼리 문자열 정렬을 표준화하여 캐싱 (실제로 CloudFront 캐시를 사용하지 않음 - 고유 구현이 있음)을 수행하는 기능을 최적화 할 수 있습니다.

그러나 위에서 제안한 것처럼 알고리즘은 보내는 쪽과 같은 것에 대한 쿼리 매개 변수의 이진, 어휘 정렬 (대소 문자를 구분하지 않는 "알파벳"이 아닌 대/소문자를 구분)이 필요합니다. 수신 측에서 다시.

이것은 불필요한 복잡성처럼 보입니다. 그러나 이것은 다양한 AWS 서명 알고리즘이 서명하기 전에 쿼리 문자열 (및 헤더, 동일한 이유로 인해)의 키와 값을 정렬해야하는 이유입니다. 클라이언트 라이브러리, 프록시 또는 다른 엔터티에서 일관되게 처리 할 수 ​​있습니다.