Как перехватить запрос из браузера

Обновлено: 08.07.2024

получить доступ к заголовкам и телам запроса, к заголовкам ответа
отменять и перенаправлять запросы
изменять запрос и заголовки ответа

В этой статье мы рассмотрим три разных способа использования webRequest модуля:

Логирование URL сделанных запросов.
Перенаправление запросов.
Модификация заголовков запроса.

Логирование URL запросов

Создайте новый каталог "requests". В нём создайте файл "manifest.json" со следующим содержимым:

Далее, создайте файл "background.js" со следующим содержимым:

Для проверки проинсталлируйте WebExtension, откройте консоль браузера и откройте какую-нибудь веб-страницу. В консоли вы должны увидеть URL для каждого ресурса, который запрашивает браузер:

Перенаправление запросов

Единственное изменение здесь заключается в добавлении "webRequestBlocking" в permission . Мы должны запрашивать это дополнительное разрешение каждый раз, когда мы изменяем запрос.

Затем замените «background.js» следующим образом:

Опять же, мы используем onBeforeRequest (en-US) обработчик событий для запуска функции непосредственно перед каждым запросом. Эта функция заменит целевой URL на redirectUrl указанный в функции.

На этот раз мы не перехватываем каждый запрос: опция указывает, что мы должны перехватывать запросы (1) для URL-адресов, находящихся в разделе «https://mdn.mozillademos.org / "(2) для ресурсов изображения. Подробнее см. webRequest.RequestFilter (en-US).

Также обратите внимание, что мы передаём опцию "blocking" : нам нужно передать это, когда мы хотим изменить запрос. Это заставляет функцию обработчика блокировать сетевой запрос, поэтому браузер ждёт, пока обработчик вернётся, прежде чем продолжить. Дополнительную информацию о "blocking" смотрите в документации webRequest.onBeforeRequest (en-US).

Modifying request headers

Finally we'll use webRequest to modify request headers. In this example we'll modify the "User-Agent" header so the browser identifies itself as Opera 12.16, but only when visiting pages under http://useragentstring.com/".

The "manifest.json" can stay the same as in the previous example.

Replace "background.js" with code like this:

Here we use the onBeforeSendHeaders (en-US) event listener to run a function just before the request headers are sent.

The listener function will be called only for requests to URLs matching the targetPage pattern. Also note that we've again passed "blocking" as an option. We've also passed "requestHeaders" , which means that the listener will be passed an array containing the request headers that we expect to send. See webRequest.onBeforeSendHeaders (en-US) for more information on these options.

The listener function looks for the "User-Agent" header in the array of request headers, replaces its value with the value of the ua variable, and returns the modified array. This modified array will now be sent to the server.

Learn more

To learn about all the things you can do with the webRequest API, see its reference documentation.

Этичный хакинг и тестирование на проникновение, информационная безопасность

Современные веб-сайты становятся всё сложнее, используют всё больше библиотек и веб технологий. Для целей отладки разработчиками сложных веб-сайтов и веб-приложений потребовались новые инструменты. Ими стали «Инструменты разработчика» интегрированные в сами веб-браузеры:

Chrome DevTools
Firefox Developer Tools

Они по умолчанию поставляются с браузерами (Chrome и Firefox) и предоставляют много возможностей по оценке и отладке сайтов для самых разных условий. К примеру, можно открыть сайт или запустить веб-приложение как будто бы оно работает на мобильном устройстве, или симулировать лаги мобильных сетей, или запустить сценарий ухода приложения в офлайн, можно сделать скриншот всего сайта, даже для больших страниц, требующих прокрутки и т.д. На самом деле, Инструменты разработчика требуют глубокого изучения, чтобы по-настоящему понять всю их мощь.

В предыдущих статьях я уже рассматривал несколько практических примеров использования инструментов DevTools в браузере:

Эта небольшая заметка посвящена анализу POST запросов. Мы научимся просматривать отправленные методом POST данные прямо в самом веб-браузере. Научимся получать их в исходном («сыром») виде, а также в виде значений переменных.

По фрагменту исходного кода страницы видно, что данные из формы передаются методом POST, причём используется конструкция onChange="this.form.submit();":

Как увидеть данные, переданные методом POST, в Google Chrome

Итак, открываем (или обновляем, если она уже открыта) страницу, от которой мы хотим узнать передаваемые POST данные. Теперь открываем инструменты разработчика (в предыдущих статьях я писал, как это делать разными способами, например, я просто нажимаю F12):

Теперь отправляем данные с помощью формы.

Переходим во вкладку «Network» (сеть), кликаем на иконку «Filter» (фильтр) и в качестве значения фильтра введите method:POST:

Как видно на предыдущем скриншоте, был сделан один запрос методом POST, кликаем на него:

Header — заголовки (именно здесь содержаться отправленные данные)
Preview — просмотр того, что мы получили после рендеренга (это же самое показано на странице сайта)
Response — ответ (то, что сайт прислал в ответ на наш запрос)
Cookies — кукиз
Timing — сколько времени занял запрос и ответ

Поскольку нам нужно увидеть отправленные методом POST данные, то нас интересует столбец Header.

Там есть разные полезные данные, например:

Request URL — адрес, куда отправлена информация из формы
Form Data — отправленные значения

Пролистываем до Form Data:

Там мы видим пять отправленных переменных и из значения.

Если нажать «view source», то отправленные данные будут показаны в виде строки:

Вид «view parsed» - это вид по умолчанию, в котором нам в удобном для восприятия человеком виде показаны переданные переменные и их значения.

Как увидеть данные, переданные методом POST, в Firefox

В Firefox всё происходит очень похожим образом.

Открываем или обновляем нужную нам страницу.

Открываем Developer Tools (F12).

Отправляем данные из формы.

Переходим во вкладку «Сеть» и в качестве фильтра вставляем method:POST:

Кликните на интересующий вас запрос и в правой части появится окно с дополнительной информацией о нём:

Переданные в форме значения вы увидите если откроете вкладку «Параметры»:

Другие фильтры инструментов разработчика

Для Chrome кроме уже рассмотренного method:POST доступны следующие фильтры:

Впрочем, возможно перспектива обрисованная мной, слишком пессимистична и текущие коды будут работать еще 200 лет. Сложность всех перечисленных методов видится мне в своей неуниверсальности, необходимости мониторить обновления браузеров, горы перехватов, к которым готовы различные защиты вроде трастер раппорта, необходимости поддерживать несколько веток кода, выполняющего одну «простую» цель — вмешательство в пользовательский сслхттп траффик.

Идеальный вариант — либо полное отсутствие перехватов, либо такая их комбинация, чтоб они не зависили ни от чего. Ни от версии браузера или его семейства, ни от версии Windows, ни от направления ветра или настроения пользователя. Сделать совсем без перехватов тоже можно, но оставим это в следущий выпуск журнала. В этот раз поговорим о том, как убить одним хуком всех зайцев. Этот метод тоже нельзя считать идеальным или простым, но он по крайней мере позволяет избавиться от минусов вышеописанных способов, таких как неуниверсальность и сложность поддержки. Ближе к практике! Суть предлагаемого способа на самом деле стара как мир. Необходимо научится проксировать браузер. Что нужно для успешной проксификации? По сути ничего. Нужно отловить момент , когда браузер делает коннект на удаленный хост и пропатчить структуру SOCKADDR_IN, изменив в ней удаленный адрес и порт. Это не проксификация в полном смысле этого слова, а просто редирект коннекта кудато там. Так как браузер не будет знать ничего о том, куда отправили коннект. Так же как и не будет знать и о туннеле, который мы для него готовим. Общий случай выглядит примерно так : Практически во всех случаях, нам достаточно установить перехват на WSAConnect, но в этом случае мы побреемся в windows 8+, с браузером IE11, который использует передовые технологии майкрософта в лице RIO. Что такое RIO можно посмотреть тут Если быть кратким, то это новая, принципиально другая технология для работы с сетью для приложений, критичных к сетевым задержкам (к коим относится и браузер). Эдакий винсокет на стероидах. Так вот рио _не_ использует винсокеты, и потому хук на WSAConnect не помешает ишаку выйти в интернет. Для создания удаленного кодлючения, в этом случае будет использована неэкспортируемая, но документированная ConnectEx, указатель на которую можно получить без особого труда следущим кодом :

В итоге , функционал редиректа укладывается в два хука:

Вот только, как мне кажется, хук на коннект недвусмысленного говорит «о чем то таком». Более беспалевно было бы хукнуть NtDeviceIoControlFile. В хуке мониторить, если IoControlCode будет IOCTL_AFD_CONNECT, то безжалостно патчить InputBuffer. В нем будет структура AFD_CONNECT_INFO и в ней все, что нужно знатьизменять для успешного перенаправления соединения. Детали реализации оставим на совести эксперементаторов.

Стоит только отметить что структуры для NT5 и NT6+ разные. Но в этой точке можно отлавливать любые попытки коннекта процесса, в котором мы находимся.

Хттп и в африке хттп. Этот момент может отпугнуть своей нетривиальностью реализации, но на самом деле, мы же про теорию. Задача состоит в том, чтоб принять хттп запрос, дождавшись когда браузер отправит хедеры и запрос (тело с данными), если таковой будет присутствовать. Получив все заголовки, вытаскиваем оттуда поле «Host» и делаем самостоятельный коннект на адрес, который там указан. Учитывая, что там может быть указан как айпи, так и домен или домен:порт и еще несколько вариаций. Все их можно найти в спецификации хттп.

Все остальное дело техники. Мы может как модифицировать запрос (подмена ПОСТ данных), так и ответ, собирая во временный буффер ответ, на интересующий нас запрос. Все вроде прозрачно, все просто. Кстати, отличный хттп парсер есть в libevent. Его юзает в своих целях NGINX, он компактный, отлаженный и стабильный.

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

Подход первый : патчинг проверки сертификатов. Метод дибильный, успешно зарекомендовавший свою неприменяемость. Суть сводится к тому, чтоб создавать коннект браузер <-> локалхост с самоподписанным сертифткатом, но ставя перехваты внутри CryptoAPI и внутри браузеров (чаще всего это неэкспортируемые функции внутренних проверок браузера), создавать видимость того, что сертифкат нормальный. К томуже тут вылазит масса побочных эффектов:

1 — все сайты внезапно начинают юзать один и тот же сертификат. Тоесть если зайти в гугл, там там сертифкат выдан «super co ltd». Если зайти на майкрософт, то и там все тот же «super co ltd».
Нормальный человек сразу заподозрит неладное. А целевая аудитория у нас естественно не идиоты.
2 — Нестабильность метода, так как фукнции проверки сертификатов разработчики браузеров (ИЕ исключение) не спешат помечать как экспортируемые. Отсюда куча геморроя, вроде того, что сами функи меняются, их сигнатурки меняются, кол-во параметров может менятся (нормальное явление в случае с хромом)
3 — Можно смело забывать по EV-сертифкаты. Это сертификаты с расширенной проверкой, результат применения которых зеленая полоса в адресной строке браузера.

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

1 — ловим коннект браузера на удаленный сервер
2 — редиректим на локалхост, запуская там попутно новый инстанс TCP сервера, копия которого привязана к хосту, куда изначально шел браузер
3 — В инстансе сервера ждем коннекта браузера. Как только браузер приконнектился, мы не начинаем SSL сессию, а идем на тот хост, куда шел браузер изначально. Путь это будет гугл.
4 — После инициализации SSL соединения с гуглом, получаем от него сертифкат, парсим все поля из него.
5 — создаем свой сертифкат, на основе всего того, что удалось выдрать из настоящего церта. Для замыливания глаз хватит полей CN, E, OU, etc. базовые поля х509
6 — преобразуем наш инстанс TCP сервера в SSL сервер, начиная handsnake с только что сгенерированного сертифката.
7 — .
8 — PROFIT!

В итоге мы имеем динамическую генерацию цертов для каждого домена. Результат генерации можно сохранять в локальных кешах, конечно. Таким образом мы можем сделать так, чтоб сертифкаты были такие, какие нужно (по составу). Чтоб браузер не ругался на то, что церт самопальный, нужно сделать так, чтоб он не был самопальным 🙂

То есть, нам нужно для начала сгенерировать нейки начальный церт, которому дать право подписывать сертифкаты ( CertStrToName, CertCreateSelfSignCertificate), выставив соответствующие флаги при создании сертификата :

а затем добавить его в сторадж доверенных виндовых цертов (CertAddCertificateContextToStore). затем связать его с генерированным приватным ключем (CryptGenKey/CryptAcquireCertificatePrivateKey). Все!

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

Браузер увидит церт, начнет раскручивать цепочку выдачи, наткнется на наш траст, который числится издателем сертифкатов, убедится что сертифкат валидный. Профит.

Что получается в сухом остатке ?

1 — Один перехват, в полностью документированной и никуда не девающейся функе в ntdll.
2 — Независимость от платформы браузера (3264) и особенностей реализации его механизмов
проверки цертов и прочего говна
3 — Работа на всех ос максимально безболезненно.
4 — Полная невидимость работы для пользователя (все работает быстро, хотя и зависит от хттп парсера), все сертифкаты остаются такими, какими они должны быть.

Эта статья о том, как стать кулхацкером (или по-английски Script Kiddie) — условным злоумышленником, который испытывает недостаток знаний в области программирования и использует существующее программное обеспечение, чтобы провести атаку на смартфоны и планшеты своих одноклассников.

Шучу. На самом деле передо мной стояла задача понять две вещи:

Отправная точка

Сразу скажу, что хотя часть моих опытов проводил в настоящих публичных сетях, “неправомерный доступ” я получал только к браузерам своих собственных устройств. Поэтому фактически Главу 28 УК РФ я не нарушал, и Вам настоятельно нарушать не советую. Данный эксперимент и статья предлагаются к ознакомлению исключительно в целях демонстрации небезопасности использования публичных беспроводных сетей.

Железо

В качестве инструментария для эксперимента я использовал следующий инструментарий:

Любая публичная WiFi сеть на фудкорте
Нетбук Acer Aspire one D270
Встроенная wifi карта Atheros AR5B125
Внешний wifi usb адаптер WiFi TP-LINK Archer T4U v3
Внешний wifi usb адаптер TP-LINK Archer T9UH v2
Kali Linux c версией ядра 5.8.0-kali2-amd64
Фреймворк Bettercap v2.28
Фреймворк BeEF 0.5
Несколько смартфонов и планшетов на Android 9 и ноутбук на Windows 7 в качестве устройств-жертв.

У встроенной карты Atheros AR9485 была великолепная поддержка всех режимов и драйвер “из коробки” в Kali, но невозможность управлять мощностью сигнала и слабая антенна сводили на нет эффективность данной карты на фазе активного вмешательства в трафик.

У WiFi TP-LINK Archer T4U v3 не было драйвера из коробки, а тот который я нашел на Github, не имел поддержки режима точки доступа (AP) и его нужно было компилировать самостоятельно.

Карточка TP-LINK Archer T9UH v2 заработала идеально с драйвером из коробки, на ней то у меня все и получилось.

Первым делом я установил Kali Linux 5.8.0 на свой ноутбук. Единственный SSD в ноутбуке был пустым и предназначался целиком для эксперимента, что избавило меня от некоторых трудностей с разбивкой разделов и резервным копированием старых данных с него, поэтому при установке я использовал все варианты “по умолчанию”. Я все же столкнулся некоторыми тривиальными проблемами вроде потери монтирования флешки с дистрибутивом в процессе установки и обновления системы до последней актуальной версии из репозитория.

Затем нужно было запустить инструменты проникновения, ими будут Bettercap и BeEF. С их помощью мы принудим браузеры “жертв” отказаться от шифрования трафика и внедрим в просматриваемые сайты троянский JavaScript.

Bettercap — это полный, модульный, портативный и легко расширяемый инструмент и фреймворк с диагностическими и наступательными функциями всех видов, которые могут понадобиться для выполнения атаки “человек посередине”. Bettercap написан на Go, основная разработка проекта проходила до 2019 года, сейчас происходят лишь небольшие исправления. Однако, как мы увидим позднее этот инструмент в быстро меняющемся мире информационной безопасности сохраняет свою актуальность и на закате 2020 года. Bettercap поставляется со встроенным модулями arp spoof и sslstrip. Именно Bettercap должен перехватывать трафик и внедрять в него вредоносную нагрузку.

BeEF — это фреймворк, позволяющий централизованно управлять пулом зараженных через XSS-атаку (сross-site scripting) клиентов, отдавать им команды и получать результат. “Злоумышленник” внедряет на уязвимый сайт скрипт hook.js. Скрипт hook.js из браузера “жертвы” сигналит управляющему центру на компьютере “злоумышленника” (BeEF) о том, что новый клиент онлайн. “Злоумышленник” входит в панель управления BeEF и удаленно управляет зараженными браузерами.

Я использовал версии Bettercap v2.28 и BeEF 0.5 Они оба уже есть в составе Kali Linux 5.8.0
Открываем окно командной строки и вводим команду

Стартует первая часть нашего зловредного бутерброда — фреймворк BeEF.

Оставляем вкладку с BeEF открытой, мы в нее вернемся позже.

Перейдем к второй части бутерброда — Bettercap. Тут был подводный камень — Bettercap, уже имевшийся в системе, отказывался стартовать сервисом и выдавал другие непонятные мне ошибки. Поэтому я его решил удалить и поставить заново вручную. Открываем окно командной строки и выполняем команды:

Затем скачиваем браузером бинарную версию Bettercap v2.28 в архиве в папку загрузки. Обратите внимание, что я выбрал версию для своей архитектуры ядра.

Теперь распаковываем и размещаем исполняемый файл в системе Bettercap в папку, предназначенную для ручной установки.

Самый простой способ начать работу с Bettercap — использовать его официальный веб-интерфейс пользователя. Веб-интерфейс работает одновременно с сервисом rest API и интерактивной сессией командной строки. Чтобы установить веб-интерфейс нужно выполнить команду:

Внимание! Уже на этом этапе нужно обязательно подключиться к атакуемой беспроводной сети, получить ip-адрес для беспроводного интерфейса атакующей машины и запомнить его (команда ifconfig поможет его узнать).

Теперь можно открыть в браузере еще одну вкладку с адресом 127.0.0.1 (без номера порта!) и войти в систему, используя учетные данные, которые были подсмотрены или настроены на предыдущем шаге (обычно это user/pass).

Веб-интерфейс Bettercap полностью дублирует командную строку, поэтому все действия которые мы будем делать из командной строки, можно сделать и из веб-интерфейса (запуск модулей, смена режимов, просмотр изменение значение переменных, вывод диагностической информации)

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

net.recon on — Запускает обнаружение сетевых хостов.
net.probe on — Запускает активное зондирование новых хостов в сети через отправку фиктивных пакетов каждому возможному IP в подсети.
net.show — Даёт команду отобразить список кэша обнаруженных хостов.
net.probe off — Выключает модуль активного зондирования.
Настраиваем переменные Bettercap, чтобы он:

Затем запускаем атаку против пользователей беспроводной сети:
Команды

А на машине “злоумышленника” в контрольной панели фреймворка BeEF, в разделе Online Browsers тем временем появится запись о новом браузере, пойманном на крючок. Выбираем этот браузер мышью, переходим в суб-вкладку Commands, на каталог Browsers, потом последовательно Hooked domain → Get Cookie → Execute

Выводы

Выводы по результатам эксперимента неутешительные. Браузеры еще не могут на 100% защитить пользователей от вмешательства в трафик или подмены настоящего сайта фишинговым. Механизм HSTS срабатывает только для пары тысяч самых популярных сайтов и оставляет без надежной защиты миллионы других. Браузеры недостадочно явно предупреждают о том, что соединение с сервером не зашифровано. Еще хуже дело обстоит в беспроводных сетях, где доступ к среде передачи данных есть у любого желающего, при этом почти никто из пользователей вообще никак не проверяет подлинность самой точки доступа, а надежных методов проверки подлинности точек доступа просто не существует.

Читайте также: