AWS Serverless Lambda незашифрованный символ - PullRequest
Новая
       7

AWS Serverless Lambda незашифрованный символ

0 голосов
/ 31 мая 2018

У меня есть простая серверная функция на aws lambda

Команда QA решила создать запрос curl для тестирования с символом «^», когда он не закодирован, то есть: 

curl -X GET   'https://lambda.com/call?id=inva^lid'

поэтому этот вызов даже не доходит до моего кода, поскольку ничего не возвращает.Пусто, нет.

Есть идеи, как это решить?на лямбду?ApiGateway?CloudFront?

Любая идея будет отличной!

Спасибо!

подробный запрос завитка: 

*   Trying 54.230.159.190...
* TCP_NODELAY set
* Connected to example.com (1.1.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):


* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.example.com
*  start date: Feb 26 00:00:00 2018 GMT
*  expire date: Mar 26 12:00:00 2019 GMT
*  subjectAltName: host "example.com" matched cert's "example.com"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb1cc00a400)
> GET /call?id=inva^lid HTTP/2
> Host: example.com
> User-Agent: curl/7.54.0
> Accept: application/json
> Cache-Control: no-cache
> Postman-Token: b730c1f2-b8ab-4eeb-b097-99f7d812434a
> api-key: xxxxxxxxxxxxxxxxxxxxxx
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 400
< content-length: 0
< date: Thu, 31 May 2018 12:38:54 GMT
< x-cache: Error from cloudfront
< via: 1.1 xxxxxx.cloudfront.net (CloudFront)
< x-amz-cf-id: -Kn-xxxxxx==
<
* Connection #0 to host example.com left intact

и теперь я вижу это в журнале "Ошибка отcloudfront "

так есть идеи, как решить эту проблему?

теперь тот же вызов с --http1.1

*   Trying 1.1.1.1...
* TCP_NODELAY set
* Connected to example.com (1.1.1.1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=*.example.com
*  start date: Feb 26 00:00:00 2018 GMT
*  expire date: Mar 26 12:00:00 2019 GMT
*  subjectAltName: host "example.com" matched cert's "example.com"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET /call?id==inva^lid HTTP/1.1
> Host: example.com
> User-Agent: curl/7.54.0
> Accept: application/json
> Cache-Control: no-cache
> Postman-Token: b730c1f2-b8ab-4eeb-b097-99f7d812434a
> api-key: xxxxxxxxx
>
< HTTP/1.1 400 Bad Request
< Content-Length: 0
< Connection: keep-alive
< Date: Thu, 31 May 2018 14:37:26 GMT
< X-Cache: Error from cloudfront
< Via: 1.1 xxxxxxx.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: xxxxxxxxx-J60xxc0TI4MOjQ==
<
* Connection #0 to host example.com left intact

1 Ответ

0 голосов
/ 31 мая 2018

Вы можете игнорировать любое конкретное значение X-Cache: Error from CloudFront, потому что это стандартный заголовок, добавляемый CloudFront к любому обрабатываемому запросу, где код ответа HTTP> = 400. Инфраструктура CloudFront обрабатывает транспортировку запросов для некоторых других служб.включая конечные точки API Gateway Edge-Optimized и ускорение передачи S3 (и вы можете сгенерировать тот же заголовок, пытаясь создать ускоренное соединение с сегментом, в котором не включена функция ускорения передачи).По сути, это означает, что «CloudFront обработал этот запрос, и что-то не сработало» - но это не дает подсказки относительно того, что именно, потому что ошибка могла быть внутренней или внешней по отношению к CloudFront, и этот заголовок будет присутствовать.в обоих случаях.

Чтобы сузить это, я провел дополнительное тестирование.Как оказалось, у CloudFront нет проблем с символом ^ в параметре строки запроса.Подтвержденный дистрибутивом CloudFront и пользовательским источником, этот символ в этой позиции не является проблемой.

Но API Gateway блокирует его.

Подтвердил это с помощью региональной конечной точки API (которая не 'т. е. CloudFront для транспорта), API Gateway блокирует ^ и возвращает ... почти ничего. 

< HTTP/1.1 400 Bad Request
< Date: Thu, 31 May 2018 15:54:59 GMT
< Content-Length: 0
< Connection: keep-alive
<

Есть документированный случай чего-то подобного ...

Символ простой текстовой трубы (|) не поддерживается ни для одной строки запроса URL-адреса запроса и должен быть закодирован в URL-адресе.

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html

Вставка символа неэкранированной трубы вСтрока запроса запускает точно такое же поведение, поэтому это кажется ограничением в API Gateway - он отклоняет этот символ и называет его «Плохой запрос», что означает, что запрос клиента искажен.

Похоже, чтоУ API Gateway та же проблема, что и у ^.

. В обоих случаях отклонение происходит настолько рано в инфраструктуре API Gateway, что не только ваш код нене вижу ... это так рано, что запрос даже не поступает в журналы CloudWatch для конечной точки API.

Исходя из этого, возможно , что он может даже не рассчитывать на ваши пределы регулирования , поскольку API-шлюз мог прекратить синтаксический анализ запроса, прежде чем он даже связал его с вашимAPI, в частности .

Если вы укажете ^ как %5E, то у API Gateway нет проблем.На самом деле, он даже правильно декодирует его и показывает значение в журналах: 

Method request query string: {id==inva^lid}

Так что я бы сказал, что ваша команда QA обнаружила проблему с API Gateway - вам нужно будет url-escapeсимвол ^ в строках запроса.Но он возвращает правильный код ошибки HTTP ... просто нет тела ответа.

...