Такая же политика происхождения и CORS (совместное использование ресурсов)

Я пытался понять КОРС. По моему мнению, это механизм безопасности , реализованный в браузерах, чтобы избежать любого запроса ajax в домене, отличном от того, который был открыт пользователем (указан в URL-адресе)

Теперь из-за этого ограничения многие CORS были реализованы, чтобы веб-сайты могли выполнять запрос на перекрестный поиск. но, согласно моему пониманию, внедрение CORS не соответствует цели безопасности «Same Origin Policy» SOP

CORS просто обеспечивает дополнительный контроль над сервером запросов. Может быть, он может избежать спамеров.

Из Википедии :

Чтобы инициировать запрос перекрестного происхождения, браузер отправляет запрос с заголовком заголовка Origin. Значение этого заголовка – это сайт, который обслуживал страницу. Например, предположим, что страница http://www.example-social-network.com пытается получить доступ к данным пользователя в онлайн-альбоме -calendar.com. Если браузер пользователя реализует CORS, будет отправлен следующий заголовок запроса:

Происхождение: http://www.example-social-network.com

Если online-personal-calendar.com разрешает запрос, он отправляет заголовок Access-Control-Allow-Origin в свой ответ. Значение заголовка указывает, какие исходные сайты разрешены. Например, ответ на предыдущий запрос будет содержать следующее:

Access-Control-Allow-Origin: http://www.example-social-network.com

Если сервер не разрешает запрос перекрестного происхождения, браузер отправит сообщение на страницу example-social-network.com вместо ответа online-personal-calendar.com.

Чтобы разрешить доступ ко всем страницам, сервер может отправить следующий ответный заголовок:

Access-Control-Allow-Origin: *

Однако это может оказаться неприемлемым для ситуаций, в которых проблема безопасности.

Что мне здесь не хватает? какова цель CORS для обеспечения безопасности сервера и защиты клиента.

Политика же происхождения

Что это?

Политика одинакового происхождения – это мера безопасности, стандартизованная среди браузеров. «Начало » в основном относится к «домену» . Это предотвращает взаимодействие разных источников друг от друга, чтобы предотвратить атаки, такие как Cross Site Request Forgery .

Как работает CSRF-атака?

Браузеры позволяют веб-сайтам хранить информацию на компьютере клиента в виде файлов cookie. Эти cookies имеют некоторую информацию, прикрепленную к ним, например имя файла cookie, когда оно было создано, когда оно истечет, кто установил cookie и т. Д. Файл cookie выглядит примерно так:

Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]

Итак, это шоколадное печенье, которое должно быть доступно с http://bakery.com и всех его поддоменов.

Этот файл cookie может содержать некоторые конфиденциальные данные. В этом случае эти данные … chocolate . Как вы можете видеть, очень чувствительный.

Таким образом, браузер сохраняет этот файл cookie. И всякий раз, когда пользователь делает запрос в домен, на котором доступен этот куки-файл, cookie будет отправлен на сервер для этого домена. Счастливый сервер.

Это хорошая вещь. Супер classный способ для сервера хранить и извлекать информацию с клиентской стороны.

Но проблема в том, что это позволяет http://malicious-site.com отправлять эти cookies на сайт http://bakery.com , не зная! Например, рассмотрим следующий сценарий:

 # malicious-site.com/attackpage var xhr = new XMLHttpRequest(); xhr.open('GET', 'http://sofru.miximages.com/ajax/deliveryAddress=%22address%20of%20malicious%20user%22'); xhr.send(); 

Если вы посещаете вредоносный сайт и выполняете вышеуказанный код, а политика того же происхождения не существует, злоумышленник отправит заказ от вашего имени и получит заказ у него … и вам может не понравиться это ,

Это произошло потому, что ваш браузер отправил ваш шоколадный cookie на http://bakery.com , что заставило http://bakery.com подумать, что вы делаете запрос на новый заказ, сознательно . Но это не так.

Это, проще говоря, атака CSRF. Поддельный запрос был сделан через сайты. «Подделка запросов на межсайтовый запрос». И это не сработает, благодаря политике одного и того же происхождения.

Как политика такого же происхождения разрешает это?

Он запрещает malicious-site.com делать запросы в другие домены. Просто.

Другими словами, браузер не разрешил бы любому сайту делать запрос на любой другой сайт. Это предотвратило бы взаимодействие разных источников друг с другом посредством таких запросов, как AJAX.

Однако загрузка ресурсов с других хостов, таких как изображения, сценарии, таблицы стилей, iframe, формы и т. Д., Не подпадает под это ограничение. Нам нужна еще одна стена, чтобы защитить нашу пекарню от вредоносного сайта, используя токены CSRF .

Токены CSRF

Как указано, вредоносный сайт все еще может сделать что-то вроде этого, не нарушая политику одного и того же происхождения:

  

И браузер попытается загрузить изображение с этого URL-адреса, в результате чего GET-запрос на этот URL-адрес отправит все cookies. Чтобы этого не произошло, нам нужна защита на стороне сервера.

В принципе, мы присоединяем случайный уникальный символ подходящей энтропии к сеансу пользователя, храним его на сервере, а также отправляем его клиенту с формой. Когда форма отправляется, клиент отправляет этот токен вместе с запросом, а сервер проверяет, является ли этот токен действительным или нет.

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


CORS

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

Это работает, когда «домены» сообщают обозревателю о охлаждении и разрешают такие запросы. Эта «говорящая» вещь может быть выполнена путем передачи заголовка. Что-то вроде:

Access-Control-Allow-Origin: //comma separated allowed origins list, or just * Так что если http://bakery.com передает этот заголовок в браузер, а страница, создающая запрос на http://bakery.com, – это присутствовать в списке происхождения, то браузер отправит запрос вместе с файлами cookie.

Существуют правила, согласно которым определяется начало координат 1 . Например, разные порты для одного и того же домена не совпадают. Таким образом, браузер может отклонить этот запрос, если порты отличаются. Как всегда, наш дорогой Internet Explorer является исключением из этого. IE обрабатывает все порты одинаково. Это нестандартно, и никакой другой браузер не ведет себя так. Не полагайтесь на это .


JSONP

JSON с Padding – это всего лишь способ обойти политику одного и того же происхождения, когда CORS не является вариантом. Это рискованная и плохая практика. Избегайте использования этого.

Этот метод включает в себя запрос на другой сервер, например:

Поскольку политика одинакового происхождения не предотвращает этот запрос 2 , ответ этого запроса будет загружен на страницу.

Этот URL, скорее всего, будет отвечать содержимым JSON. Но просто включение содержимого JSON на странице не поможет. Это приведет к ошибке, конечно. Таким образом, http://badbakery.com принимает параметр обратного вызова и изменяет данные JSON, отправляя его, завернутый в все, что передается параметру обратного вызова.

Поэтому вместо того, чтобы возвращаться,

{ user: "vuln", acc: "B4D455" }

который недействителен JavaScript, бросающий ошибку, он вернется,

cake({user: "vuln", acc:"B4D455"});

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

Это в основном используется API для отправки данных в другие домены. Опять же, это плохая практика, может быть рискованной, и ее следует строго избегать.

Почему JSONP плохой?

Прежде всего, он очень ограничен. Вы не можете обрабатывать какие-либо ошибки, если запрос не работает (по крайней мере, не разумно). Вы не можете повторить запрос и т. Д.

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

Наконец, вы вставляете случайный код JavaScript в DOM. Если вы не на 100% уверены, что удаленная служба вернет безопасные пирожные, вы не можете полагаться на это.


Рекомендации

1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin

2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details

Другие достойные чтения

http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html

http://tools.ietf.org/html/rfc3986 (извините: p)

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Политика одинакового происхождения (SOP) – это браузер политик для предотвращения уязвимостей через Cross Site Scripting (XSS). Это в основном для защиты сервера, так как есть много случаев, когда сервер может иметь дело с аутентификацией, куки, сеансами и т. Д.

Совместное использование ресурсов Cross Origin (CORS) – один из немногих методов расслабления SOP. Поскольку SOP по умолчанию включен, установка CORS на стороне сервера позволит отправить запрос на сервер через XMLHttpRequest, даже если запрос был отправлен из другого домена. Это становится полезным, если ваш сервер должен был обслуживать запросы из других доменов (например, если вы предоставляете API).

Надеюсь, это прояснит различие между SOP и CORS и целями каждого из них.

  • Access-Control-Allow-Origin Несколько доменов происхождения?
  • Поскольку v38, расширение Chrome больше не может загружаться с URL-адресов HTTP, обходной путь?
  • Давайте будем гением компьютера.