始终返回 Access-Control-Allow-Credentials 是否有缺点？

Question

一个奇怪的 CORS 问题...

我的example.com服务器中有代码，它为所有 POST 和 GET 请求返回 Access-Control-Allow-Origin 响应标头，其中传递了 Origin 请求标头，并且它具有 example.com 子域的值（superman .example.com、batman.example.com等）。

我现在需要能够进行 AJAX 调用并传递 cookie，因此如果请求包含 cookie，我需要能够返回Access-Control-Allow-Credentials响应标头。

如果我看到 Cookie 请求标头，我可以添加额外的检查以返回 Access-Control-Allow-Credentials 响应标头，但为了简单起见，我想知道始终返回 Access-Control-Allow-Credentials是否有任何缺点来自我的子域的所有 GET/POST 请求的响应标头，其中指定了 Origin 请求标头。

这是我的代码（它是 Tcl iRule，FWIW）：

when HTTP_REQUEST priority 200 {
    if { ( [HTTP::method] equals "OPTIONS" ) and
         ( [HTTP::host] ends_with "example.com"] ) and
         ( [HTTP::header exists "Access-Control-Request-Method"]) } {
        HTTP::respond 200 "Access-Control-Allow-Origin" [HTTP::header "Origin"] \
                          "Access-Control-Allow-Methods" "POST, GET, OPTIONS" \
                          "Access-Control-Allow-Headers" [HTTP::header "Access-Control-Request-Headers"] \
                          "Access-Control-Max-Age" "86400"       
    } elseif { ( [HTTP::host] ends_with "example.com"] ) and
               ( [HTTP::header exists "Origin"]) } {
        # CORS GET/POST requests - set cors_origin variable
        set cors_origin [HTTP::header "Origin"]
    }
}
when HTTP_RESPONSE {
    # CORS GET/POST response - check cors_origin variable set in request
    if { [info exists cors_origin] } {
        HTTP::header insert "Access-Control-Allow-Origin" $cors_origin
        HTTP::header insert "Access-Control-Allow-Credentials" "true"
    }
}

我知道，如果我返回 Access-Control-Allow-Credentials 响应标头，我必须指定一个命名（非通用）Access-Control-Allow-Origin 标头（并且可能存在 Vary 标头问题），但是是否存在还有什么我需要注意的吗？

Answer 1

如果考虑纵深防御的话，无条件包括

\n

Access-Control-Allow-Credentials: true\n

\n

在回应中是一个坏主意。您的应用程序确实可能容易受到HTTP 标头注入的攻击。想象一下这样一种情况，攻击者能够通过 URL 中的查询参数注入 xe2x80x94 响应中的任意一个 HTTP 标头。在这种情况下，攻击者实际上能够强制响应包含以下标头，

\n

Access-Control-Allow-Origin: https://attacker.com\nAccess-Control-Allow-Credentials: true\n

\n

这将使内容容易受到来自 的跨源攻击https://attacker.com。

\n

James Kettle 在他的 AppSecUSA 2016 演讲中提到了类似的内容，题为“利用比特币和赏金的 CORS 错误配置”：

\n

\n

发现经典的 HTTP 标头注入漏洞很常见，无论出于何种原因，您都无法注入响应内容。您不能只是注入恶意 HTML；您唯一能做的就是设置 HTTP\n标头。CORS 提供了一种利用这一点的绝妙方法，因为你可以说

\n

\n

此内容向所有人开放！

\n

\n

使用 CORS，然后攻击者可以掌握该 [...]

\n

\n