Политика S3 CORS для общего сегмента

Question

Кажется, это легко, но я не знаю, чего мне не хватает. У меня есть общедоступная корзина со скриптом js, которую я получаю с моего веб-сайта. Я заметил, что я не отправляю заголовок Origin на S3, он не требуется, и все работает без каких-либо настроек CORS.

Более того, даже после того, как я вручную добавил заголовок Origin к этому вызову GET и явно запретил GET и мой домен через:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://www.nonexistingdomain.com</AllowedOrigin>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Я все еще могу получить контент. Что здесь происходит?

Answer 1

Хорошо, после разговора с Квентином, я думаю, я понимаю, где я неправильно понимаю, как должен работать CORS. В мире Java очень распространенная практика - отклонять запросы, когда Origin не совпадает. Вот еще одна тема, где упоминается . Если мы возьмем Spring в качестве примера (который является де-факто стандартом в мире Java), вот что происходит, когда добавляется фильтр CORS:

    String allowOrigin = checkOrigin(config, requestOrigin);
    ...

    if (allowOrigin == null) {
        logger.debug("Reject: '" + requestOrigin + "' origin is not allowed");
        rejectRequest(response);
        return false;
    }

где:

/**
 * Invoked when one of the CORS checks failed.
 */
protected void rejectRequest(ServerHttpResponse response) {
    response.setStatusCode(HttpStatus.FORBIDDEN);
}

Вы можете найти код здесь .

Но, к моему удивлению, это не такая распространенная практика с другими стеками и серверными технологиями. Другим распространенным подходом было бы отправить любую конфигурацию CORS, которую они имеют, в браузер и оставить решение за ним.

S3 еще более сложен: он отправляет заголовки ответа CORS только тогда, когда правила CORS сегмента соответствуют запросу с поддержкой CORS (запрос qith заголовок Origin). В противном случае не было бы заголовков ответа CORS.

Answer 2

Такая же политика происхождения - это функция, поддерживаемая браузерами , которая запрещает JavaScript, работающему на одном веб-сайте, читать данные с другого веб-сайта. (Это останавливает случайные веб-сайты, использующие JavaScript, чтобы ваш браузер пропускал корпоративный брандмауэр и получал доступ к вашей внутренней сети или читал ваш GMail с помощью файлов cookie).

CORS позволяет веб-сайту расслабиться той же Политике происхождения, что позволяет другим веб-сайтам считывать данные с него таким образом.

CORS не является аутентификацией / авторизацией. Ваш общедоступный сегмент - public .

Вы не используете JavaScript для чтения данных из своего контейнера, вы загружаете JS непосредственно из контейнера.

Answer 3

Давайте разберем проблему и попытаемся понять основы CORS.

Что такое запрос перекрестного происхождения и CORS?

Запрос перекрестного происхождения: запрос наРесурс (например, изображение или шрифт) за пределами источника известен как запрос перекрестного источника.

CORS полезен, когда вы запрашиваете защищенный ресурс из другого источника.

Совместное использование запроса между источниками. Запрос ресурса защищенный (например, изображения, шрифта или XHR-запроса) за пределами источника называется перекрестным источником.request.

Зачем нам CORS, если ресурсы можно защитить с помощью токенов аутентификации / авторизации?

CORS - это первая линия защиты.Когда и клиент (например, браузеры), и серверы поддерживают CORS, клиенты будут разрешать только запросы от определенных источников к серверам в соответствии с инструкциями серверов.

По умолчанию в браузерах должен быть реализован механизм безопасности политики одного и того же происхождения в соответствии с рекомендациями по созданию браузера.Почти все современные браузеры реализуют политику одного и того же источника, которая инструктирует браузеры разрешать запросы к серверам, если источник один и тот же.

Политика одного и того же источника - это механизм безопасности браузера, вы можете прочитать больше оэто здесь .Именно из-за этой функции браузеров браузер блокирует все запросы, когда источник обозначения и источник источника различаются.(Серверы даже не осознают, что это происходит, вау!)

Для более простых случаев использования, когда ресурсы (js, CSS, изображения, шрифты), ресурсы XHR доступны с тем же источником, нетнужно беспокоиться о CORS.

Если ресурсы размещены на другом источнике или ресурс XHR размещен на серверах с другим доменом, отличным от исходного, браузеры по умолчанию не отклонят запрос на перекрестное происхождение.Только с соответствующими заголовками запросов и ответов CORS браузерам разрешается делать запросы с разными источниками.

Давайте рассмотрим заголовки запросов и ответов.

Заголовки запросов

• Происхождение
• Метод контроля доступа-запроса
• Заголовки запроса-контроля доступа

Заголовки ответа

• Контроль доступа-Разрешить происхождение
• Контроль доступа-Разрешить-учетные данные
• Доступ-Control-Expose-Headers
• Access-Control-Max-Age
• Access-Control-Allow-Методы Access-Control-Allow-Headers

Для настройкиCORS нужны заголовки Origin и Access-Control-Allow-Origin.Браузеры автоматически добавляют заголовок Origin к каждому запросу, поэтому разработчику необходимо настроить только заголовок ответа Access-Control-Allow-Origin.

Для защиты доступа к ресурсам только из определенных доменов S3 предоставляет возможность настройки правил CORS.Если значение заголовка Access-Control-Allow-Origin равно *, разрешены все запросы кросс-источников, или же задайте список доменов через запятую.

Есть пара вещей, о которых вам нужно знатьпри использовании CORS.

• Это первый уровень защиты защищаемого ресурса, а не окончательная защита.
• Вам все еще необходимо внедрить соответствующую аутентификацию и авторизацию для ресурса для выполнения операций CRUD на сервере..
• Реализация одной и той же политики происхождения является руководством для построения браузера и не является обязательной.
• Заголовки CORS полезны только тогда, когда клиенты принимают заголовки.Только современные браузеры принимают заголовки CORS.Если вы не используете браузеры для запроса ресурсов, то CROS не применяются.
• Если вы введете ссылку в адресной строке браузера, правила CORS не будут применяться, поскольку браузер не отправляет заголовок Origin на сервер.Заголовок Origin отправляется браузером только на последующий запрос ресурса (таблицы стилей, файлы js, шрифты) и запросы XHR источником.
  • Если вы обращаетесь к файлу ресурса, непосредственно набрав ссылку в адресной строке, браузер не отправляет заголовок Origin на этот запрос.

Также, еслиВы хотите ограничить доступ GET, используя предварительно подписанный URL-адрес S3 в приватной корзине.