Есть ли недостаток в том, чтобы всегда возвращать Access-Control-Allow-Credentials?

Question

Странный вопрос CORS...

У меня есть код на моем сервере example.co m, который возвращает заголовок ответа Access-Control-Allow-Origin для всех запросов POST & GET, где передается заголовок запроса Origin, и он имеет значение субдомена example.com (супермен.example.com, batman.example.com и т. д.).

Теперь мне нужно иметь возможность совершать вызовы AJAX, передавая файлы cookie, поэтому мне нужно иметь возможность возвращать заголовок ответа Access-Control-Allow-Credentials, если запрос включает файлы cookie.

Я мог бы добавить дополнительную проверку для возврата заголовка ответа Access-Control-Allow-Credentials, если я вижу заголовок запроса Cookie, но для простоты мне интересно, есть ли недостаток в том, чтобы всегда возвращать Access-Control-Allow-Credentials заголовок ответа для всех запросов GET/POST от моих поддоменов, где указан заголовок запроса источника.

Вот мой код (это 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

Если принять во внимание глубокоэшелонированную защиту , безоговорочно включающую

      Access-Control-Allow-Credentials: true

в ответах - плохая идея. Ваше приложение действительно может быть уязвимо для внедрения HTTP-заголовков . Представьте себе ситуацию, когда злоумышленник может внедрить — возможно, через параметр запроса в URL-адресе — ровно один произвольный HTTP-заголовок в ответе. В этом случае злоумышленник сможет заставить ответы содержать следующие заголовки:

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

что оставило бы контент широко открытым для атак из разных источников со стороны https://attacker.com.

Джеймс Кеттл упоминает нечто подобное в своем выступлении на AppSecUSA 2016, озаглавленном « Использование неправильных конфигураций CORS для биткойнов и вознаграждений»:

Довольно часто встречаются классические уязвимости HTTP-внедрения заголовков, когда по какой-либо причине вы не можете внедрить содержимое ответа. Вы не можете просто внедрить вредоносный HTML; единственное, что вы можете сделать, это установить заголовки HTTP. И CORS предлагает блестящий способ использовать это, потому что вы можете просто сказать

Этот контент открыт для всех!

с помощью CORS, после чего злоумышленники могут [...]