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

145

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

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

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

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

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

— Брент Ариас
источник

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

— Майкл Хэмптон

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

— Сиро Сантилли 郝海东冠状病六四事件法轮功

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

— Маленький инопланетянин

Ответы:

175

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

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

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

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

— Суреш Кумар
источник

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

— Крис

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

— Суреш Кумар

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

— Крис

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

— Кристиан Давен

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

— Мохсенме

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

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

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

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

— Mikey
источник

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

— Брент Ариас

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

— Майки

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

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

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

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

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

— Mohsenme
источник