Cross-Origin Request Headers(CORS) with PHP headers
I have a simple PHP script that I am attempting a cross-domain CORS request:
Yet I still get the error:
Request header field X-Requested-With is not allowed by Access-Control-Allow-Headers
Anything I’m missing?
11 Answers 11
Handling CORS requests properly is a tad more involved. Here is a function that will respond more fully (and properly).
Security Notes
Check the HTTP_ORIGIN header against a list of approved origins.
If the origin isn’t approved, then you should deny the request.
Please read the spec.
When a browser wants to execute a cross-site request it first confirms that this is okay with a «pre-flight» request to the URL. By allowing CORS you are telling the browser that responses from this URL can be shared with other domains.
CORS does not protect your server. CORS attempts to protect your users by telling browsers what the restrictions should be on sharing responses with other domains. Normally this kind of sharing is utterly forbidden, so CORS is a way to poke a hole in the browser’s normal security policy. These holes should be as small as possible, so always check the HTTP_ORIGIN against some kind of internal list.
There are some dangers here, especially if the data the URL serves up is normally protected. You are effectively allowing browser content that originated on some other server to read (and possibly manipulate) data on your server.
If you are going to use CORS, please read the protocol carefully (it is quite small) and try to understand what you’re doing. A reference URL is given in the code sample for that purpose.
Header security
It has been observed that the HTTP_ORIGIN header is insecure, and that is true. In fact, all HTTP headers are insecure to varying meanings of the term. Unless a header includes a verifiable signature/hmac, or the whole conversation is authenticated via TLS, headers are just «something the browser has told me».
In this case, the browser is saying «an object from domain X wants to get a response from this URL. Is that okay?» The point of CORS is to be able to answer, «yes I’ll allow that».
Небезопасный cross-origin resource sharing
Что такое CORS?
CORS — это механизм безопасности, который позволяет веб-странице из одного домена обращаться к ресурсу с другим доменом (кросс-доменным запросом). Без таких функций, как CORS, веб-сайты ограничиваются доступом к ресурсам одного и того же происхождения через так называемую политику единого происхождения.
Первым шагом в понимании CORS является знание того, как работают некоторые функции безопасности веб-браузеров. По умолчанию веб-браузеры не разрешают AJAX-запросы на сайты, кроме сайта, который вы посещаете. Это называется политикой единого происхождения, и это важная часть модели веб-безопасности. Совместное использование ресурсов между разными источниками (cross-origin resource sharing) — это механизм HTML 5, который дополняет политику единого происхождения для упрощения совместного использования ресурсов домена между различными веб-приложениями.
Спецификация CORS определяет набор заголовков, которые позволяют серверу и браузеру определять, какие запросы для междоменных ресурсов (изображения, таблицы стилей, сценарии, данные и т. д.) разрешены, а какие нет. CORS является техникой для ослабления правила одного источника, позволяя JavaScript на web странице обрабатывать REST API запросы от другого источника.
По своей сути, CORS это защитная оболочка для браузера. Совместное использование ресурсов между разными источниками очень важно в современном мире сложных веб-приложений, и все браузеры поддерживают его. В частности, CORS обычно используется для междоменных AJAX запросов.
Обмен запросами
Взаимодействие ресурсов начинается с отправки GET, POST или HEAD запросу к тому или иному ресурсу на сервере. Тип содержимого POST запроса ограничен application/x-www-form-urlencoded, multipart/form-data или plaintext. Запрос включает заголовок Origin, который и указывает на происхождение клиентского кода.
Веб приложение проверяет происхождение запроса и на основании Origin либо принимает запрос, либо отвергает его. Если запрос принят, запрашиваемые сервер ответит заголовком Access-Control-Allow-Origin. Этот заголовок будет указывать клиенту с каким происхождением будет разрешен доступ. Принимая во внимание, что Access-Control-Allow-Origin соответствует Origin запроса, браузер разрешит запрос.
При запросе на site.ru/resource с site.com/some будут следующие заголовки:
Если запрос принят, запрашиваемый сервер добавляет к ответу заголовок Access-Control-Allow-Origin, содержащий домен запроса site.com.
Access-Control-Allow-Origin указывает, какие домены могут обращаться к ресурсам сайта. Например, если компания имеет домены site.ru и site.com, то ее разработчики могут использовать этот заголовок, чтобы предоставить site.com доступ к ресурсам site.ru.
Access-Control-Allow-Methods определяет, какие HTTP-запросы (GET, PUT, DELETE и т. д.) могут быть использованы для доступа к ресурсам. Этот заголовок позволяет повысить безопасность, указав какие методы действительны, когда site.com обращается к ресурсам site.ru.
Access-Control-Max-Age указывает время жизни предзапроса (также он называется «предполетным») доступности того или иного метода, после которого должен быть выполнен новый запрос на тот или иной метод.
Отказ от политики запроса из белого списка
Использование правильных заголовков, методов и доверенных доменов вроде бы не позволяет злоумышленнику вклиниться в эту цепочку обмена. На самом деле это не так. И подводит здесь коварная *.
Наиболее распространенная проблема безопасности при внедрении CORS — это отказ от проверки запроса белых списков. Зачастую разработчики устанавливают значение для Access-Control-Allow-Origin в ‘*’. Это позволяет любому домену в Интернете получать доступ к ресурсам этого сайта.
Основания проблема кроется в том, что многие компании размещают API в пределах домена, не ограничивания к нему доступ политикой «белого списка». Это порождает уязвимость.
Attack scenario
Большинство веб-приложений использует файлы cookie для отслеживания информации о сеансе. При генерации cookie ограничены определенным доменом. При каждом HTTP запросе к этому домену браузер подставлять значение cookie, созданные для этого домена. Это относится к каждому HTTP запросу — для получения изображений, страниц или AJAX-вызовов.
Что это означает на практике: при авторизации в goodsite.ru, cookie генерируются и хранятся для этого домена. Веб-приложение goodsite.ru основано на технологии SPA и содержит REST API на goodsite.ru/api для взаимодействия с помощью AJAX. Предположим, что вы просматриваете badsite.ru, будучи авторизованным на goodsite.ru. Без ограничения Access-Control-Allow-Origin по белому списку (с указанием сайта) badsite.ru может выполнить любой разрешенный аутентифицированный запрос к goodsite.ru, даже не имея прямого доступа к сессионной cookie!
Это связано с тем, что браузер автоматически привязывает файлы cookie к goodsite.ru для любых HTTP запросов в этом домене, включая AJAX запросы от badsite.ru в goodsite.ru. Таким образом атакующий может взаимодействовать даже с вашим внутренним ресурсом, недоступным в сети интернет и находящимся в корпоративной сети.
Наглядные примеры
В качестве примера приведу код OWASP Testing Guide. Уязвимое веб-приложение, с неверно настроенной политикой Access-Control-Allow-Origin.
Например, такой запрос будет показывать содержимое файла profile.php:
Т.к. отсутствует проверка URL-адреса, атакующий может добавить скрипт, который будет выполняться в контексте домена example.foo со следующим URL:
В качестве еще одного примера рекомендую ознакомиться с Stealing contact form data on www.hackerone.com using Marketo Forms XSS with postMessage frame-jumping and jQuery-JSONP — публичным раскрытием уязвимости, включая небольшую видео-демонстрацию.
Защитные меры
Используйте белые списки доменов. Если такой возможности нет — размещайте API вне домена — политики CORS для sub.site.ru, site.ru и даже разным портам будут различаться.
Указывайте конкретные методы обращения.
Не используйте wildcard — CORS учитывает или * или домен.
Обязательно указывайте протокол. «Access-Control-Allow-Origin: site.ru» не будет учтён, поскольку протокол отсутствует.
При использовании Access-Control-Allow-Credentials: true всегда используется Access-Control-Allow-Origin: домен — при использовании * браузер не получит ответ.
CORS с заголовками php
у меня есть простой PHP-скрипт, который я пытаюсь выполнить междоменный запрос CORS:
но я все равно получаю ошибку:
запрос поле заголовка X-Requested-With Не допускается Access-Control-Allow-Headers
что-нибудь я пропустил?
9 ответов
Access-Control-Allow-Headers не дает * в качестве принятого значения см. документацию Mozilla здесь.
вместо звездочки вы должны отправить принятые заголовки (сначала X-Requested-With как говорится в ошибке).
обработка запросов CORS правильно-это немного больше. Вот функция, которая будет реагировать более полно (и правильно).
Я получил ту же ошибку и исправил ее со следующим PHP в моем бэкэнд-скрипте:
многие описания в Интернете не упоминают, что указание Access-Control-Allow-Origin не хватает. Вот полный пример, который работает для меня:
Мне просто удалось получить dropzone и другой плагин для работы с этим исправлением (angularjs + php backend)
добавить в загрузки.php или куда вы отправите свой запрос (например, если у вас есть загрузка.html и вам нужно прикрепить файлы для загрузки.php, затем скопируйте и вставьте эти 4 строки). Кроме того,если вы используете плагины/аддоны CORS в chrome/mozilla, обязательно переключайте их более одного раза, чтобы включить CORS
Если вы хотите создать сервис CORS из PHP, вы можете использовать этот код в качестве первого шага в вашем файле, который обрабатывает запросы:
CORS может стать головной болью, если мы не правильно понимаем его функционирование. Я использую их в PHP и они работают без проблем. ссылка здесь
этот код работает для меня при использовании angular 4 в качестве клиентской стороны и PHP в качестве серверной стороны.
CORS для чайников: история возникновения, как устроен и оптимальные методы работы
В этой статье подробно разобрана история и эволюция политики одинакового источника и CORS, а также расписаны разные типы доступа между различными источниками, а также несколько оптимальных решений работы с ними.
Если вы давно хотели разобраться в CORS и вас достали постоянные ошибки, добро пожаловать под кат.
Ошибка в консоли вашего браузера
No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://example.com/
Access to fetch at ‘https://example.com’ from origin ‘http://localhost:3000’ has been blocked by CORS policy.
Я уверен, вам уже доводилось видеть похожие сообщения об ошибках в консоли вашего браузера. Если нет, не волнуйтесь, скоро увидите. Все программисты достаточно часто натыкаются на CORS-ошибки.
Эти всплывающие ошибки в процессе разработки просто раздражают. Но на самом деле, CORS — это невероятно полезный механизм в мире неправильно настроенных веб серверов, злоумышленников, орудующих в интернете и организаций, продвигающих веб-стандарты.
Но давайте-ка пойдем к истокам…
В начале был первый субресурс
Верни мне мой 1993 г.
Источники & cross-origin
Источник идентифицируется следующей тройкой параметров: схема, полностью определенное имя хоста и порт. Например, и имеют разные источники: первый использует схему http, а второй https. Вдобавок, портом для http по умолчанию является 80, тогда как для https — 443. Следовательно, в данном примере 2 источника отличаются схемой и портом, тогда как хост один и тот же (example.com).
Таким образом, если хотя бы один из трех элементов у двух ресурсов отличается, то источник ресурсов также считается разным.
Если, к примеру, мы будем сравнивать источник с другими источниками, то мы получим следующие результаты:
| URL | Результат | Причина |
| Тот же | Отличается только путь | |
| Тот же | Отличается только путь | |
| Отличен | Разные протоколы | |
| Отличен | Отличается порт (https:// порт является по умолчанию 443) | |
| Отличен | Разный хост |
Пример запроса между различными источниками: когда ресурс (то есть, страница) типа попробует отобразить тег из источника (заметьте, что схема поменялась!).
Слишком много опасностей запроса между различными источниками
Теперь, когда мы определились, что такое совместное использования ресурсов между разными и одинаковыми источниками, давайте посмотрим, в чем же дело.
Когда тег появился во Всемирной Паутине, мы тем самым открыли ящик Пандоры. Некоторое время спустя в Сети появились теги
fastcodenote
Страницы
вторник, 11 февраля 2014 г.
CORS. Как посылать запросы GET, POST, DELETE etc.
В наши дни не знать что такое CORS (wiki), сродни прогулки тёмной ночью по последнему этажу, недостроенной высотки где-нибудь за городом, в неблагополучном районе. Т.е. смертеподнобно, а особенно если вы фронт-енд разработчик.
Более подробно вы можете ознакомиться перейдя по ссылкам в конце текста, я же скажу вкратце, CORS это набор HTTP заголовков, которые позволяют объяснить браузеру и серверу, что они хоть и из разных доменов, но одной крови работать могут вместе. Т.е. кросс-доменные зпросы поддерживаються. Кто не знает, то запрос из браузера посредством старого, доброго JavaSctipt недавно, так на чистоту, без костылей сделать было невозможно. Ура, эти мрачные времена канули в лету. Пришёл на момощь CORS.
Речь пойдет именно о процессе использования и базовой настройки заголовков сервера, и отсыла запросов клиента с использованием jQuery.
Сервер, который мнит себя крутым сервисом, настолько куртым что хочет предоставить поддержку кросс-доменных запросов. Должен клинету сообщить об этом. Отправив следующие заголовки:
Это тот минимум, который необходим для успешной работы наших кросс-доменных запросов. немного рапишем что, к чему:
Access-Control-Allow-Origin — (обязательный) собственно список разделенный пробелами допустимых доменнов (источников), которые будут ломиться делать запросы к нам на сервер. Из особенностей: регистрозависим, поддерживает маски, например, http://api.superservice.com/, http://*.superservice.com/ или, как вы могли догадаться просто «звездочка» *. Этот заголовок будет сравниваться с заголовком Origin клиентского запроса.
Access-Control-Allow-Method — (обязательный) это список доступных HTTP методов, разделенных запятыми. Особое внимание стоит уделить тому, что «звездочка» аля * работать не будет!
Access-Control-Allow-Headers — (обязательный вместе с Access-Control-Request-Headers) список через запятую заголовков разрешенных в запросе.
Пример настройки для Apache:
Давайте разберемся, что тут происходит? А происходит следующее, запросы будут обработанны с любого источника, если они будут одного из перечисленных в Header always set Access-Control-Allow-Methods типов, так же будут подерживаться заголовки X-Requested-With и content-type
Тот же пример для PHP
Такое поведение странно, для меня, по крайней мере, несмотря на то что заголовок X-Requested-With вы укажите Access-Control-Allow-Headers не исключены проблемы с запросами. Ходят слухи что это бага AngularJs, кому интересно, если найдете что, отпишитесь в коментах.
Переходим к интересным запросам типа POST/PUT/DELETE, всех их объединяет то что они пытаются что-то изменить на сервере. Но как сделать такой запрос кросс-доменным? Сначала надо получить список заголовков типа Access-Control-*, делается это предварительным OPTIONS запросом. Который может вернуть тот же набор Access-Control-*, что и обычный метод GET.
На сервере если вы больше нигде и не для чего более не будете использовать OPTIONS запросы, то можете смело на все запросы типа OPTIONS отвечать необходимыми заголовками в том числе и такими заветными для нас как CORS заголовки. Если кто не понял то имееться ввиду добавить правило для всех запросов типа OPTIONS в роутах вашего любимого фреймворка. Или же сделать обработку руками.
Этот предварительный запрос (prefligth-запрос), делается автоматически jQuery или тем же Angular, по-тому же URL что и ваш основной запрос POST/PUT/DELETE поэтому будте внимательны если вы не сделаете правильной обработку запросов типа OPTIONS то и запрос POST/PUT/DELETE у вас сделать не получиться, из-за политики безопасности, который следуют браузеры.
Пример запроса POST с использованием jQuery.
Я старался изложить кратко, в справочном виде, не очень получилось :), но думаю многим кто прочитал это сэкономит время. Ниже список источников, который позволят вам более глумого изучить вопрос CORS