Публикация междоменных форм

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

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

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

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

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


http html security csrf same-origin-policy
person Brent Arias    schedule 10.07.2012    source источник
comment
Да, злоумышленник может это сделать ... с помощью обычного веб-браузера.   -  person Michael Hampton    schedule 27.12.2013
comment
Возможно, нет RFC по той же причине, по которой нет RFC, в которой говорится: не размещайте свой пароль на своем веб-сайте. Веб-стандарты требуются только тогда, когда несколько сторон должны работать вместе для достижения чего-то: одна и та же политика происхождения представляет собой более сложный набор передовых методов безопасности, которые предотвращают взлом пользователей.   -  person Ciro Santilli 新疆再教育营六四事件ۍ    schedule 03.07.2014
comment
@Ciro Пожалуйста, скажите прямо. Правила перекрестной публикации на других сайтах не влияют на несколько сторон. Не нужно использовать туманный язык.   -  person Little Alien    schedule 27.09.2016

Ответы (3)


arrow_upward
190
arrow_downward

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

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

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

Дополнительную информацию см. В wikipedia.

person Suresh Kumar    schedule 11.07.2012
comment
Извините, что перетащил старый вопрос, что произойдет, если действие было изменено с помощью JS, но затем форма была опубликована с помощью кнопки? Сможет ли это создать успешную междоменную публикацию? - person Chris; 04.07.2013
comment
AFAIK это не должно быть проблемой, но я сам не пробовал. Было бы интересно узнать. - person Suresh Kumar; 05.07.2013
comment
Я придерживаюсь той же мысли. Я действительно беспокоился о безопасности, какой-то сторонний JS / вирус изменял действие, чтобы отправить форму где-то злонамеренно, но понял, что это можно сделать на любой кросс-доменной форме приема платежей или нет, и результат будет таким же. Урок здесь на самом деле: проверьте любые сторонние JS файлы;) - person Chris; 05.07.2013
comment
Вкратце: ДА, междоменное размещение разрешено. - person Christian Davén; 15.04.2014
comment
Я не думаю, что это действительно связано с javascript или нет, скорее, если вы хотите, чтобы ваша страница попала в целевой домен после публикации. Если нет, вам нужно посмотреть на решения типа CORS или mod_proxy. - person user1255162; 25.06.2014
comment
-1 для: Политика одного и того же происхождения не имеет ничего общего с отправкой запроса на другой URL-адрес (другой протокол, домен или порт), это все об ограничении доступа (чтении) данных ответа с другого URL-адреса (и тем самым предотвращении javascript для обновления документа с помощью формы, содержащие токены безопасности с другого URL-адреса). - person Mohsenme; 08.05.2015
comment
Тем, кто приедет сюда в 2021 году, стоит отметить, что Chrome теперь будет блокировать некоторые файлы cookie в сообщении формы, если для них не установлены значения SameSite = None и Secure = true blog.chromium.org/2020/02/ - person waternova; 23.06.2021

arrow_upward
45
arrow_downward

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

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

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

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

person Mikey    schedule 11.07.2012
comment
Я обновил свой вопрос, чтобы уточнить. Кроме того, указанная вами ссылка WordPress включает эксплойты, которые были инициированы из X того же источника, а не из междоменного Y ... так что это неправильный сценарий из того, что я вижу. - person Brent Arias; 11.07.2012
comment
@Brent Arias: да, то, что вы описываете в пунктах 1 и 2, в точности совпадает с тем, что выполняет CSRF-атака, возможно, вам стоит попробовать выполнить один из предоставленных CSRF-эксплойтов и проанализировать трафик. Я обновил свой пост, вы должны прочитать каждую предоставленную ссылку, потому что она точно ответит на эти вопросы. Смысл атаки с подделкой межсайтового запроса (CSRF) заключается в том, что запрос исходит из другого домена, все предоставленные эксплойты полностью соответствуют этому фундаментальному требованию. - person Mikey; 11.07.2012

arrow_upward
16
arrow_downward

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

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

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

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

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

person Mohsenme    schedule 07.05.2015