基于引用来限制对AWS S3存储桶的访问

时间:2017-09-02 05:33:59

标签: amazon-web-services amazon-s3 amazon-cloudfront policy

我正在尝试限制对S3存储桶的访问,并且只允许基于引用者的列表中的某些域。

存储桶策略基本上是:

{
"Version": "2012-10-17",
"Id": "http referer domain lock",
"Statement": [
    {
        "Sid": "Allow get requests originating from specific domains",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::example.com/*",
        "Condition": {
            "StringLike": {
                "aws:Referer":  [ 
                    "*othersite1.com/*",
                    "*othersite2.com/*",
                    "*othersite3.com/*"
                ]
            }
        }
    }
 ]
}

这个otherite1,2和3调用一个对象,我已经存放在域example.com下的s3存储桶中。 我还有一个附加到存储桶的云端分发。我在字符串条件之前和之后使用*通配符。引用者可以是othersite1.com/folder/another-folder/page.html。引用者也可以使用http或https。

我不知道为什么我会收到403 Forbidden错误。

我这样做基本上是因为我不希望其他网站调用该对象。

非常感谢任何帮助。

1 个答案:

答案 0 :(得分:5)

正确的缓存行为是必要的,CloudFront会在将请求转发到源服务器之前从请求中删除几乎所有请求标头。

  

Referer | CloudFront删除标题。

     

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior

因此,如果您的存储桶尝试阻止基于引用页面的请求(有时为防止热链接而执行),S3将不会 - 默认情况下 - 能够看到Referer标头,因为CloudFront没有转发它。

而且,这是为什么 CloudFront无法转发它的非常好的例证。如果CloudFront转发标头然后盲目缓存结果,则存储桶策略是否具有预期效果将取决于第一个请求是来自其中一个目标站点还是来自其他位置 - 而其他请求者将获得缓存响应,可能是错误的响应。

(tl; dr)将Referer标头转发到原点(在CloudFront缓存行为设置中)的白名单解决了这个问题。

但是,有一点问题。

现在您要将Referer标头转发给S3,您已经扩展了缓存密钥 - CloudFront缓存响应的事项列表 - 包括Referer标题。

因此,现在,对于每个对象,除非传入请求的Referer标头与已经缓存的请求中的完全匹配,否则CloudFront不会提供缓存响应。 ..否则请求必须转到S3。而且,关于引用标题,它是引用页面,而不是引用网站,因此来自授权的每个站点将在CloudFront中拥有自己的这些资产的缓存副本。

这本身不是问题。这些额外的对象副本是免费的,这就是CloudFront的设计工作方式......问题是,它降低了给定对象在给定边缘缓存中的可能性,因为每个对象必然会被引用较少。如果您拥有大量流量,那么这一点就变得不那么重要了 - 如果您的流量较小则更为重要。缓存命中率越低意味着页面加载速度越慢,向S3发出的请求越多。

这是否适合您是不正确的答案,因为它非常具体到您使用CloudFront和S3的方式。

但是,这是替代方案:

您可以从标头的白名单中删除Referer标头以转发到S3,并通过配置CloudFront以触发将检查每个请求的Lambda@Edge Viewer Request trigger来撤消对缓存命中产生负面影响的潜在可能性来自前门,并阻止那些不是来自您想要允许的引用页面的请求。

在匹配特定缓存行为之后但在检查实际缓存之前触发查看器请求触发器,并且大多数传入标头仍然完好无损。您可以允许请求继续,可选择进行修改,或者您可以生成响应并取消其余的CloudFront处理。这就是我在下面说明的内容 - 如果Referer标头的主机部分不在可接受值的数组中,我们会生成403响应;否则,请求继续,检查缓存,并且仅在需要时查询原点。

触发此触发器会为每个请求增加少量开销,但这种开销可能会比缓存命中率降低更为可取。所以,以下不是更好的"解决方案 - 只是一种替代解决方案。

这是用Node.js 6.10编写的Lambda函数。

'use strict';

const allow_empty_referer = true;

const allowed_referers = ['example.com', 'example.net'];

exports.handler = (event, context, callback) => {

    // extract the original request, and the headers from the request
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    // find the first referer header if present, and extract its value;
    // then take http[s]://<--this-part-->/only/not/the/path.
    // the || [])[0]) || {'value' : ''} construct is optimizing away some if(){ if(){ if(){ } } } validation

    const referer_host = (((headers.referer || [])[0]) || {'value' : ''})['value'].split('/')[2];

    // compare to the list, and immediately allow the request to proceed through CloudFront 
    // if we find a match

    for(var i = allowed_referers.length; i--;)
    {
        if(referer_host == allowed_referers[i])
        {
            return callback(null,request);
        }
    }

    // also test for no referer header value if we allowed that, above
    // usually, you do want to allow this

    if(allow_empty_referer && referer_host === "")
    {
        return callback(null,request);
    }

    // we did not find a reason to allow the request, so we deny it.

    const response = {
        status: '403',
        statusDescription: 'Forbidden',
        headers: {
            'vary':          [{ key: 'Vary',          value: '*' }], // hint, but not too obvious
            'cache-control': [{ key: 'Cache-Control', value: 'max-age=60' }], // browser-caching timer
            'content-type':  [{ key: 'Content-Type',  value: 'text/plain' }], // can't return binary (yet?)
        },
        body: 'Access Denied\n',
    };

    callback(null, response);
};