【问题标题】:Solutions to overcoming 494 cloud-front cookie error克服494云端cookie错误的解决方案
【发布时间】:2022-02-02 01:10:38
【问题描述】:

我们正在使用 aws cloudfront 将我们的 Angular Web 应用程序分发到 Web。我们已经进行了此设置和配置,因此我们的 web 应用程序是实时的并且可以访问。但是,由于需要允许跨这些应用程序进行身份验证,我们已经实现了 cookie,其中域设置为核心域,子域使用通配符。例如,我们可能有两个 webapp,一个位于 appone.example.com,另一个位于 apptwo.example.com。两者都通过将 cookie 域设置为 .example.com 来查看跨子域共享的相同 cookie 选择。

现在这个设置效果很好,我们不发送带有 api 请求的 cookie,而是只发送一个身份验证标头,因此那里的标头大小没有问题,我们不需要这些 cookie 进入请求云端。但是,这些请求是由浏览器发起的,因此无法操纵请求以删除问题所在的 cookie 标头。

当我们有相当多的 cookie(大约 30 个)时,有两批 cognito cookie 和一些其他包含信息的信息,以促使 cognito 设置使用 cognito cookie。这意味着请求大小约为 22,000 字节。这超出了 here 规定的 20,480 字节 的限制。如果我的请求低于 20,480 字节,它将成功完成。

现在考虑到我不需要这些 cookie 来访问云端请求,我认为您可以在源请求策略的一部分中或使用查看器请求 Lambda@Edge 函数从标头中删除它们.但是,它似乎还不足以实现此功能。

这是 aws 模板提供的一些示例代码。此 Lambda@Edge 函数不会像上面建议的那样去除标头,但是如果请求小于 20,480 字节,它仍然应该记录事件如果被命中。如果不是,它不会记录...:

exports.handler = async (event, context) => {
    console.log(event);
    /*
     * Generate HTTP response using 200 status code with a simple body.
     */
    const response = {
        status: '200',
        statusDescription: 'OK',
        headers: {
            vary: [{
                key: 'Vary',
                value: '*',
            }],
            'last-modified': [{
                key: 'Last-Modified',
                value: '2017-01-13',
            }],
        },
        body: 'Example body generated by Lambda@Edge function.',
    };

    return response;
};

现在,我想我可以通过删除一组 cognito cookie 和实例化它所涉及的配置 cookie 来缓解这个问题,但这不是理想的情况,因为这意味着每次你在两者之间切换和更改您需要重新登录的系统不是很好,也不适合我们非常专业的用例。 另一种解决方案是删除 cookie 的使用并切换到跨域共享的本地存储。然而,这给 XSS 带来了安全挑战,从最初的研究来看,这似乎是不可行和不可接受的。

因此,总体而言,基于我目前对 aws cloudfront 的有限理解,我的问题变成了是否可以从请求中剥离 cookie 标头,从而允许在没有 494 错误页面的情况下接受请求。在我们的用例中,我们只希望使用 cookie 作为跨域存储的一种方式,因此不需要使用 cookie 来处理静态 js 文件请求。

494 error image link

【问题讨论】:

    标签: amazon-web-services cookies amazon-cognito amazon-cloudfront


    【解决方案1】:

    如果您只是想避免向静态资产发送带有请求的 cookie,请设置不同的域并从那里提供服务。

    但我真的很想知道你在想什么;如果您的 Angular 应用程序可以访问存储为 cookie 的令牌,那么从 XSS 的角度来看,它并不比 localstorage 更安全。

    【讨论】:

      猜你喜欢
      • 2014-08-19
      • 2010-11-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-12-07
      • 2013-08-28
      相关资源
      最近更新 更多