Як веб-сервери застосовують політику того самого походження?

Я заглиблююсь у розробку API RESTful і до цього часу працював з кількома різними рамками для досягнення цього. Звичайно, я зіткнувся з політикою того самого походження, і тепер мені цікаво, як веб-сервери (а не веб-браузери) їх застосовують. З того, що я розумію, здається, що деякі вимоги відбуваються в кінці браузера (наприклад, вшанування заголовка Access-Control-Allow-Origin, отриманого від сервера). А як щодо сервера?

Наприклад, веб-сервер розміщує веб-додаток Javascript, який має доступ до API, також розміщеного на цьому сервері. Я припускаю, що сервер запроваджував би політику одного і того ж джерела --- так що тільки JavaScript, який розміщений на цьому сервері, отримав би доступ до API. Це не дозволить комусь іншому писати клієнт JavaScript для цього API та розміщувати його на іншому сайті, правда? То як веб-сервер зможе зупинити зловмисного клієнта, який намагатиметься робити запити AJAX до своїх кінцевих точок API, претендуючи на те, що він працює на JavaScript, що походить з того самого веб-сервера? Яким чином найбільш популярні сервери (Apache, nginx) захищають від подібної атаки? Або моє розуміння цього якось поза межею?

Або політика перехресного походження застосовується лише в кінці клієнта?

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

Припустимо, я пишу програму, яка отримує доступ до вашого веб-сервісу. Це просто програма, яка надсилає TCP-повідомлення, що включають HTTP-запити. Ви просите механізм на стороні сервера, щоб розрізняти запити, зроблені моєю програмою (які можуть надсилати що завгодно), і запити браузера, у якого сторінка завантажена з дозволеного походження. Це просто неможливо зробити; моя програма завжди може надсилати запит, ідентичний запиту, сформованому веб-сторінкою.

Політика такого ж походження була придумана, оскільки вона не дозволяє коду одного веб-сайту отримувати доступ до вмісту з обмеженими обліковими записами на іншому сайті. За запитом Ajax за замовчуванням надсилаються будь-які авторські файли cookie, надані цільовим сайтом. Наприклад, припустимо, я випадково завантажую http://evil.com/, на що надсилає запит http://mail.google.com/. Якщо SOP не був на своєму місці, і я ввійшов у Gmail, сценарій у цій програмі evil.comміг би побачити мою вхідні. Якщо веб-сайт evil.comхоче завантажити mail.google.comбез моїх файлів cookie, він може просто використовувати проксі-сервер; публічний вміст mail.google.comне є секретом (але вміст, mail.google.comколи звертаються до моїх файлів cookie, є секретом).

Політика такого ж походження застосовується на стороні клієнта. Якщо браузер підтримує CORS , сервер може надсилати заголовки, які сповіщають браузер робити винятки з тієї ж політики походження. Наприклад, надсилання заголовка

 Access-Control-Allow-Origin: www.example.com

скаже веб-переглядачу, щоб дозволити запити між походженнями з www.example.com.

 Access-Control-Allow-Origin: *

повідомляє веб-переглядачу дозволити всі запити між походженнями до цього ресурсу.

Веб-сервери, як правило, запобігають атакам подібного роду, перевіряючи (ганебно неправильно написані) Refererрядки в заголовку HTTP, щоб переконатися, що запит надходить зі сторінки на їхньому власному сайті. Немає хорошого способу захисту від зловмисного клієнта, але це не так, як працюють атаки XSRF.

Клієнт не є шкідливим; це звичайний звичайний користувач, який змусив зловмисну ​​сторону відкрити документ, який мовчки робить HTTP-запит, використовуючи збережені файли cookie клієнта. Отже, якщо сервер може перевірити, Refererщо HTTP-запит надходить з gmail.com, а не MyAwesomeWebsite.com, він може закрити атаку.

Як веб-сервери застосовують політику того самого походження?

Коротше кажучи, їх немає, як вказували апсилери та Дірк .
Однією з важливих причин є те, що заголовок ACAO захищає самих серверів від бурхливих DDOS, - розподіленого відмови в сервісних атаках .

Хто:

ACAO як заголовок відповідей HTTP призначений для інтерпретації веб-клієнта, який працює за припущенням, що більшість користувачів Інтернету в Інтернеті переглядають Інтернет через великих постачальників браузерів, які дотримуються та реалізують рекомендований проект W3C . Зрештою, їм слід користуватися швидким, доступним Інтернетом.

Як:

В іншому випадку кожен може просто скопіювати та вставити кілька рядків коду JavaScript на шкідливий веб-сайт, на якому працює простий цикл, який робить запит Ajax GET або POST на іноземний домен. Без взаємодії з користувачем та можливості багатопотокової роботи.

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

Майбутнє:

У цей момент ми прислухалися до напряму виробника веб-браузера:

• видалення плагінів за замовчуванням , як крок до повністю пісочного середовища та
• видалення користувацької опції для вимкнення javascript

Обмеження безпеки можна чітко встановити за допомогою комбінації TSL 2/3, сильних ідентифікаторів сеансу, TAN, двофакторної аутентифікації тощо.

"Google" має це показати і сказати про DDOS

Нарешті, кожен може вільно проксифікувати будь-який веб-контент та додавати потрібний заголовок ACAO, щоб отримати доступ до проксі-вмісту міжміського сайту. Крім того, цей проксі-сервер потім настільки ж відкритий для атаки DDOS, як це дозволяє налаштування ACAO. Я фактично не знаю жодної, безкоштовної публічної послуги. Будь ласка, виправте мене, якщо я помиляюся.

Як говорили інші, це залежить від клієнта. Але серверу може знадобитися мати справу з XSS, який обходить SOP.

Supopse ваш сервер дозволяє користувачам завантажувати вміст, який відображається, коли інші користувачі переглядають ваш сайт Ця сторінка є хорошим прикладом - я щойно завантажив вміст, і він відображається вам.
Якщо мій вміст містить <script>тег, а сервер просто копіює його у створений HTML, сценарій, який я завантажив, запуститься.
Оскільки сценарій був знайдений у вашому HTML у вашому файлі, він має всі дозволи сценарію вашого сайту. Наприклад, це може відповісти на цю відповідь. І тому ця відповідь має стільки відгуків.

Хороший веб-сервер (на жаль, той, який використовує StackExchange) не дозволить цього зробити. Він може видалити <script>тег або вийти з нього, тому він буде помічений, але не виконаний (попередження - ця відповідь далеко не є надійним рецептом запобігання XSS).

Тож саме клієнтська сторона застосовує SOP, але в деяких випадках сервер повинен працювати, щоб запобігти його обходу.