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 API通常支持两种提供凭据的备选方案：query string parameters, or the Authorization: header.。

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

...除非它在URI中看到一个查询字符串...在这种情况下，它可以选择允许请求继续进行，假设授权可能在该层完成。

因此请求被移交给另一个层，该层负责查询字符串处理。它在查询字符串中找不到任何凭据，但它也知道在处理标头时未找到任何凭据，因此请求将作为匿名请求处理（如果允许的话）。

所以，你正在滑倒漏洞：通过添加查询字符串，任何查询字符串，可以防止Authorization:标头抛出错误。

在我的估计中，这不是一个安全漏洞，而是URI中的某些内容会更改标头的解释方式 - 具体而言，是否格式错误（用于其目的）授权标头会触发异常或被允许通过

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

我不同意 - 部分和技术性 - 与@ LorenzodeLara断言API网关不符合RFC-7235。服务器不需要使用WWW-Authenticate: - 来自RFC：

在收到对省略凭证的受保护资源的请求时，包含无效凭证（例如，密码错误）或部分凭证（例如，当认证方案需要多次往返时），原始服务器{{1发送一个401（未授权）响应，其中包含WWW-Authenticate头字段，其中至少有一个（可能是新的）挑战适用于所请求的资源。

RFC中的SHOULD和SHOULD字符表示可能存在有效异常的所需行为。它们不是强制性要求。

另一方面，完全准确的是，API网关完全不支持从HTTP 使用HTTP基本身份验证来验证请求 ...但是你是只是尝试让它将这些凭据传递给内部运行的代码，这看起来确实有效，因为您的用户代理提交凭证而没有挑战...假设您阻止前端系统阻止您，添加查询字符串。

这是我的分析，需要有权访问更多权威信息的人进行更正。从这个角度来看，使用基本身份验证可能不是最好的计划，因为它看起来似乎是偶然的。

我讨厌得出这个结论。基本的auth得到了一个糟糕的说唱，当与HTTPS结合使用时并不完全值得 - 与请求签名不同，它通常“正常工作”，开箱即用，即使对于不理解{{1 }和RECOMMENDED，更不用说如何生成十六进制编码的HMAC摘要。

AWS Chalice意外行为

1 个答案: