Ответ 1
Если я посещаю вредоносный веб-сайт, я хочу быть уверенным, что:
- Он не может читать мои личные данные с других сайтов, которые я использую. Подумайте, как атаковать злоумышленник gmail.com.
- Он не может выполнять действия от моего имени на других сайтах, которые я использую. Подумайте, что атакующий сайт переводит средства из моей учетной записи на сайте bank.com.
То же самое правило происхождения решает первую проблему. Вторая проблема называется подделкой запроса на перекрестный сайт и не может быть решена с помощью существующих междоменных ограничений.
Такая же политика происхождения в целом соответствует следующим правилам -
- Правило 1: не позволяет читать что-либо из другого домена
- Правило 2: Позволяет писать все, что угодно, в другом домене, но правило №1 не позволит вам прочитать ответ.
- Правило 3: вы можете свободно делать запросы GET для кросс-домена и запросы POST, но вы не можете управлять заголовками HTTP
Давайте посмотрим, как различные перечисленные вами вещи соответствуют приведенным выше правилам:
- Теги
-
Теги<img>позволяют вам делать HTTP-запрос, но нет способа прочитать содержимое изображения, кроме простого его отображения. Например, если я сделаю это<img src="http://bank.com/get/latest/funds"/>, запрос будет проходить (правило 2). Но нападающий не может видеть мой баланс (правило 1). -
<script>работают в основном как<img>. Если вы сделаете что-то вроде<script src="http://bank.com/get/latest/funds">, запрос будет проходить. Браузер также попытается проанализировать ответ как JavaScript и не выполнит свою работу. -
Известно злоупотребление тегами
<script>, называемыми JSONP, где вы вступаете в сговор с междоменным сервером, чтобы вы могли "читать" кросс-домен. Но без явного участия междоменного сервера вы не можете прочитать ответ через тег<script> -
<link>для таблиц стилей работают в основном как теги<script>, за исключением того, что ответ оценивается как CSS. В общем, вы не можете прочитать ответ - если ответ каким-то образом не будет хорошо сформированным CSS. -
<iframe>- это, по сути, новое окно браузера. Вы не можете прочитать HTML-код междоменного iframe. Кстати, вы можете изменить URL-адрес междоменного iframe, но вы не можете прочитать URL-адрес. Обратите внимание, как это следует из двух правил, упомянутых выше. -
XMLHttpRequest- самый универсальный метод для запросов HTTP. Это полностью находится в управлении разработчиками; браузер не делает ничего с ответом. Например, в случае<img>,<script>или<link>браузер принимает определенный формат и в целом будет соответствующим образом проверять его. Но в XHR нет предписанного формата ответа. Таким образом, браузеры применяют одну и ту же политику происхождения и не позволяют вам прочитать ответ, если веб-сайт перекрестного домена явно не позволяет вам. -
Шрифты через
font-faceявляются аномалией. AFAIK, только для Firefox требуется поведение при входе; другие браузеры позволяют использовать шрифты так же, как вы использовали бы изображения.
Короче говоря, одна и та же политика происхождения согласуется. Если вы найдете способ сделать запрос на междоменное соединение и читать ответ без явного разрешения на междоменном веб-сайте - вы будете делать заголовки по всему миру.
EDIT. Почему я не могу обойти все это с помощью прокси-сервера на стороне сервера?
Для gmail для отображения персонализированных данных ему нужны куки файлы из вашего браузера. Некоторые сайты используют базовую аутентификацию HTTP, в которой учетные данные хранятся в браузере.
Прокси-сервер на стороне сервера не может получить доступ к файлам cookie или базовым учетным данным. И поэтому, даже если он может сделать запрос, сервер не будет возвращать данные, специфичные для пользователя.