Кросс-доменная форма POSTing


145

Я видел статьи и посты по всей теме (включая SO) по этой теме, и преобладающим комментарием является то, что политика одного и того же происхождения предотвращает POST формы через домены. Единственное место, где я видел, что кто-то предполагает, что политика одного и того же происхождения не распространяется на посты, находится здесь .

Я хотел бы получить ответ из более "официального" или официального источника. Например, кто-нибудь знает RFC, который рассматривает, как тот же источник влияет или не влияет на форму POST?

уточнение : я не спрашиваю, может ли GET или POST быть создан и отправлен в любой домен. Я спрашиваю:

  1. если Chrome, IE или Firefox разрешат контенту из домена «Y» отправлять POST в домен «X»
  2. если сервер, получающий POST, вообще увидит какие-либо значения формы. Я говорю это потому, что большинство онлайн-дискуссий записывают тестеров, которые сообщают, что сервер получил сообщение, но все значения формы были пустыми.
  3. Какой официальный документ (то есть RFC) объясняет, каково ожидаемое поведение (независимо от того, что браузеры в настоящее время реализовали).

Между прочим, если одно и то же происхождение не влияет на POST формы - это делает более очевидным, почему необходимы токены против подделки. Я говорю «несколько», потому что кажется слишком легким верить, что злоумышленник может просто выполнить HTTP GET, чтобы получить форму, содержащую токен противодействия фальсификации, и затем создать незаконный POST, который содержит этот же токен. Комментарии?


Да, злоумышленник может сделать это ... с помощью обычного веб-браузера.
Майкл Хэмптон

Возможно, не существует RFC по той же причине, по которой нет RFC, в которых говорится: «не размещайте свой пароль на своем веб-сайте». Веб-стандарты требуются, только когда несколько сторон должны работать вместе, чтобы чего-то достичь: одна и та же политика происхождения представляет собой более сложный набор «передовых методов обеспечения безопасности», которые предотвращают взлом пользователей.
Сиро Сантилли 郝海东 冠状 病 六四 事件 法轮功

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

Ответы:


175

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

<form action="http://someotherserver.com">

и нет никакого javascript, участвующего в публикации формы, то такая же политика происхождения не применяется.

Смотрите Википедию для получения дополнительной информации


18
Извините, что перетащил старый вопрос, что произойдет, если действие было изменено с помощью JS, но тогда форма была опубликована с помощью кнопки? Позволит ли это успешное междоменное сообщение?
Крис

AFAIK, это не должно быть проблемой, но я сам не пробовал. Было бы интересно узнать.
Суреш Кумар

2
Я той же мысли. Я действительно беспокоился о безопасности: какой-то сторонний JS / вирус изменил действие для публикации формы где-то вредоносным, но понял, что это может быть сделано на любом домене формы приема платежей или нет, и результат будет таким же. Урок здесь действительно: проверьте любые сторонние файлы JS;)
Крис

20
Вкратце: ДА, междоменная POSTing разрешена.
Кристиан Давен

17
-1 для: та же политика происхождения не имеет ничего общего с отправкой запроса на другой URL-адрес (другой протокол, домен или порт), она сводится к ограничению доступа (чтению) данных ответа из другого URL-адреса (и, таким образом, к предотвращению обновления документа с помощью javascript. формы, которые имеют токены безопасности от других URL).
Мохсенме

43

Можно создать произвольный запрос GET или POST и отправить его на любой сервер, доступный браузеру жертвы. Это включает устройства в вашей локальной сети, такие как принтеры и маршрутизаторы.

Существует много способов создания эксплойта CSRF. Простую атаку CSRF на основе POST можно отправить с помощью .submit()метода. Более сложные атаки, такие как межсайтовая загрузка файлов CSRF-атаками, будут использовать CORS-поведение xhr.withCredentals .

CSRF не нарушает политику одного и того же происхождения для JavaScrip t, поскольку SOP касается JavaScript, считывающего ответ сервера на запрос клиента. Атаки CSRF не заботятся об ответе, они заботятся о побочном эффекте или изменении состояния, вызванном запросом, таким как добавление пользователя с правами администратора или выполнение произвольного кода на сервере.

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


Я обновил свой вопрос, чтобы уточнить. Кроме того, ссылка на WordPress, которую вы дали, включает в себя эксплойты, которые были инициированы из X того же источника, а не из междоменного Y ... так что это не правильный сценарий из того, что я вижу.
Брент Ариас

@ Брент Ариас: да, то, что вы описываете в 1 и 2, в точности совпадает с тем, что выполняет атака CSRF, возможно, вам следует попробовать выполнить один из предоставленных эксплойтов CSRF и перехватить трафик. Я обновил свой пост, вы должны прочитать каждую предоставленную ссылку, потому что он точно ответит на эти вопросы. Смысл атаки «подделка межсайтового запроса» (CSRF) - это запрос, исходящий из другого домена, все предоставляемые эксплойты полностью соответствуют этому фундаментальному требованию.
Майки

16

Такая же политика происхождения не имеет ничего общего с отправкой запроса на другой URL (другой протокол, домен или порт).

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

Но что делает эти POST-запросы неэффективными, так это то, что в этих запросах отсутствуют токены защиты от подделки, поэтому другие URL игнорируют их. Более того, если JavaScript пытается получить эти маркеры безопасности, отправляя запрос AJAX на URL жертвы, он запрещает доступ к этим данным в соответствии с Same Origin Policy.

Хороший пример: здесь

И хорошая документация от Mozilla: здесь

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.