Углубленный взгляд на CORS

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

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

Получение страницы, как видит пользователь с помощью CORS

Если мы хотим включить учетные данные пользователя в удаленный запрос, мы должны сделать два изменения: первое в коде веб-сайта, выполняющего запрос, и второе в веб-сайте, получающем запрос. На веб-сайте, выполняющем запрос, мы должны установить для свойства withCredentials запроса Ajax значение true :

 var xhr = new XMLHttpRequest(); xhr.withCredentials = true; 

Сам удаленный сервер, помимо разрешения нашего происхождения, должен установить заголовок Access-Control-Allow-Credentials и установить его значение в true . Использование чисел 1 или 0 не будет работать.

Если мы просто установим withCredentials в значение true но сервер не установил вышеупомянутый заголовок, мы не получим ответ, даже если наш источник разрешен. Мы получим сообщение, похожее на:
XMLHttpRequest не может загрузить http://example.com/index.php . Флаг Credentials имеет значение «true», но заголовок «Access-Control-Allow-Credentials» имеет значение «. Это должно быть 'true', чтобы разрешить учетные данные. Поэтому происхождение ' http: // localhost: 63342 ' не разрешено.

Если оба изменения будут внесены, мы получим персональный ответ. В нашем случае имя пользователя, которое мы сохранили в cookie, будет в ответе, который удаленный сервер возвращает на наш сайт.

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

Preflights

Когда запросы начинают усложняться, мы можем захотеть узнать, разрешен ли и принят ли конкретный метод запроса (такой как get , put , post , patch или delete ) или конкретный пользовательский заголовок и принят ли сервер. В этом случае вы можете использовать предварительные рейсы, когда вы сначала отправляете запрос с помощью метода options и объявляете, какой метод и заголовки будут иметь ваш запрос. Затем, если сервер возвращает заголовки CORS и мы видим, что наши origin, заголовки и методы запроса разрешены, мы можем сделать фактический запрос (Origin - это заголовок, который передается нашими браузерами при каждом запросе перекрестного источника, который мы делаем. И нет, мы не можем изменить значение Origin при запросе в обычном браузере).

Как мы видим на изображении выше, сервер возвращает несколько заголовков, которые мы можем использовать, чтобы определить, следует ли сделать фактический запрос. Он возвращает нам, что все источники разрешены ( Access-Control-Allow-Origin: * , что мы не можем сделать запрос при передаче учетных данных пользователя ( Access-Control-Allow-Credentials ), что мы можем только делать запросы get ( Access-Control-Allow-Methods ) и что мы можем использовать пользовательский заголовок X-ApiKey ( Access-Control-Allow-Headers ). Наконец, Access-Control-Allow-Headers Access-Control-Max-Age показывают значение в секундах, указывая, как долго (с время запроса) мы можем делать запросы, не полагаясь на другой предполетный полет.

С другой стороны, в нашей внешней логике мы передаем Access-Control-Request-Method и передаем Access-Control-Request-Headers чтобы указать, какой метод запроса и какие заголовки мы намереваемся добавить в наш реальный запрос. В Vanilla JavaScript вы можете прикрепить заголовок при выполнении вызовов Ajax с помощью xhr.setRequestHeader ('headerString', 'headerValueString'); ,

CORS для холст изображения

Если мы хотим загрузить внешние изображения и отредактировать их на холсте или просто сохранить их значение в кодировке base64 в localStorage в качестве механизма кэширования, удаленный сервер должен включить CORS. Есть разные способы сделать это. Один из способов - это изменить конфигурацию вашего веб-сервера, добавив заголовок Access-Control-Allow-Origin при каждом запросе для определенных типов изображений, такой пример показан в документации Mozilla . Если у нас есть скрипт, который динамически генерирует изображения путем изменения типа Content-Type и выводит изображение, например http://example.com/image/image.php?image=1, мы можем просто установить этот заголовок вместе с выводом изображения.
Без CORS, если мы попытаемся получить доступ к удаленному изображению, загрузить его на холст, отредактировать и сохранить его с помощью toDataURL или просто попытаться добавить измененное изображение в DOM с помощью toDataURL , мы получим следующее исключение безопасности (и мы не будем сохранить или показать его): изображение из источника " http://example.com " заблокировано для загрузки политикой общего доступа к ресурсам разных источников: в запрошенном заголовке «Access-Control-Allow-Origin» отсутствует ресурс. Поэтому происхождение ' http: // localhost: 63342 ' не разрешено .
Если сервер, на котором находится изображение, возвращает изображение вместе с заголовком Access-Control-Allow-Origin: * , то мы можем сделать следующее:

 var img = new Image, canvas = document.createElement("canvas"), ctx = canvas.getContext("2d"), src = "http://example.com/test/image/image.php?image=1"; img.setAttribute('crossOrigin', 'anonymous'); img.onload = function() { canvas.width = img.width; canvas.height = img.height; ctx.drawImage( img, 0, 0 ); ctx.font = "30px Arial"; ctx.fillStyle = "#000"; ctx.fillText("#SitePoint",canvas.width / 3,canvas.height / 3); img.src = canvas.toDataURL(); document.querySelector("body").appendChild(img); localStorage.setItem( "savedImageData", canvas.toDataURL("image/png") ); } img.src = src; 

Это загрузит внешнее изображение, добавит в него текст #SitePoint, отобразит его для пользователя и сохранит в localStorage. Обратите внимание, что мы установили атрибут crossOrigin внешнего изображения - img.setAttribute('crossOrigin', 'anonymous'); , Этот атрибут является обязательным, и если мы не добавим его во внешний образ, мы все равно получим еще одно исключение безопасности.

Атрибут Crossorigin

Когда мы делаем запросы на внешние изображения, аудио, видео, таблицы стилей и скрипты, используя соответствующий тег HTML (5), мы не делаем запрос CORS. Это означает, что заголовок Origin не отправляется на страницу, обслуживающую внешний ресурс. Без CORS мы не смогли бы редактировать внешнее изображение на холсте, просматривать исключения и вести журнал ошибок из внешних скриптов, загружаемых нашим веб-сайтом, или использовать объектную модель CSS при работе с внешними таблицами стилей и так далее. Есть определенные случаи, когда мы хотим использовать эти функции, и здесь crossorigin атрибут crossorigin который мы упомянули выше.

crossorigin может быть установлен для таких элементов, как <link> , <img> и <script> . Когда мы добавляем атрибут к такому элементу, мы гарантируем, что запрос CORS будет выполнен с правильно установленным заголовком Origin . Если внешний ресурс разрешает ваше происхождение через заголовок Access-Control-Allow-Origin ограничения на запросы не-CORS не будут применяться.

crossorigin имеет два возможных значения:

1. anonymous - установка атрибута crossorigin в это значение сделает запрос CORS без передачи учетных данных пользователя во внешний ресурс (аналогично выполнению запроса Ajax CORS без добавления атрибута withCredentials ).
2. use-credentials - установка атрибута crossorigin в это значение сделает CORS-запрос к внешнему ресурсу вместе с любыми учетными данными пользователя, которые могут существовать для этого ресурса. Чтобы это работало, сервер должен не только установить заголовок Access-Control-Allow-Origin который разрешает ваш источник, но также должен установить для Access-Control-Allow-Credentials значение true .

К учетным данным пользователя относятся файлы cookie, учетные данные HTTP Basic Auth, сертификаты и другие пользовательские данные, которые отправляются, когда пользователь запрашивает определенный веб-сайт.

Выводы

CORS позволяет разработчикам в дальнейшем взаимодействовать с другими системами и веб-сайтами, чтобы создавать еще лучшие веб-интерфейсы. Он может использоваться вместе с традиционными запросами, сделанными популярными тегами HTML, а также с технологиями Web 2.0, такими как Ajax.

Вы использовали CORS в своих проектах? У вас были трудности с этим? Мы хотели бы знать, каковы ваши впечатления от этого.

Ссылки и дальнейшее чтение:

• Caniuse.com
• HTML5 Rocks - ресурс для разработчиков открытого веб HTML5
• Сеть разработчиков Mozilla - изображение с поддержкой CORS
• Сеть разработчиков Mozilla - атрибуты настроек CORS
• Сеть разработчиков Mozilla - контроль доступа HTTP (CORS)
• Сеть разработчиков Mozilla - XDomainRequest
• W3.org - Обмен ресурсами между источниками
• Сеть разработчиков Mozilla - элемент HTML <link>