Эксклюзивно для codeby.net продолжаю публиковать перевод ресерчей по книге 2021 года от Brandon Wieser The Hackers Codex: Modern Web Application Attacks Demystified.
На этот раз о способах обхода проверок хэдера Origin, в основном через колдовство с доменом.
ORIGIN REFLECTION ATTACKS
Регулярные выражения
Теперь, когда у нас есть базовое представление о CORS и о том, как использовать распространенную мисконфигурацию, мы можем начать атаковать другие конфигурации. Другая распространенная реализация - проверка origin регулярным выражением этот подход может быть опасен, если выполняется без должной степени осмотрительности.
Представьте, что разработчик хочет разрешить междоменный доступ с test.com, любому поддомену test.com с любых портов в этих поддоменах. Например, для этого может быть использована нижеприведенная конфигурация Apache:
Хотя это может показаться надежным решением, существует исключение, которое может обходить регулярное выражение. Например, домен https://test.com$.attacker.com обойдет проверку регулярного выражения. На первый взгляд кажется, что злоумышленник не будет использовать такой домен; однако исследователи из команды corben.io нашли
Чтобы понять, как команда corben.io обошла проверку регулярным выражением, сначала нам нужно понять ключевую деталь о браузерах, особенно Safari. Safari не проверяет синтаксис или символы используемые в именах доменов. Например, если конечный пользователь Safari пытается просмотреть домен «testi = ng#*.tes`t+.com» Safari попытается загрузить эту страницу.
Во-вторых, нам нужно выяснить, как настроить субдомен, который заканчивается специальным символом. В нашем примере нам нужно создать поддомен «test.com$» для домена attacker.com. Это проще чем звучит из-за спец.символьных записей DNS (wildcard DNS records).
Спец.символьная запись DNS - это запись, которая отвечает на запросы DNS для всех субдоменов - даже тех, которые не были определены. В принципе, мы можем создать такую DNS-запись для attacker.com, которая будет направлять все поддомены на IP-адрес VPS, на которой размещен домен attacker.com. Как следует из названия, это делается с помощью специального символа «*». После конфигурации, когда конечный пользователь Safari, попытается перейти на https://test.com$.attacker.com, запись DNS свяжет имя домена с IP-адресом attacker.com.
Последняя часть информации, необходимой для организации атаки, - это использование технологии веб-сервера, которая будет размещать субдомены со специальными символами. Несмотря на то, что Safari будет обращаться к этим доменам, Apache и Nginx (без модификации) не будут обслуживать контент из спец.символьных доменов. NodeJS не имеет такой проблемы и будет обслуживать контент без каких-либо дополнительных конфигураций. Поэтому рекомендуется, чтобы злоумышленник использовал вредоносный код на JavaScript на веб-сервере с NodeJS, если конечно он не хочет изменять исходный код под другую технологию веб-сервера.
Юрий имеет все необходимое для атаки и выполняет следующие действия:
1) Покупает VPS и доменное имя.
2) Настраивает спец.символьную запись DNS, которая указывает всем поддоменам домена, приобретенного на шаге 1, на IP-адрес VPS.
3) Устанавливает и настраивает NodeJS на VPS.
4) Размещает вредоносный файл JavaScript
5) Убеждает жертву посетить вредоносный субдомен, содержащий специальный символ, например «_» (который будет работать в Firefox, Chrome и Safari). Это перенаправит жертву на ваш VPS из-за спец.символьной записи DNS, которая была создана на шаге 1, без изменения заголовка Origin.
Как в примере с https://test.com$.attacker.com.
Существует отличный инструмент для проверки мисконфигурации CORS, в том числе небезопасной конфигурации заголовков, небезопасного использования «нулевых» origin, обход поддоменов, специальные символы, разрешенные в субдомене и т. д. Их можно найти по ссылки ниже:
github.com
github.com
Кроме того, в таблице ниже показано, какие специальные символы в доменном имени поддерживаются каждым браузером:
Посмотреть вложение 49610
В таблице выше показано, что использование символа нижнего подчеркивания (_) должно работать во всех браузерах.
******
Прежде чем перейти к следующему разделу, автор предлагает быстро рассмотреть типичную мисконфигурацию, которую нельзя использовать из-за того, что веб-браузеры препятствуют запросу. Иногда при выполнении тестов на проникновение тестировщик может столкнуться с конфигурацией заголовка CORS, в которой для значения заголовка ответа Access-Control-Allow-Origin установлено значение «*» (все домены) в дополнение к значению заголовка Access-Control-Allow-Credentials. установите значение «true», как показано на рисунке ниже.
Посмотреть вложение 49611
Пентестер может подумать, что такая конфигурация позволит вредоносному скрипту, описанному в предыдущей главе, размещенному на любом домене, читать ответы аутентифицированных жертв. К счастью, все основные веб-браузеры откажутся соблюдать небезопасную конфигурацию.
Например, в документации разработчика Firefox
Кроме того, если для заголовка Access-Control-Allow-Origin задано значение «*», а Access-Control-Allow-Credentials отсутствует в response, то это, скорее всего, не является серьезной уязвимостью. См. перехваченный ответ ниже:
Посмотреть вложение 49612
По сути, заголовок позволяет всем доменам взаимодействовать с ответом; однако, ни один браузер не предоставит учетные данные для доступа к ресурсу. Это означает, что невозможно получить конфиденциальную информацию, относящуюся к конкретному пользователю.
Если бы страница содержала конфиденциальную информацию, к которой злоумышленник мог бы получить доступ, даже без заголовка CORS, можно было бы получить доступ к этой информации в любом случае и, вероятно, это было бы раскрытием конфиденциальной информации, а не неправильной конфигурацией CORS.
Если заголовок Access-Control-Allow-Origin используется, убедитесь, что в ответе не содержится конфиденциальной информации. Если его нет, тогда конфигурация не предлагает возможностей для эксплоита.
*******
Атака на поддомены
Теперь, когда мы знаем несколько способов обхода регулярные выражения, и у нас есть некоторые инструменты, которые позволяют нам быстро идентифицировать и обходить их, давайте атакуем регулярное выражение, которое работает правильно и не обходится.
Например, представим, что мы натолкнулись на регулярное выражение, которое проверяет, исходит ли запрашивающий источник (origin) из поддомена уязвимого домена. Мы не можем найти способ обойти проверку и она кажется надежной. Что мы можем сделать? Есть два основных вектора атаки:
• Захват поддомена
• Межсайтовый скриптинг (XSS)
Обе эти атаки сами по себе чрезвычайно опасны; однако, комбинируя одну из них со смягченной SOP (same origin policy, политикой единого источника) из реализации CORS, делает их смертельными. Причина в том, что все атаки, перечисленные в предыдущем подразделе, снова становятся возможными против домена. Таким образом, возможна утечка любых конфиденциальных данных в любом ответе, к которому имеют доступ аутентифицированные пользователи. Также возможно заставить любого аутентифицированного пользователя выполнять действия в любом домене, для которого действителен его сеанс. Причина в том, что злоумышленник может прочитать токен CSRF из ответа и затем отправить его во вредоносном запросе.
Чтобы продемонстрировать это, представим, что в домене и поддомене размещены два веб-приложения. Приложение «Альфа» на сайте alpha.com и приложение «Блог» на сайте blog.alpha.com. Давайте представим, что Alpha выполняет проверку на стороне сервера (в файле конфигурации Apache или другом коде на стороне сервера), который использует регулярное выражение для проверки того, что значение заголовка Origin поступает из любого поддомена alpha.com (например, * .alpha.com ), который будет включать blog.alpha.com.
Регулярное выражение может выглядеть следующим образом (
Если проверка прошла успешно, приложение отвечает заголовками CORS, чтобы ослабить политику SOP для поддомена, из которого пришел запрос. В частности, значение request (запрос) заголовка Origin отражается (помещается) в response (ответ) заголовке «Access-Control-Allow-Origin». Кроме того, для заголовка Access-Control-Allow-Credentials устанавливается значение «true», чтобы прошедшие проверку пользователи могли получить доступ к некоторым типам конфиденциальных данных.
В случае запроса, поступающего с blog.alpha.com на alpha.com, обмен может выглядеть следующим образом:
Посмотреть вложение 49613
Посмотреть вложение 49614
Псевдонимы домена (Domain Aliasing)
Прежде чем мы продолжим, нам понадобится некоторая справочная информация о псевдонимах доменов (alias, алиас) и CNAMEs. По сути, псевдонимы домена и CNAMEs позволяют записи домена перенаправлять на другой ресурс. Хотя между ними есть некоторые различия, этого определения будет достаточно для наших нужд.
Псевдонимы домена и CNAMEs чрезвычайно полезны при использовании облачных сервисов и популярных хостинговых услуг. Например, представьте, что организация ведет блог на WordPress. Они не хотят, чтобы конечные пользователи переходили на companyname.wordpress.com. Вместо этого они хотят, чтобы пользователи посещали blog.companyname.com. Это можно сделать с помощью CNAME.
Что произойдет, если подписка, приобретенная на WordPress, истечет или будет удалена или перемещена без удаления записи CNAME? Запись CNAME будет указывать на просроченный веб-сервис. Если злоумышленник зарегистрирует имя в службе (в данном случае WordPress), то субдомен компании (blog.companyname.com) будет перенаправлять пользователей на страницу злоумышленника. Это серьезно, потому что злоумышленник может выполнять такие атаки, как фишинг, XSS и т. д .; однако в случае CORS это еще более критично.
Несколько сервисов могут быть уязвимы для этой атаки, включая корзины Amazon S3, DigitalOcean, WordPress, Github и, возможно, сотни других сервисов. Чтобы получить хороший ресурс потенциально уязвимых сервисов, взгляните на следующий проект GitHub:
EdOverflow/can-i-take-over-xyz
List of specific sub-domains seen as CNAMEs · Issue #26 · EdOverflow/can-i-take-over-xyz
Как правило, если вы перейдете в веб-браузере к CNAME с потенциально истекшим сроком действия, сервер ответит сообщением об ошибке 404. В случае WordPress ответ будет содержать «Вы хотите зарегистрировать * .wordpress.com?» как видно на скриншоте ниже:
Посмотреть вложение 49609
Поиск просроченных CNAME
Исследователи и баг-хантеры создали несколько инструментов для поиска поддоменов с истекшим сроком действия. Я рекомендую посмотреть следующие инструменты и однострочный bash-скрипт:
OWASP/Amass
aboul3la/Sublist3r
ProjectAnte/dnsgen
assetnote/commonspeak2
rivermont/spidy
michenriksen/aquatone
FortyNorthSecurity/EyeWitness
for line in $(cat subdomains.txt); do host $line |grep alias |cut -d " " -f1; done
По сути, примерный план атаки Юрия может выглядеть следующим образом:
1. Использует веб-спайдера, например spidy, для сканирования главной веб-страницы домена веб-приложения.
2. Сохраняет все ссылки на поддомены и слова, найденные при сканировании, в текстовый файл.
3. Использует такие инструменты, как Amass и Sublist3r, для пассивного и активного перечисления поддоменов.
4. Использует инструмент dnsgen со списком слов commonspeak2, чтобы создать список слов для возможных доменов.
5. Выполняет DNS брутфорс с помощью Amass или Sublist3r со списком, созданным на шаге 4, и словами из текстового файла, созданного на шаге 2.
6. Объединяет все обнаруженные поддомены в файл с именем «subdomains.txt».
7. Запускает следующий сценарий bash и сохраняет вывод в файл с именем alias.txt:
for line in $(cat subdomains.txt); do host $line |grep alias |cut -d " " -f1; done
8. Использует такой инструмент, как Eyewitness, для навигации в веб-браузере и создания скриншотов со списком обнаруженных псевдонимов доменов.
9. Если на снимке экрана видно, что срок действия домена истек, сравнивает сообщение с фингерпринтами, указанными в: EdOverflow/can-i-take-over-xyz
10. Если срок действия сервиса истек, создает учетную запись и пытается приобрести имя домена с истекшим сроком действия. Как описано на https://github.com/EdOverflow/can-i-take-over- xyz # all-entries.
11. Размещает вредоносный файл JavaScript на новом поддомене.
12. Побуждает жертв посетить поддомен, и из-за конфигурации CORS обходит SOP, позволяя своему поддомену получить доступ к конфиденциальной информации.
На этот раз о способах обхода проверок хэдера Origin, в основном через колдовство с доменом.
- Html Injection
- Host Header Injection
- Username Enumeration – SSN
- Same Origin Policy и Exploiting CORS Misconfigurations
- Origin Reflection Attacks
- CSRF
- CSRF Bypass – Clickjacking Drag and Drop
- Redirection Bugs
- XSS – Cross-Site Scripting
- Identifying XSS Vulnerabilities
- JSONP
- Language-Specific XSS
- SOME Attacks
- CSV Injection
- HTTP Desync
- Web Cache Poisoning
ORIGIN REFLECTION ATTACKS
Регулярные выражения
Теперь, когда у нас есть базовое представление о CORS и о том, как использовать распространенную мисконфигурацию, мы можем начать атаковать другие конфигурации. Другая распространенная реализация - проверка origin регулярным выражением этот подход может быть опасен, если выполняется без должной степени осмотрительности.
Представьте, что разработчик хочет разрешить междоменный доступ с test.com, любому поддомену test.com с любых портов в этих поддоменах. Например, для этого может быть использована нижеприведенная конфигурация Apache:
Хотя это может показаться надежным решением, существует исключение, которое может обходить регулярное выражение. Например, домен https://test.com$.attacker.com обойдет проверку регулярного выражения. На первый взгляд кажется, что злоумышленник не будет использовать такой домен; однако исследователи из команды corben.io нашли
Ссылка скрыта от гостей
.Чтобы понять, как команда corben.io обошла проверку регулярным выражением, сначала нам нужно понять ключевую деталь о браузерах, особенно Safari. Safari не проверяет синтаксис или символы используемые в именах доменов. Например, если конечный пользователь Safari пытается просмотреть домен «testi = ng#*.tes`t+.com» Safari попытается загрузить эту страницу.
Во-вторых, нам нужно выяснить, как настроить субдомен, который заканчивается специальным символом. В нашем примере нам нужно создать поддомен «test.com$» для домена attacker.com. Это проще чем звучит из-за спец.символьных записей DNS (wildcard DNS records).
Спец.символьная запись DNS - это запись, которая отвечает на запросы DNS для всех субдоменов - даже тех, которые не были определены. В принципе, мы можем создать такую DNS-запись для attacker.com, которая будет направлять все поддомены на IP-адрес VPS, на которой размещен домен attacker.com. Как следует из названия, это делается с помощью специального символа «*». После конфигурации, когда конечный пользователь Safari, попытается перейти на https://test.com$.attacker.com, запись DNS свяжет имя домена с IP-адресом attacker.com.
Ссылка скрыта от гостей
Ссылка скрыта от гостей
Последняя часть информации, необходимой для организации атаки, - это использование технологии веб-сервера, которая будет размещать субдомены со специальными символами. Несмотря на то, что Safari будет обращаться к этим доменам, Apache и Nginx (без модификации) не будут обслуживать контент из спец.символьных доменов. NodeJS не имеет такой проблемы и будет обслуживать контент без каких-либо дополнительных конфигураций. Поэтому рекомендуется, чтобы злоумышленник использовал вредоносный код на JavaScript на веб-сервере с NodeJS, если конечно он не хочет изменять исходный код под другую технологию веб-сервера.
Юрий имеет все необходимое для атаки и выполняет следующие действия:
1) Покупает VPS и доменное имя.
2) Настраивает спец.символьную запись DNS, которая указывает всем поддоменам домена, приобретенного на шаге 1, на IP-адрес VPS.
3) Устанавливает и настраивает NodeJS на VPS.
4) Размещает вредоносный файл JavaScript
5) Убеждает жертву посетить вредоносный субдомен, содержащий специальный символ, например «_» (который будет работать в Firefox, Chrome и Safari). Это перенаправит жертву на ваш VPS из-за спец.символьной записи DNS, которая была создана на шаге 1, без изменения заголовка Origin.
Как в примере с https://test.com$.attacker.com.
Существует отличный инструмент для проверки мисконфигурации CORS, в том числе небезопасной конфигурации заголовков, небезопасного использования «нулевых» origin, обход поддоменов, специальные символы, разрешенные в субдомене и т. д. Их можно найти по ссылки ниже:
GitHub - lc/theftfuzzer: TheftFuzzer is a tool that fuzzes Cross-Origin Resource Sharing implementations for common misconfigurations.
TheftFuzzer is a tool that fuzzes Cross-Origin Resource Sharing implementations for common misconfigurations. - lc/theftfuzzer
github.com
GitHub - chenjj/CORScanner: 🎯 Fast CORS misconfiguration vulnerabilities scanner
🎯 Fast CORS misconfiguration vulnerabilities scanner - chenjj/CORScanner
github.com
Кроме того, в таблице ниже показано, какие специальные символы в доменном имени поддерживаются каждым браузером:
Посмотреть вложение 49610
В таблице выше показано, что использование символа нижнего подчеркивания (_) должно работать во всех браузерах.
******
Прежде чем перейти к следующему разделу, автор предлагает быстро рассмотреть типичную мисконфигурацию, которую нельзя использовать из-за того, что веб-браузеры препятствуют запросу. Иногда при выполнении тестов на проникновение тестировщик может столкнуться с конфигурацией заголовка CORS, в которой для значения заголовка ответа Access-Control-Allow-Origin установлено значение «*» (все домены) в дополнение к значению заголовка Access-Control-Allow-Credentials. установите значение «true», как показано на рисунке ниже.
Посмотреть вложение 49611
Пентестер может подумать, что такая конфигурация позволит вредоносному скрипту, описанному в предыдущей главе, размещенному на любом домене, читать ответы аутентифицированных жертв. К счастью, все основные веб-браузеры откажутся соблюдать небезопасную конфигурацию.
Например, в документации разработчика Firefox
Ссылка скрыта от гостей
: «Для запросов без учетных данных можно использовать специальный символ «*»; это значение указывает браузерам на использование кода запроса из любого источника (origin) для доступа к ресурсу. Однако, попытка использовать этот подстановочный знак к запросу с учетными данными приведет к ошибке».Кроме того, если для заголовка Access-Control-Allow-Origin задано значение «*», а Access-Control-Allow-Credentials отсутствует в response, то это, скорее всего, не является серьезной уязвимостью. См. перехваченный ответ ниже:
Посмотреть вложение 49612
По сути, заголовок позволяет всем доменам взаимодействовать с ответом; однако, ни один браузер не предоставит учетные данные для доступа к ресурсу. Это означает, что невозможно получить конфиденциальную информацию, относящуюся к конкретному пользователю.
Если бы страница содержала конфиденциальную информацию, к которой злоумышленник мог бы получить доступ, даже без заголовка CORS, можно было бы получить доступ к этой информации в любом случае и, вероятно, это было бы раскрытием конфиденциальной информации, а не неправильной конфигурацией CORS.
Если заголовок Access-Control-Allow-Origin используется, убедитесь, что в ответе не содержится конфиденциальной информации. Если его нет, тогда конфигурация не предлагает возможностей для эксплоита.
*******
Атака на поддомены
Теперь, когда мы знаем несколько способов обхода регулярные выражения, и у нас есть некоторые инструменты, которые позволяют нам быстро идентифицировать и обходить их, давайте атакуем регулярное выражение, которое работает правильно и не обходится.
Например, представим, что мы натолкнулись на регулярное выражение, которое проверяет, исходит ли запрашивающий источник (origin) из поддомена уязвимого домена. Мы не можем найти способ обойти проверку и она кажется надежной. Что мы можем сделать? Есть два основных вектора атаки:
• Захват поддомена
• Межсайтовый скриптинг (XSS)
Обе эти атаки сами по себе чрезвычайно опасны; однако, комбинируя одну из них со смягченной SOP (same origin policy, политикой единого источника) из реализации CORS, делает их смертельными. Причина в том, что все атаки, перечисленные в предыдущем подразделе, снова становятся возможными против домена. Таким образом, возможна утечка любых конфиденциальных данных в любом ответе, к которому имеют доступ аутентифицированные пользователи. Также возможно заставить любого аутентифицированного пользователя выполнять действия в любом домене, для которого действителен его сеанс. Причина в том, что злоумышленник может прочитать токен CSRF из ответа и затем отправить его во вредоносном запросе.
Чтобы продемонстрировать это, представим, что в домене и поддомене размещены два веб-приложения. Приложение «Альфа» на сайте alpha.com и приложение «Блог» на сайте blog.alpha.com. Давайте представим, что Alpha выполняет проверку на стороне сервера (в файле конфигурации Apache или другом коде на стороне сервера), который использует регулярное выражение для проверки того, что значение заголовка Origin поступает из любого поддомена alpha.com (например, * .alpha.com ), который будет включать blog.alpha.com.
Регулярное выражение может выглядеть следующим образом (
Ссылка скрыта от гостей
): ^https?:\/\/(.*\.)?alpha\.com$Если проверка прошла успешно, приложение отвечает заголовками CORS, чтобы ослабить политику SOP для поддомена, из которого пришел запрос. В частности, значение request (запрос) заголовка Origin отражается (помещается) в response (ответ) заголовке «Access-Control-Allow-Origin». Кроме того, для заголовка Access-Control-Allow-Credentials устанавливается значение «true», чтобы прошедшие проверку пользователи могли получить доступ к некоторым типам конфиденциальных данных.
В случае запроса, поступающего с blog.alpha.com на alpha.com, обмен может выглядеть следующим образом:
Посмотреть вложение 49613
Посмотреть вложение 49614
Псевдонимы домена (Domain Aliasing)
Прежде чем мы продолжим, нам понадобится некоторая справочная информация о псевдонимах доменов (alias, алиас) и CNAMEs. По сути, псевдонимы домена и CNAMEs позволяют записи домена перенаправлять на другой ресурс. Хотя между ними есть некоторые различия, этого определения будет достаточно для наших нужд.
Псевдонимы домена и CNAMEs чрезвычайно полезны при использовании облачных сервисов и популярных хостинговых услуг. Например, представьте, что организация ведет блог на WordPress. Они не хотят, чтобы конечные пользователи переходили на companyname.wordpress.com. Вместо этого они хотят, чтобы пользователи посещали blog.companyname.com. Это можно сделать с помощью CNAME.
Что произойдет, если подписка, приобретенная на WordPress, истечет или будет удалена или перемещена без удаления записи CNAME? Запись CNAME будет указывать на просроченный веб-сервис. Если злоумышленник зарегистрирует имя в службе (в данном случае WordPress), то субдомен компании (blog.companyname.com) будет перенаправлять пользователей на страницу злоумышленника. Это серьезно, потому что злоумышленник может выполнять такие атаки, как фишинг, XSS и т. д .; однако в случае CORS это еще более критично.
Несколько сервисов могут быть уязвимы для этой атаки, включая корзины Amazon S3, DigitalOcean, WordPress, Github и, возможно, сотни других сервисов. Чтобы получить хороший ресурс потенциально уязвимых сервисов, взгляните на следующий проект GitHub:
EdOverflow/can-i-take-over-xyz
List of specific sub-domains seen as CNAMEs · Issue #26 · EdOverflow/can-i-take-over-xyz
Как правило, если вы перейдете в веб-браузере к CNAME с потенциально истекшим сроком действия, сервер ответит сообщением об ошибке 404. В случае WordPress ответ будет содержать «Вы хотите зарегистрировать * .wordpress.com?» как видно на скриншоте ниже:
Посмотреть вложение 49609
Поиск просроченных CNAME
Исследователи и баг-хантеры создали несколько инструментов для поиска поддоменов с истекшим сроком действия. Я рекомендую посмотреть следующие инструменты и однострочный bash-скрипт:
OWASP/Amass
aboul3la/Sublist3r
ProjectAnte/dnsgen
assetnote/commonspeak2
rivermont/spidy
michenriksen/aquatone
FortyNorthSecurity/EyeWitness
for line in $(cat subdomains.txt); do host $line |grep alias |cut -d " " -f1; done
По сути, примерный план атаки Юрия может выглядеть следующим образом:
1. Использует веб-спайдера, например spidy, для сканирования главной веб-страницы домена веб-приложения.
2. Сохраняет все ссылки на поддомены и слова, найденные при сканировании, в текстовый файл.
3. Использует такие инструменты, как Amass и Sublist3r, для пассивного и активного перечисления поддоменов.
4. Использует инструмент dnsgen со списком слов commonspeak2, чтобы создать список слов для возможных доменов.
5. Выполняет DNS брутфорс с помощью Amass или Sublist3r со списком, созданным на шаге 4, и словами из текстового файла, созданного на шаге 2.
6. Объединяет все обнаруженные поддомены в файл с именем «subdomains.txt».
7. Запускает следующий сценарий bash и сохраняет вывод в файл с именем alias.txt:
for line in $(cat subdomains.txt); do host $line |grep alias |cut -d " " -f1; done
8. Использует такой инструмент, как Eyewitness, для навигации в веб-браузере и создания скриншотов со списком обнаруженных псевдонимов доменов.
9. Если на снимке экрана видно, что срок действия домена истек, сравнивает сообщение с фингерпринтами, указанными в: EdOverflow/can-i-take-over-xyz
10. Если срок действия сервиса истек, создает учетную запись и пытается приобрести имя домена с истекшим сроком действия. Как описано на https://github.com/EdOverflow/can-i-take-over- xyz # all-entries.
11. Размещает вредоносный файл JavaScript на новом поддомене.
12. Побуждает жертв посетить поддомен, и из-за конфигурации CORS обходит SOP, позволяя своему поддомену получить доступ к конфиденциальной информации.
Последнее редактирование:
