Часть 1. Предисловие

Уязвимость междоменного совместного использования ресурсов CORS аналогична уязвимости перехвата JSONP.,Программисты внесли неправильные настройки при решении междоменных задач. Злоумышленники могут использовать веб-приложения для небрежной проверки заголовка Origin пакетов пользовательских запросов.,Обманом заставить жертву посетить вредоносный веб-сайт, созданный злоумышленником.,Тем самым мы получаем конфиденциальные данные жертвы в разных доменах, включая записи о переводах, записи транзакций, информацию о личном идентификационном номере, информацию о заказах и т. д.。

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

1. Что такое уязвимость CORS?

2. При каких обстоятельствах уязвимости CORS являются уязвимостями высокого риска? При каких обстоятельствах уязвимости CORS безвредны?

3. Как эксплуатировать уязвимость CORS?

4. Рекомендации по исправлению уязвимостей CORS?

много друзейДумать, что веб-приложение возвращает Access-Control-Allow-Origin: *, означает наличие уязвимости. На самом деле это суждение несовершенно.。Этот вопросABC_123Я написал один самJavaтестовая среда,Позвольте мне продемонстрировать вам процесс воспроизведения и использования уязвимости CORS.,Я думаю, каждый поймет это с первого взгляда.

Результаты теста уязвимости CORS части 2

Сначала приведены результаты испытаний ABC_123.,Следующие выводы — это выводы, которые я сделал, когда писал собственный Java-код для создания среды для тестирования.,Приглашаем всех критиковать и исправлять。Первое использованиеburpsuiteПара захвата пакетовhttpПросьба добавитьOrigin: http://www.attacker.comтест：

1 Если заголовок возврата следующий, это уязвимость высокого риска. В этом случае лучше всего использовать уязвимость:

Access-Control-Allow-Origin: https://www.attacker.com

Access-Control-Allow-Credentials: true

2 Если возвращаемый заголовок имеет следующий вид, его также можно считать уязвимостью высокого риска, но его сложнее эксплуатировать:

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

3 Если возвращается следующее, уязвимость не существует, поскольку для существования уязвимости значение Null должно быть в нижнем регистре:

Access-Control-Allow-Origin: Null

Access-Control-Allow-Credentials: true

4 Если возвращается следующее, можно считать, что уязвимости нет, поскольку в этом случае механизм безопасности CORS предотвращает эксплуатацию уязвимости, а также могут быть записаны ошибки конфигурации CORS с низким уровнем риска.

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

5 Если возвращается следующее, можно считать, что уязвимости нет, и также может быть записана ошибка конфигурации CORS с низким уровнем риска.

Access-Control-Allow-Origin: *

Часть 3: Повторение междоменной уязвимости CORS

• Процесс тестирования общих уязвимостей CORS

Сначала просмотрите традиционный процесс тестирования уязвимостей CORS: возьмите пакет HTTP-запроса, который может возвращать конфиденциальные личные данные, добавьте Origin: http://www.xxx.com и проверьте, содержит ли заголовок возврата «Access-Control-Allow-Origin». « : *», «Access-Control-Allow-Credentials: true», здесь следует отметить: если эти два заголовка существуют в возвращаемом пакете одновременно, то на самом деле он не имеет уязвимости CORS. Далее, в соответствии с разными возвращаемыми значениями Access-Control-Allow-Origin и Access-Control-Allow-Credentials, напишите Java-код, чтобы проверить, можно ли получить конфиденциальные данные, и все поймут.

• Написание тестов Java-кода

Затем я написал два кода сервлетов на Java для имитации веб-сайта покупок в Интернете и использовал интерфейсный код JS для имитации HTML-страницы эксплойта уязвимости CORS, созданной злоумышленником.

Как показано ниже, первым является код сервлета интерфейса входа в систему.

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

Затем пользователь посещает страницу PersonInfo, http://192.168.237.1:9999/Servlet/PersonInfo, и пароль транзакции — 123456.

Код Sevlet PersonInfo, соответствующий этой странице, выглядит следующим образом:

Далее, чтобы получить пароль транзакции пользователя торгового сайта, злоумышленник,Следующая страница Attack.html тщательно создана и размещена на веб-сервере.,Атака в это времяURLдаhttp://www.attacker111.com/attack.html。Злоумышленник использует этоURLОтправить жертве на просмотр,Будет получен пароль транзакции жертвы.

• Случай 1:

Давайте сначала рассмотрим первый случай. Сервер возвращает следующий заголовок сообщения. В этом случае его очень легко использовать, поэтому уязвимость оценивается как высокий риск:

Access-Control-Allow-Origin: https://www.attacker.com

Access-Control-Allow-Credentials: true

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

После того как жертва получает доступ к URL-адресу, созданному злоумышленником, она успешно получает конфиденциальные данные пользователя.

F12 проверил запрос, отправленный браузером, и обнаружил, что он содержит файлы cookie, что позволяет успешно обойти междоменные ограничения одного и того же происхождения.

• Случай 2:

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

Access-Control-Allow-Origin: null

Access-Control-Allow-Credentials: true

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

В это время я посетил http://192.168.237.199/attack.html и обнаружил, что браузер выдал ошибку политики CORS.

Потому что Origin в это время не равен нулю

Здесь нам нужно найти способ сделать Origin равным нулю, чтобы злоумышленник сконструировал следующий js-код:

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

• Случай 3:

Сервер возвращает следующий заголовок сообщения: В этом случае уязвимости на самом деле нет. Если вам нужно сказать, что уязвимость есть, вы можете договориться об ошибке конфигурации CORS. В конце концов, установка * сама по себе проблематична.

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

Соответствующий Java-код выглядит следующим образом:

Посетив http://www.attacker111.com/attack.html, выяснилось, что браузер напрямую сообщил об ошибке. Похоже, что такая ситуация вообще не разрешена политикой безопасности.

• Случай 4:

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

Access-Control-Allow-Origin：*

• Результаты тестирования браузера Chrome

Затем я протестировал последнюю версию Google Chrome и обнаружил, что она успешно обходит политику одного и того же источника и инициирует междоменный запрос. Однако браузер Chrome не отправлял файлы cookie для запроса, поэтому уязвимость была ограничена.

Рекомендации по исправлению части 4

1. Источником, указанным в Access-Control-Allow-Origin, могут быть только доверенные сайты. Избегайте использования Access-Control-Allow-Origin: *, избегайте использования Access-Control-Allow-Origin: null, иначе злоумышленник может подделать запросы к источникам для кражи междоменных ресурсов.

2. Строго проверяйте значение «Origin», а регулярное выражение для проверки должно быть хорошо написано, чтобы избежать обходов.

3. Уменьшите количество методов запроса, разрешенных «Access-Control-Allow-Methods».

4. Помимо правильной настройки CORS, веб-серверы должны продолжать защищать конфиденциальные данные, такие как аутентификация и управление сеансами.