Возникают проблемы с пониманием того, как этот эксплойт CORS для любого источника делает сайт уязвимым - PullRequest
0 голосов
/ 04 ноября 2019

Я работаю над API авторизации, который моя компания хотела бы использовать как внутри, так и в качестве внешнего API для некоторых наших клиентов. Мы бы предпочли не вносить в белый список все домены, из которых может исходить запрос, но это, по-видимому, поведение веб-браузеров по умолчанию, предназначенное для принудительного применения, когда параметр XHR withCredentials равен true.

Мы можем обойти эту проблему, заставив наш API возвращать то, что заголовок Origin запроса содержит в качестве значения Access-Control-Allow-Origin заголовка ответа API, но это, очевидно, то, что якобы настолько опасно, поэтому яне уверен, что мы должны делать это. Может быть, в нашей ситуации это совершенно безопасно, но я не могу понять природу потенциальной атаки, пока не могу сказать.

Согласно этой статье:

https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties

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

Но как? Для меня статья не проясняет это.

Есть ли какая-то другая уязвимость помимо проблемы CORS, которая необходима? Глядя на примеры, PDF слайд-презентации, которая идет вместе со статьей, и ссылочную статью на http://ejj.io/misconfigured-cors/, Я не до конца понимаю, где доступ к информации или учетным данным какого-либо другого пользователя проскальзывает в изображение.

CORS attack diagram

На приведенной выше схеме мне кажется, что «evil.com» каким-то образом обманом заставил бы пользователя обменять биткойны на evil.com. сначала проверять учетные данные, прежде чем CORS войдет в картину, и если evil.com может сделать это уже, разве проблема CORS только не усугубит и без того очень плохую ситуацию?

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

Есть ли что-то, где, скажем, просто иметьодна страница браузера, открытая для evil.com, когда пользователь также посещает биржу биткойнов, позволяет передавать данные cookie-файлов на evil.com? Похоже, это тоже было бы большой проблемой, CORS или нет CORS.

1 Ответ

0 голосов
/ 05 ноября 2019

Я наконец-то понял, где риск, и мне пришлось самому разобраться. Возможно, все люди, объясняющие этот эксплойт CORS, думают, что их читатели автоматически узнают, что происходит с cookie-файлами в подобной ситуации, и не думают, что это даже стоит упомянуть.

Это определенно помогло бы мне, если бы ониОднако упомянул об этом!

Теперь я понимаю следующее:

  1. Вы настроили API на myservice.com, который разрешает доступ к CORS, и позволяет любому пользователю из любого домена ви он отвечает на запросы XHR, где withCredentials равен true с происхождением хоста, отраженным обратно в заголовке Access-Control-Accept-Origin, вместо отправки обратно *.
  2. пользователя на mylegitapicustomer.com, которыйзаконно использует myservice.com, входит в ваш API и возвращает сессионный cookie, принадлежащий домену myservice.com.
  3. Этот пользователь, используя тот же веб-браузер, затем посещает evilhacker.com.
  4. Если веб-страница evilhacker.com отправляет запрос XHR на myservice.com, все файлы cookie, принадлежащие домену myservice.com, отправляются вместе. за поездку!
  5. Ваш веб-сайт myservice.com видит файл cookie сеанса, который он выдал законному пользователю, посетившему сайт mylegitapicustomer.com, и с радостью отвечает на вышеуказанный запрос, внося любые запрошенные изменения вУчетная запись пользователя, или отвечает любой информацией о запрошенном пользователе.
  6. evilhacker.com теперь может получать любую из этой информации и / или выполнять любые действия API, которые позволил бы законный доступ через mylegitapicustomer.com.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...