AWS Chalice意外行为

Question

我正在编写一个Chalice部署，并且体验了我无法解释的行为。

我的根端点接受PUT请求，并验证一些基本的授权凭证。

from chalice import Chalice
from base64 import b64decode

app = Chalice(app_name='test-basic-auth-issue')

@app.route('/', methods=['PUT'])
def index():
    auth = app.current_request.headers['Authorization'].split()

    username, password = b64decode(auth[1]).split(':')

    if username == 'test-user' and password == 'test-password':
        return {username: password}

    else:
        raise Exception('Unauthorized')

使用curl与此API进行接口：

curl https://test-user:test-password@<API-URL>/dev/ --upload-file test.txt

我得到以下答复：

{"message":"Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter. Authorization header requires 'SignedHeaders' parameter. Authorization header requires existence of either a 'X-Amz-Date' or a 'Date' header. Authorization=Basic dGVzdC11c2VyOnRlc3QtcGFzc3dvcmQ="}

但是-当在URL中包含任何参数时：

curl https://test-user:test-password@<API-URL>/dev/?ANYTHING --upload-file test.txt

我得到了以下预期的回应：

{"test-user": "test-password"}

我不知道为什么指定参数会影响授权。

Answer 1

我没有内部信息，所以我无法知道以下内容是否真的正确，但这似乎是对你所看到的行为的合理解释。

AWS通常支持两种提供凭据的替代方法： header.。

对于检查Authorization:头的堆栈中的层，您的值似乎是错误的，因此它们会抛出一个错误，因为您提供的凭据格式不正确.

...unless它在URI中看到一个查询字符串..。在这种情况下，它可以选择允许请求继续进行，前提是授权可以在该层进行。

因此，请求被传递到另一个层，该层负责查询字符串处理。它不会在查询字符串中找到任何凭据，但它也知道在以前处理标头时没有找到凭据，因此如果允许的话，请求将作为匿名请求处理。

因此，您正在滑过一个洞:通过添加查询字符串、任意查询字符串，可以防止Authorization:标头抛出错误。

据我估计，这不是一个安全漏洞，而是URI中的某些内容改变了头的解释方式的情况--特别是，一个格式错误的(就其目的而言)授权标头是否会触发异常或允许通过。

我认为有一个合理的理由将这种行为称为“破坏”，但同时我怀疑它可能不在API Gateway开发人员的手中，他们正在开发一个未命名的前端组件，这是多个AWS服务所共有的。API是AWS生态系统中的一个例外，因为客户可以定义如何操作头.因此，这很可能只是一个平台限制。

我不同意@LorenzodeLara关于API网关不符合RFC-7235的说法--在一定程度上和技术上不同。没有要求服务器使用WWW-Authenticate: (来自RFC)进行响应：

在接收到对被保护资源的请求时，该资源省略凭据，包含无效凭据(例如，错误密码)或部分凭据(例如，当认证方案需要多个往返时)，源服务器SHOULD发送包含WWW的401(未经授权)响应，该响应包含WWW-使用至少一个(可能是新的)可应用于所请求资源的挑战来验证头字段。

RFCs中的单词SHOULD和RECOMMENDED表示可能存在有效异常的期望行为。它们不是强制性的要求。

另一方面，API网关完全不支持从其角度使用HTTP basic auth对请求进行身份验证，这是完全准确的。但是，您只是试图让它将这些凭据传递到运行在内部的代码，这看起来确实有效，因为您的用户代理提交凭据而不存在任何挑战.假设您通过添加查询字符串来防止前端系统阻碍您的工作。

这是我的分析，如果有人能够获得更权威的信息，就可以加以纠正。从这个角度看，使用基本的方法可能不是最好的计划，因为它似乎是偶然的。

我不想得出这个结论。Basic的说唱很糟糕，与HTTPS相结合并不是完全值得的--与请求签名不同，它通常“只是有效”，甚至对于一个不理解GET和POST之间区别的用户来说也是如此，更不用说如何生成一个十六进制编码的HMAC摘要了。