Эксклюзивно для codeby.net продолжаю публиковать перевод ресерчей по книге 2021 года от Brandon Wieser The Hackers Codex: Modern Web Application Attacks Demystified.
На этот раз немного поверхностной теории о защите браузеров. И пример использования Cross-Origin Resource Sharing
SAME ORIGIN POLICY
Прежде чем находить и эксплуатировать наши следующие баги, нам необходимо немного предыстории. Современные веб-браузеры не позволяют читать информацию через домены. Браузеры делают это, применяя
В общем, как следует из названия, правила SOP определяют не имеют ли два ресурса одно и то же «источник, происхождение» (origin). Например, в
Same origin policy – критически важный компонент Интернета, по сути, SOP это политика изоляции, реализуемая веб-браузерами. SOP решает на основе набора правил, является ли ресурс (документ, скрипт и т. д.) разрешенным для взаимодействия с другим ресурсом. Стоит уточнить, что соблюдение политики обеспечивается на, сторона клиента, а не сторона сервера.
В следующей таблице (взятой из приведенной выше ссылки от Mozilla) видим пример сравнения единого происхождения для ресурса
Если проверка происхождения завершилась неудачно, то веб-браузер, как правило, не разрешает двум ресурсам взаимодействовать друг с другом. В большинстве случаев браузер разрешает осуществлять request (запросы, реквест) на другой домен, но доступ к response (ответу, обратному отклику, респонз) не дает.
Без SOP документ, размещенный в одном домене, может читать и взаимодействовать с документами и отвечать на запросы, отправленные из других доменов. Представьте если у конечного пользователя есть валидные сессионные cookie, полученные после аутентификации в банковском приложении. Также представьте, что злоумышленник разместил файл JavaScript на веб-сервере. Если конечный пользователь переходит на сервер к злоумышленнику после посещения банковского сайта и в веб-браузере не реализована SOP, то веб-сервер злоумышленника может получить конфиденциальную информацию о банке жертвы и даже осуществить перевод средств со счета жертвы на банковский счет по выбору злоумышленника.
Изображение ниже – хороший пример того, как SOP, внедренная в браузер, блокирует домен злоумышленника от чтения чувствительной информации из банка:
Злоумышленники разработали несколько методов обхода SOP. Эта глава будет посвящена самому популярному и распространенному методу атаки - Cross-Site Scripting (XSS). Однако в этой главе мы рассмотрим другие методы такие как мисконфигурация CORS, подделка межсайтовых запросов (Cross-Site Request Forgery, CSRF), перехват субдоменов и атаки обратного вызова JSONP.
Cross-Origin Resourse Sharing (CORS, совместное использование ресурсов между источниками)
Современный веб – это сложное пространство. Во многих случаях разработчики и инженеры хотят взаимодействовать со скриптами across origin (через источники). Что происходит, когда разработчикам необходимо взаимодействовать с ресурсами разного origin (происхождения, источника), например с другого субдомена? Современные браузеры добавили поддержку хэдеров запросов и ответов, которые позволяют веб-приложению смягчить SOP веб-браузера. Эти хэдеры (заголовки) относятся к протоколу Cross-Origin Resource Sharing или «CORS». Спецификацию для этих заголовков можете найти здесь:
По сути, веб-приложения могут отправлять определенные response-заголовки, которые попросят клиента смягчить SOP для конкретного origin (источника). Это позволяет ресурсам (например, скриптам) взаимодействовать с ослабленными доменами. Как мы увидим далее в этой главе, если эти заголовки не настроены должным образом, то могут возникнуть катастрофические последствия, такие как раскрытие конфиденциальных данных или CSRF-атаки.
Эксплуатация мисконфигурации CORS
Origin Reflection (отражение заголовка Origin)
Теперь, когда у нас есть некоторая справочная информация об одной и той же политике происхождения и CORS, давайте вернемся в голову Юрия. Его скрипты по перебору SSN работают как часы, собирая тысячи потенциальных жертв кражи личных данных и номеров SSN, которые будут использоваться для подачи фальсифицированных налоговых деклараций.
Пока он ждет следующего налогового сезона, начальство хочет, чтобы он диверсифицировал потоки доходов банды. Они создали банковский троян, который запускается на персональных компьютерах и мобильных устройствах. Работает аналогично
Его босс поручил ему составить список состоятельных людей, которых можно использовать в целевых фишинговых и спам-кампаниях. Кроме этого, они не хотят, чтобы их недавно разработанный банковский троян был обнаружен антивирусными компаниями или исследователями вредоносного ПО хотя бы в течение нескольких лет. Банда решает следующее:
1. Убедиться, что у жертв достаточно денег для успешной атаки (повышение рентабельности, мать их етить, прим. переводчика).
2. Ограничив масштаб атаки, как можно дольше не попадаться ФБР, Интерполу, антивирусным компаниям и фирмам, занимающимся исследованиями в области безопасности.
3. Развить успех (количество установок зловреда), создавая более качественные предложения, основанные на социальной инженерии для каждой цели исходя из полученной информации.
Юрий знает, что ему нужно найти состоятельных людей, но не знает, как собрать такой список. Быстрый поиск в Google показывает, что диджитал маркетологи и другие продажники могут приобрести список у третьих лиц,
У этого подхода есть несколько недостатков. Во-первых, в этих списках очень ограниченная информация о перечисленных лицах. Хотя адрес электронной почты и номер телефона - хорошее начало и, скорее всего к чему-то приведет, он хочет более таргетированный список. Он хочет знать уровень дохода и любую информацию, которая может быть использована в качестве предлога для целевых атак. Во-вторых, список содержит более двух миллионов записей. Если спам-кампания нацелена на такое количество жертв, то вполне вероятно, что антивирусные компании и исследователи безопасности будут предупреждены, что приведет к мониторингу спам-кампании и ее блокировке - электронные письма быстро попадут в папку со спамом жертвы.
После нескольких часов размышлений Юрию приходит в голову мысля! Что, если он нацелится на компании, занимающиеся финансовым планированием и консультированием по инвестициям в Интернете? Обычно эти компании имеют более состоятельных людей в качестве клиентов, и более точную информацию, такую как уровень заработка, чистая прибыль, банки клиента, должность и другую финансовую информацию.
Обычно у этих компаний есть флагманское веб-приложения для использования клиентами, и многие предлагают бесплатную регистрацию или пробные предложения. Немного погуглив он натыкается на веб-приложение, которое может быть интересно и создает бесплатную учетную запись. При создании аккаунта запрашивается несколько деталей, таких как адрес электронной почты, номер телефона, уровень дохода, банковская информация, планируемый пенсионный возраст и информация по инвестированию (например, сколько наличных денег по сравнению с акциями и облигациями есть у человека). После настройки бесплатной учетной записи с тестовыми данными он переходит к странице «Your Money» и замечает, что отображаются его тестовые данные. Он настраивает Firefox использует прокси BurpSuite и обновляет домашнюю страницу финансовой компании после аутентификации.
Для генерации информации, отображаемой на странице, было запущено несколько запросов включая запросы к другим поддоменам. В BurpSuite он ищет в теле всех перехваченных респонзов значение показываемое под фразой «total portfolio», показанной в изображении выше (100 000 долларов США). Из поиска ничего не возвращается, поэтому он удаляет все десятичные дроби, запятые и знаки доллара (100000) и выполняет поиск снова.
Сразу же появляется несколько результатов поиска значения которое Юрий установил в своем профиле, большинство из которых получены из ответов на запросы, направленные к конечной точке API на поддомене «gateway».
Он выбирает в BurpSuite один запрос и отправляет его на вкладку «Repeater» чтобы проще было просматривать запрос и ответ. Ответ содержит несколько пикантных кусочков информации, включая общую чистую стоимость, название финансового учреждения, финансовые идентификаторы учреждений, имя и фамилия, имена членов семьи, имя работодателя, статус аккаунта, должность и информация о пенсионном плане 401k. Для тестовой учетной записи Юрий не заполнил большую часть этой информации, поэтому в перехваченном ниже response стоят «null».
Еще более интересны хедеры ответа, возвращаемые приложением. Он ясно видит, что несколько хэдеров CORS используются в реквесте и респонсе ниже. Они были выделены жирным шрифтом, чтобы легче читать.
И снова возбуждение наполняет тело Юрия. Представьте, если бы он смог получить список банков состоятельных частных лиц, имен пользователей для тех учетных записей, имена, количество денег на каждом счете и их текущие имя работодателя, а также имя его супруги. Количество тем для социальных инженеров, которые могут быть сгенерированы из этой информации становится почти безгранична.
Юрий выводит документацию на заголовки, выделенную жирным шрифтом. Быстрый поиск в Google возвращает следующую документацию разработчика Mozilla MDN:
Он изучает, что заголовок «Access-Control-Allow-Origin» ослабляет SOP для домена, помещенного в значение заголовка. Другими словами, браузер разрешает запросам, отправленным с домена, указанного в заголовке читать ответы на запросы. Он также узнает, что методы HTTP, которые будет разрешено использовать таким образом, перечислены в значении заголовка Access-Control-Allow-Methods. Наконец, он узнает, что если для заголовка Access-Control-Allow-Credentials установлено значение true, тогда браузер будет прикреплять cookie и сессионные токены в запросы.
Он решает копнуть глубже. Он находит интересные заметки на странице Mozilla MDN, а именно:
1) «Можно указать только один источник (origin). Если сервер поддерживает работу с несколькими источниками (origins) клиентов, он должен возвращать origin для конкретного клиента, делающего запрос.»
2) «Ограничение возможных значений Access-Control-Allow-Origin набором разрешенных origins требует наличие кода на стороне сервера, который проверяет значения request хедера «Origin» и сравнивает его со списком разрешенных, а затем, если значение Origin присутствует в списке, устанавливает значение заголовка Access-Control-Allow-Origin на то же значение, что и заголовок Origin.»
Заголовок Access-Control-Allow-Origin позволяет указать только один origin, поэтому невозможно указать несколько доменов. Если разработчику нужно ослабить SOP для нескольких поддоменов, ему нужно написать серверный код для проверки происхождения на основе белого списка. Поиск в Google показывает, что у нескольких разработчиков
Имея опыт работы программистом, Юрий знает,
Он проверяет, как разработчики реализовали проверку на стороне сервера. В запросе, который он отправил на вкладку «Repeater» в BurpSuite, он меняет Origin заголовок запроса на https://www.*REDACTED*.test.com и отправляет запрос. Приложение отражает измененный заголовок Origin в респонсе, как видно на изображении ниже.
Это поведение сервиса в сочетании с заголовком Access-Control-Allow-Credentials, установленным в значение "true" означает, что можно выполнять CSRF атаки против конечных пользователей, а также считывать чувствительные данные из response на requests, в случае наличия валидных сессионных файлов cookie.
Обманным путем или заставляя жертву перейти на веб-страницу, на которой размещены вредоносные скрипты JavaScript, злоумышленник может прочитать значения в ответе жертвы. В случае с этим приложением это означает чтение всей конфиденциальной информация в перехваченном request, как показано на рисунке выше. Юрий начинает свою атаку. Чтобы воспользоваться уязвимостью, ему необходимо выполнить следующие действия:
1) Купить список адресов электронной почты состоятельных людей.
2)
3) Приобрести VPS и создать запись «A» для домена, приобретенного на шаге 2, которая указывает на IP-адрес VPS.
4) Разместить на VPS вредоносную веб-страницу, содержащую JavaScript файл, выполняющий следующие действия:
а. Создание объекта XMLHttpRequest
б. Установка request метода на «GET»
c. Установка request URL-адреса запроса на адрес с конфиденциальными данными
d. Установка свойства «withCredentials» для объекта XMLHttpRequest на «true»
е. Отправка request'а
f. Когда request завершится, сохранить ответ в переменной и отправить эту переменную в «GET» или «POST» запросом на хостинг злоумышленника (на шаге 3)
g. Создать серверный скрипт на хостинг-провайдере, который записывает конфиденциальную информацию в базе данных или текстовом файле
5) Создать массовую рассылку по электронной почте, которая привлечет пользователя (из шага 1) посетить страницу злоумышленника после входа в уязвимое приложение для финансового планирования.
Код JavaScript из шага 4 может выглядеть следующим образом:
На этот раз немного поверхностной теории о защите браузеров. И пример использования Cross-Origin Resource Sharing
- 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
SAME ORIGIN POLICY
Прежде чем находить и эксплуатировать наши следующие баги, нам необходимо немного предыстории. Современные веб-браузеры не позволяют читать информацию через домены. Браузеры делают это, применяя
Ссылка скрыта от гостей
(SOP, «политику единого источника»).В общем, как следует из названия, правила SOP определяют не имеют ли два ресурса одно и то же «источник, происхождение» (origin). Например, в
Ссылка скрыта от гостей
говорится: «два URL-адреса имеют одинаковое происхождение, если протокол, порт (если указан) и хост - одинаковы для обоих».Same origin policy – критически важный компонент Интернета, по сути, SOP это политика изоляции, реализуемая веб-браузерами. SOP решает на основе набора правил, является ли ресурс (документ, скрипт и т. д.) разрешенным для взаимодействия с другим ресурсом. Стоит уточнить, что соблюдение политики обеспечивается на, сторона клиента, а не сторона сервера.
В следующей таблице (взятой из приведенной выше ссылки от Mozilla) видим пример сравнения единого происхождения для ресурса
Ссылка скрыта от гостей
|
Ссылка скрыта от гостей
| Одно и то же происхождение | Различается только путь (path) |
|
Ссылка скрыта от гостей
| Одно и то же происхождение | Различается только путь (path) |
| https://store.company.com/page.html | Ошибка | Отличается протокол |
|
Ссылка скрыта от гостей
:81/dir/page.html | Ошибка | Отличается порт |
| http://news.company.com/dir/page.html | Ошибка | Отличается хост |
Если проверка происхождения завершилась неудачно, то веб-браузер, как правило, не разрешает двум ресурсам взаимодействовать друг с другом. В большинстве случаев браузер разрешает осуществлять request (запросы, реквест) на другой домен, но доступ к response (ответу, обратному отклику, респонз) не дает.
Без SOP документ, размещенный в одном домене, может читать и взаимодействовать с документами и отвечать на запросы, отправленные из других доменов. Представьте если у конечного пользователя есть валидные сессионные cookie, полученные после аутентификации в банковском приложении. Также представьте, что злоумышленник разместил файл JavaScript на веб-сервере. Если конечный пользователь переходит на сервер к злоумышленнику после посещения банковского сайта и в веб-браузере не реализована SOP, то веб-сервер злоумышленника может получить конфиденциальную информацию о банке жертвы и даже осуществить перевод средств со счета жертвы на банковский счет по выбору злоумышленника.
Изображение ниже – хороший пример того, как SOP, внедренная в браузер, блокирует домен злоумышленника от чтения чувствительной информации из банка:
Злоумышленники разработали несколько методов обхода SOP. Эта глава будет посвящена самому популярному и распространенному методу атаки - Cross-Site Scripting (XSS). Однако в этой главе мы рассмотрим другие методы такие как мисконфигурация CORS, подделка межсайтовых запросов (Cross-Site Request Forgery, CSRF), перехват субдоменов и атаки обратного вызова JSONP.
Cross-Origin Resourse Sharing (CORS, совместное использование ресурсов между источниками)
Современный веб – это сложное пространство. Во многих случаях разработчики и инженеры хотят взаимодействовать со скриптами across origin (через источники). Что происходит, когда разработчикам необходимо взаимодействовать с ресурсами разного origin (происхождения, источника), например с другого субдомена? Современные браузеры добавили поддержку хэдеров запросов и ответов, которые позволяют веб-приложению смягчить SOP веб-браузера. Эти хэдеры (заголовки) относятся к протоколу Cross-Origin Resource Sharing или «CORS». Спецификацию для этих заголовков можете найти здесь:
Ссылка скрыта от гостей
По сути, веб-приложения могут отправлять определенные response-заголовки, которые попросят клиента смягчить SOP для конкретного origin (источника). Это позволяет ресурсам (например, скриптам) взаимодействовать с ослабленными доменами. Как мы увидим далее в этой главе, если эти заголовки не настроены должным образом, то могут возникнуть катастрофические последствия, такие как раскрытие конфиденциальных данных или CSRF-атаки.
Эксплуатация мисконфигурации CORS
Origin Reflection (отражение заголовка Origin)
Теперь, когда у нас есть некоторая справочная информация об одной и той же политике происхождения и CORS, давайте вернемся в голову Юрия. Его скрипты по перебору SSN работают как часы, собирая тысячи потенциальных жертв кражи личных данных и номеров SSN, которые будут использоваться для подачи фальсифицированных налоговых деклараций.
Пока он ждет следующего налогового сезона, начальство хочет, чтобы он диверсифицировал потоки доходов банды. Они создали банковский троян, который запускается на персональных компьютерах и мобильных устройствах. Работает аналогично
Ссылка скрыта от гостей
.Его босс поручил ему составить список состоятельных людей, которых можно использовать в целевых фишинговых и спам-кампаниях. Кроме этого, они не хотят, чтобы их недавно разработанный банковский троян был обнаружен антивирусными компаниями или исследователями вредоносного ПО хотя бы в течение нескольких лет. Банда решает следующее:
1. Убедиться, что у жертв достаточно денег для успешной атаки (повышение рентабельности, мать их етить, прим. переводчика).
2. Ограничив масштаб атаки, как можно дольше не попадаться ФБР, Интерполу, антивирусным компаниям и фирмам, занимающимся исследованиями в области безопасности.
3. Развить успех (количество установок зловреда), создавая более качественные предложения, основанные на социальной инженерии для каждой цели исходя из полученной информации.
Юрий знает, что ему нужно найти состоятельных людей, но не знает, как собрать такой список. Быстрый поиск в Google показывает, что диджитал маркетологи и другие продажники могут приобрести список у третьих лиц,
Ссылка скрыта от гостей
тут.У этого подхода есть несколько недостатков. Во-первых, в этих списках очень ограниченная информация о перечисленных лицах. Хотя адрес электронной почты и номер телефона - хорошее начало и, скорее всего к чему-то приведет, он хочет более таргетированный список. Он хочет знать уровень дохода и любую информацию, которая может быть использована в качестве предлога для целевых атак. Во-вторых, список содержит более двух миллионов записей. Если спам-кампания нацелена на такое количество жертв, то вполне вероятно, что антивирусные компании и исследователи безопасности будут предупреждены, что приведет к мониторингу спам-кампании и ее блокировке - электронные письма быстро попадут в папку со спамом жертвы.
После нескольких часов размышлений Юрию приходит в голову мысля! Что, если он нацелится на компании, занимающиеся финансовым планированием и консультированием по инвестициям в Интернете? Обычно эти компании имеют более состоятельных людей в качестве клиентов, и более точную информацию, такую как уровень заработка, чистая прибыль, банки клиента, должность и другую финансовую информацию.
Обычно у этих компаний есть флагманское веб-приложения для использования клиентами, и многие предлагают бесплатную регистрацию или пробные предложения. Немного погуглив он натыкается на веб-приложение, которое может быть интересно и создает бесплатную учетную запись. При создании аккаунта запрашивается несколько деталей, таких как адрес электронной почты, номер телефона, уровень дохода, банковская информация, планируемый пенсионный возраст и информация по инвестированию (например, сколько наличных денег по сравнению с акциями и облигациями есть у человека). После настройки бесплатной учетной записи с тестовыми данными он переходит к странице «Your Money» и замечает, что отображаются его тестовые данные. Он настраивает Firefox использует прокси BurpSuite и обновляет домашнюю страницу финансовой компании после аутентификации.
Для генерации информации, отображаемой на странице, было запущено несколько запросов включая запросы к другим поддоменам. В BurpSuite он ищет в теле всех перехваченных респонзов значение показываемое под фразой «total portfolio», показанной в изображении выше (100 000 долларов США). Из поиска ничего не возвращается, поэтому он удаляет все десятичные дроби, запятые и знаки доллара (100000) и выполняет поиск снова.
Сразу же появляется несколько результатов поиска значения которое Юрий установил в своем профиле, большинство из которых получены из ответов на запросы, направленные к конечной точке API на поддомене «gateway».
Он выбирает в BurpSuite один запрос и отправляет его на вкладку «Repeater» чтобы проще было просматривать запрос и ответ. Ответ содержит несколько пикантных кусочков информации, включая общую чистую стоимость, название финансового учреждения, финансовые идентификаторы учреждений, имя и фамилия, имена членов семьи, имя работодателя, статус аккаунта, должность и информация о пенсионном плане 401k. Для тестовой учетной записи Юрий не заполнил большую часть этой информации, поэтому в перехваченном ниже response стоят «null».
Еще более интересны хедеры ответа, возвращаемые приложением. Он ясно видит, что несколько хэдеров CORS используются в реквесте и респонсе ниже. Они были выделены жирным шрифтом, чтобы легче читать.
И снова возбуждение наполняет тело Юрия. Представьте, если бы он смог получить список банков состоятельных частных лиц, имен пользователей для тех учетных записей, имена, количество денег на каждом счете и их текущие имя работодателя, а также имя его супруги. Количество тем для социальных инженеров, которые могут быть сгенерированы из этой информации становится почти безгранична.
Юрий выводит документацию на заголовки, выделенную жирным шрифтом. Быстрый поиск в Google возвращает следующую документацию разработчика Mozilla MDN:
Ссылка скрыта от гостей
Ссылка скрыта от гостей
Он изучает, что заголовок «Access-Control-Allow-Origin» ослабляет SOP для домена, помещенного в значение заголовка. Другими словами, браузер разрешает запросам, отправленным с домена, указанного в заголовке читать ответы на запросы. Он также узнает, что методы HTTP, которые будет разрешено использовать таким образом, перечислены в значении заголовка Access-Control-Allow-Methods. Наконец, он узнает, что если для заголовка Access-Control-Allow-Credentials установлено значение true, тогда браузер будет прикреплять cookie и сессионные токены в запросы.
Он решает копнуть глубже. Он находит интересные заметки на странице Mozilla MDN, а именно:
1) «Можно указать только один источник (origin). Если сервер поддерживает работу с несколькими источниками (origins) клиентов, он должен возвращать origin для конкретного клиента, делающего запрос.»
2) «Ограничение возможных значений Access-Control-Allow-Origin набором разрешенных origins требует наличие кода на стороне сервера, который проверяет значения request хедера «Origin» и сравнивает его со списком разрешенных, а затем, если значение Origin присутствует в списке, устанавливает значение заголовка Access-Control-Allow-Origin на то же значение, что и заголовок Origin.»
Заголовок Access-Control-Allow-Origin позволяет указать только один origin, поэтому невозможно указать несколько доменов. Если разработчику нужно ослабить SOP для нескольких поддоменов, ему нужно написать серверный код для проверки происхождения на основе белого списка. Поиск в Google показывает, что у нескольких разработчиков
Ссылка скрыта от гостей
.Имея опыт работы программистом, Юрий знает,
Ссылка скрыта от гостей
по поддержке белых списков, как им это предлагает делать Mozilla. Он начинает думать о том, что в целях возможного обхода средств защиты может использоваться белый список проверки разрешенных доменов. Ему в голову приходит идея! Что, если разработчики взяли request заголовок Origin и просто отразили его прямо в response заголовок Access-Control-Allow-Origin? (Более опытная команда разработчиков может использовать регулярное выражение в попытке проверить origin запроса. Позже в этой главе мы исследуем потенциальные недостатки этого подхода.)Он проверяет, как разработчики реализовали проверку на стороне сервера. В запросе, который он отправил на вкладку «Repeater» в BurpSuite, он меняет Origin заголовок запроса на https://www.*REDACTED*.test.com и отправляет запрос. Приложение отражает измененный заголовок Origin в респонсе, как видно на изображении ниже.
Это поведение сервиса в сочетании с заголовком Access-Control-Allow-Credentials, установленным в значение "true" означает, что можно выполнять CSRF атаки против конечных пользователей, а также считывать чувствительные данные из response на requests, в случае наличия валидных сессионных файлов cookie.
Обманным путем или заставляя жертву перейти на веб-страницу, на которой размещены вредоносные скрипты JavaScript, злоумышленник может прочитать значения в ответе жертвы. В случае с этим приложением это означает чтение всей конфиденциальной информация в перехваченном request, как показано на рисунке выше. Юрий начинает свою атаку. Чтобы воспользоваться уязвимостью, ему необходимо выполнить следующие действия:
1) Купить список адресов электронной почты состоятельных людей.
2)
Ссылка скрыта от гостей
, похожее на уязвимое веб-приложение с хорошей репутацией, которое можно использовать в кампании по рассылке спама, чтобы потенциальные жертвы на шаге 1 щелкнули на ссылку.3) Приобрести VPS и создать запись «A» для домена, приобретенного на шаге 2, которая указывает на IP-адрес VPS.
4) Разместить на VPS вредоносную веб-страницу, содержащую JavaScript файл, выполняющий следующие действия:
а. Создание объекта XMLHttpRequest
б. Установка request метода на «GET»
c. Установка request URL-адреса запроса на адрес с конфиденциальными данными
d. Установка свойства «withCredentials» для объекта XMLHttpRequest на «true»
е. Отправка request'а
f. Когда request завершится, сохранить ответ в переменной и отправить эту переменную в «GET» или «POST» запросом на хостинг злоумышленника (на шаге 3)
g. Создать серверный скрипт на хостинг-провайдере, который записывает конфиденциальную информацию в базе данных или текстовом файле
5) Создать массовую рассылку по электронной почте, которая привлечет пользователя (из шага 1) посетить страницу злоумышленника после входа в уязвимое приложение для финансового планирования.
Код JavaScript из шага 4 может выглядеть следующим образом:
Последнее редактирование:
