Что мешает вредоносному коду подменить заголовок «Origin» для использования CORS?

Насколько я понимаю, если клиентский скрипт, запущенный на странице с foo.com, хочет запросить данные с bar.com, в запросе он должен указать заголовок Origin: http://foo.com, а bar должен ответить Access-Control-Allow-Origin: http://foo.com.

Что может помешать вредоносному коду с сайта roh.com просто подменить заголовок Origin: http://foo.comдля запроса страниц из бара?

Браузеры контролируют настройку Originзаголовка, и пользователи не могут изменить это значение. Таким образом, вы не увидите, что Originзаголовок подделан из браузера. Злоумышленник может создать запрос curl, который вручную устанавливает Originзаголовок, но этот запрос будет поступать извне браузера и может не содержать специфической для браузера информации (например, файлов cookie).

Помните: CORS - это не безопасность. Не полагайтесь на CORS для защиты своего сайта. Если вы обслуживаете защищенные данные, используйте файлы cookie, токены OAuth или что-то еще, кроме Originзаголовка, для защиты этих данных. Access-Control-Allow-OriginЗаголовок CORS только определяет , какое происхождение должно быть разрешено делать запросы поперечного происхождения. Не надейтесь ни на что другое.

TL; DR: ничто не мешает вредоносному коду подменить источник. Когда это произойдет, ваш сервер никогда не узнает об этом и будет действовать в соответствии с запросами. Иногда эти запросы обходятся дорого. Так что не используйте CORS вместо любого типа безопасности.

Недавно я играл с CORS и задавал себе тот же вопрос. Я обнаружил, что браузер может быть достаточно умен, чтобы распознавать поддельный запрос CORS, когда он его видит, но ваш сервер не такой умный.

Первое, что я обнаружил, это то, что Originзаголовок - это имя запрещенного HTTP- заголовка, которое нельзя изменить программно. Это означает, что вы можете изменить его примерно за 8 секунд, используя Изменить заголовки для Google Chrome .

Чтобы проверить это, я установил два клиентских домена и один серверный домен. Я включил белый список CORS на сервере, который разрешал запросы CORS от Клиента 1, но не от Клиента 2. Я протестировал обоих клиентов, и действительно, запросы CORS Клиента 1 были выполнены успешно, а Клиент 2 - нет.

Затем я подделал Originзаголовок клиента 2, чтобы он соответствовал заголовку клиента 1. Сервер получил поддельный Originзаголовок и успешно прошел проверку белого списка (или провалился, если вы парень наполовину пустой). После этого Сервер работал послушно, потребляя все ресурсы, которые он был предназначен для потребления (вызовы базы данных, отправка дорогих электронных писем, отправка еще более дорогих SMS-сообщений и т. Д.). Когда это было сделано, сервер успешно отправил Access-Control-Allow-Originв браузер поддельный заголовок.

В документации, которую я прочитал, говорится, что полученное Access-Control-Allow-Originзначение должно Originточно соответствовать значению, отправленному в запросе. Они совпали, поэтому я был удивлен, когда увидел в Chrome следующее сообщение:

XMLHttpRequest не загружается http://server.dev/test. Заголовок Access-Control-Allow-Origin имеет значение http://client1.dev , не равное указанному источнику. Происхождение http://client2.dev поэтому не допускается.

Документация, которую я прочитал, кажется неточной. На вкладке сети Chrome четко отображаются заголовки запроса и ответа http://client1.dev, но вы можете видеть в ошибке, что Chrome каким-то образом знает реальное происхождение http://client2.devи правильно отклоняет ответ. На данный момент это не имеет значения, потому что сервер уже принял поддельный запрос и потратил мои деньги.

Просто скромное завершение:

В: Применяется ли политика одинакового происхождения (SOP) только в браузерах?
A: Да. Для всех вызовов, которые вы делаете внутри браузера, браузер определенно применяет СОП. Сервер может или не может проверить источник запроса.

В: Если запрос не соответствует SOP, блокирует ли его браузер?
О: Нет, это вне компетенции браузеров. Браузеры просто отправляют запросы с перекрестным происхождением и ждут ответа, чтобы убедиться, что сервер сообщает о правомерности вызова через Access-Controlзаголовки - *. Если сервер не отправляет обратно Access-Control-Allow-Originзаголовок, не отображает происхождение вызывающего абонента или не отправляет обратно *в заголовке, то все, что будет делать браузер, - это воздерживаться от предоставления ответа вызывающему.

В: Означает ли это, что я не могу обманывать Origin?
О: В браузере и с использованием сценариев вы не можете переопределить, так Originкак это находится под контролем браузера. Однако, если вы хотите взломать себя, вы можете вмешаться в звонки, исходящие из ВАШЕГО браузера, с помощью расширений браузера или других инструментов, установленных на вашем компьютере. Вы также можете оформить HTTPзвонки , используя curl, Python, C#и т.д. , и изменить Originзаголовок трюк серверов.

В: Значит, если я могу обмануть сервер, изменив Originего, значит ли это, что он CORSнебезопасен?
A: CORS по сути ничего не говорит о безопасности - т.е. аутентификации и авторизации запросов. Серверы должны проверять запросы и аутентифицировать / авторизовать их с помощью любого механизма, с которым они работают, например файлов cookie и заголовков. Сказав это, он может защитить нас немного больше в случае атак типа XSS:

Пример. Допустим, вы вошли на свой веб-сайт, и вредоносный скрипт пытается отправить запрос на веб-сайт вашего банка, чтобы узнать ваш баланс: отраженная XSS- атака. Веб-сайт вашего банка доверяет учетным данным, исходящим (здесь от имени) вашего веб-сайта, поэтому запрос проходит проверку подлинности и HTTPвыдается ответ, нацеленный на вредоносный код. Если веб-сайт вашего банка не заботится о том, чтобы делиться своими конечными точками с другими источниками, он не включаетAccess-Control-Allow-Originзаголовок в ответе. Теперь, по прибытии запроса, браузер понимает, что запрос был запросом Cross Origins, но ответ не показывает, что сервер был счастлив поделиться ресурсом (здесь конечная точка запроса баланса) с вашим веб-сайтом. Таким образом, он прерывает поток, поэтому возвращаемый результат никогда не дойдет до вредоносного кода.