Розміщення міждоменної форми

145

Я бачив статті та публікації по всій цій темі (включаючи ТАК), і переважаючий коментар полягає в тому, що політика одного і того ж походження перешкоджає надсилати форму POST для всіх доменів. Єдине місце , де я бачив хто - то припустити , що ті ж походження політик не застосовується для формування повідомлення, тут .

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

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

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

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

— Brent Arias
джерело

Так, зловмисник міг це зробити ... зі звичайним веб-браузером.

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

Можливо, немає RFC з тієї ж причини, чому немає RFC, які говорять: "не публікуйте свій пароль на своєму веб-сайті". Веб-стандарти потрібні лише тоді, коли кілька сторін повинні працювати разом, щоб чогось досягти: одна і та ж політика походження є більш складним набором "найкращих практик безпеки", які не дають користувачам зламатись.

— Ciro Santilli 郝海东冠状病六四事件法轮功

@Ciro Будь ласка, скажіть прямо. Правила перехресного опублікування на інші сайти не впливають на декілька сторін. Не потрібно туманної промови.

— Маленький прибулець

Відповіді:

175

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

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

і у публікації форми немає JavaScript, тоді та сама політика щодо оригіналу не застосовується.

Додаткову інформацію див. У wikipedia

— Суреш Кумар
джерело

Вибачте, що перетягнути старе запитання, що буде, якби дію було змінено за допомогою JS, але потім форма була розміщена за допомогою кнопки? Чи дозволить це зробити успішну публікацію між доменами?

— Кріс

AFAIK це не повинно бути проблемою, але я сам цього не пробував. Було б цікаво дізнатися.

— Суреш Кумар

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

— Кріс

Коротше кажучи: ТАК, дозволено розміщення міждоменів.

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

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

— Мохсенме

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

Існує багато способів побудови експлуатації КСВР. Проста атака CSRF на основі POST може бути надіслана .submit()методом. Більш складні атаки, такі як міжміські завантаження файлів CSRF, атакуватимуть використання CORS поведінки xhr.withCredentals .

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

Переконайтесь, що ваші запити захищені, використовуючи один із методів, описаних у шпаргалі OWASP CSRF Prevention . Для отримання додаткової інформації про CSRF див. Сторінку OWASP на CSRF .

— Майкі
джерело

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

— Brent Arias

@Brent Arias так, те, що ви описуєте в 1 і 2, точно дорівнює тому, що робить атака CSRF, можливо, вам слід спробувати виконати один із передбачених подвигів CSRF і нюхати трафік. Я оновив свою публікацію, ви повинні прочитати кожне надане посилання, оскільки воно точно відповість на ці запитання. Суть нападу "підробка підписів між веб-сайтами" (CSRF) - це запит, що походить з іншого домену, всі надані подвиги повністю відповідають цій основній вимозі.

— Майкі

Одна і та ж політика походження не має нічого спільного з надсиланням запиту на інший URL (інший протокол або домен чи порт).

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

Але те, що робить ці запити POST неефективними, полягає в тому, що в цих запитах відсутні антигенетичні маркери, тому інша URL-адреса ігнорується. Більше того, якщо JavaScript намагається отримати ці маркери безпеки, надіславши запит AJAX на URL-адресу жертви, йому забороняється отримувати доступ до цих даних за допомогою політики "Оригінальний джерело".

Хороший приклад: тут

І хороша документація від Mozilla: ось

— Мохсенме
джерело