Как веб-серверы применяют политику одного и того же происхождения?

Я углубляюсь в разработку RESTful API и до сих пор работал с несколькими различными средами для достижения этой цели. Конечно, я столкнулся с политикой того же происхождения, и теперь мне интересно, как веб-серверы (а не веб-браузеры) применяют ее. Из того, что я понимаю, кажется, что какое-то принуждение происходит в конце браузера (например, при чтении заголовка Access-Control-Allow-Origin, полученного от сервера). Но как насчет сервера?

Например, скажем, на веб-сервере размещено веб-приложение Javascript, которое обращается к API, также размещенному на этом сервере. Я предполагаю, что сервер будет применять политику того же источника - так что только javascript, размещенный на этом сервере, будет иметь доступ к API. Это помешает кому-то еще написать клиент JavaScript для этого API и разместить его на другом сайте, верно? Итак, как веб-сервер сможет остановить злонамеренный клиент, который будет пытаться отправлять запросы AJAX на свои конечные точки API, утверждая при этом, что он запускает javascript, исходящий от того же веб-сервера? Как наиболее популярные серверы (Apache, nginx) защищают от такого рода атак? Или мое понимание этого как-то не соответствует действительности?

Или политика перекрестного происхождения применяется только на стороне клиента?

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

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

Политика того же происхождения была изобретена, потому что она предотвращает доступ кода с одного веб-сайта к контенту с ограничениями доступа на другом сайте. Ajax-запросы по умолчанию отправляются с любыми куки-файлами, предоставляемыми целевым сайтом. Например, предположим, я случайно загрузил 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-запрос, используя сохраненные куки-файлы клиента. Таким образом, если сервер может подтвердить, Refererчто HTTP-запрос поступает от gmail.com, а не от MyAwesomeWebsite.com, он может остановить атаку.

Как веб-серверы применяют политику одного и того же происхождения?

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

Кто:

ACAO как HTTP-заголовок ответа предназначен для интерпретации веб-клиента, исходя из того, что большинство пользователей интернета просматривают Интернет через крупных поставщиков браузеров, которые придерживаются и реализуют рекомендованный черновик W3C . Они должны, в конце концов, большинство из них воспользоваться быстрым и доступным интернетом.

Как:

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

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

Будущее:

На этом этапе обратите внимание на направление производителя веб-браузера:

• удаление плагина по умолчанию , как шаг к полностью изолированной среде и
• удаление пользовательской опции, чтобы отключить JavaScript

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

"Google" имеет это, чтобы показать и сказать о DDOS

Наконец, любой может свободно прокси-сервер любого веб-контента и добавить желаемый заголовок ACAO для доступа к прокси-контенту между сайтами. Аналогичным образом, этот прокси-сервер также открыт для атаки DDOS, как позволяет настройка ACAO. Я на самом деле не знаю ни одного бесплатного публичного предложения. Пожалуйста, поправьте меня, если я ошибаюсь.

Как говорили другие, дело за клиентом. Но серверу, возможно, придется иметь дело с XSS, который обходит SOP.

Supopse ваш сервер позволяет пользователям загружать контент, который отображается, когда другие пользователи просматривают ваш сайт. Эта страница является хорошим примером - я только что загрузил контент, и он отображается для вас.
Если в моем контенте есть <script>тег, а сервер просто копирует его в генерируемый HTML-код, загруженный скрипт будет запущен.
Поскольку скрипт был найден в HTML из вашего файла, он имеет все разрешения для скрипта вашего сайта. Это может, например, поддержать этот ответ. И вот почему этот ответ имеет так много голосов.

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

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