POSTING

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

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

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

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

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

Ответ 1

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

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

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

Подробнее см. wikipedia

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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