Путаница в отношении той же политики происхождения (sop) и защиты csrf

Question

У меня есть путаница в отношении той же политики происхождения (SOP).

Например, http://bad.com/bad.html с bad.js и http://good.com/good.html с good.js. Я открываю оба URL-адреса в моем хроме с двумя вкладками (tab1 и tab2).

В good.html (открыт в tab2), есть элемент <input id="token-id" type='text' name='token' value='123abc'>

Теперь вопрос если нет СОП, будь то можно прочитать элемент input значение из bad.html (открыта в tab1) с кодом document.getElementById('token-id').value() в bad.js.

Другой вопрос: , если ответ на этот вопрос «нет», я не могу понять это предложение в wiki https://en.wikipedia.org/wiki/Same-origin_policy#Security_Concerns.

Что касается отправки новых сделок, даже защиты CSRF банковского сайта не имеет никакого эффекта, потому что сценарий может просто сделать то же самое, как пользователь будет делать

Поскольку мы не можем получить токен csrf. почему это не работает. Сервер может вычислять реальный пост-запрос, проверяя токен csrf.

Не понимаю ли я защиту csrf или SOP?

Спасибо, если кто-нибудь может помочь мне разобраться в этой путанице.

Answer 1

Вы недопонимание некоторых вещей, СОПЫ говорят, что если вы откроете http://bad.com/bad.html и что страница загружает и выполняет bad.js, что Javascript может сделать запрос AJAX для bad.com, но любой запрос, указывающий на good.com будет заблокирован, если good.com не принимает его в явном виде (с использованием протокола CORS).

Причина в том, что любой запрос на любой сайт может содержать файлы cookie, которые браузер хранит, связанные с этим сайтом, поэтому bad.com может использовать сеанс, который вы не закрыли на good.com, чтобы сделать что-то вредное.

Так что относительно ваших вопросов: Нет, вкладка не знает других вкладок, если они не связаны (родительский - дочерний), поэтому страница не может изменять поведение другого. И SOP гарантирует, что страница не может выдавать себя за другого

Answer 2

Теперь вопрос, если нет СОП, будь то можно прочитать значение входного элемента из bad.html (открыт в tab1) с некоторым кодом, как document.getElementById («маркер-ид»). Значение() в bad.js.

Нет - так как ссылки на другую вкладку отсутствуют.

Если открытая вкладка была открыта через window.open с вкладки, выполняющей чтение (вместо ручного), тогда токен можно прочитать.

К счастью, такая же политика происхождения делает, поэтому нам не нужно об этом беспокоиться.

---

Что касается отправки новых сделок, даже защиты CSRF банковского сайта не имеет никакого эффекта, потому что сценарий может просто сделать то же самое, как пользователь будет делать

токен CSRF содержит информация доступна только браузеру и дружественному сайту.

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

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

Поскольку такая же политика происхождения существует, это не проблема.