- Перехват post запросов android
- Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга
- Что такое certificate pinning?
- Обход certificate pinning
- Перехват HTTPS-траффика между Android-устройством и внешним сервером
- Теория
- Практика
- Fiddler = удобный сниффер + прокси сервер
- Зачем это делать ?
- Установка Fiddler
- Настройка Fiddler
- Основные настройки
- Установка сертификатов на Windows устройствах
- Анализ трафика
- Изменение данных запросов
- Задача 1: Запрет сайта
- Задача 2: Запрет загрузки ресурса
- Задача 3: Переадресация запроса
- Задача 4: Сбор данных
- Задача 5: Изменить текст в ответе
- Задача 6: Заменить ресурс веб-портала на локальный ресурс
- Задача 7: Изменение свойств HTML-объектов
- Задача 8: Скрыть элементы по className меняя css-файлы
- Задача 9: Заставить страницу открываться в текущем окне
- Задача 10: Выполнение скриптов для определенных IP
- Задача 11: Меняем css-стили портала
- Задача 12: Запрет PUT-команды и аналогичных
- Задача 13: Изменение тела POST-запроса
- Задача 14: Меняем заголовки HTTP-пакета
- Задача 15: Меняем Cookie
Перехват post запросов android
Краткое описание:
HttpCanary — это мощное приложение для захвата и анализа пакетов HTTP / HTTPS / HTTP2
Описание:
Приложение для захвата пакетов http и https, обзор поддержки, предварительный просмотр, внедрение
Особенности HttpCanary Premium:
1. Нет рекламы.
2. Http-запрос и ответные инъекции.
3. Поддержка повтора, составления и копирования CURL.
4. Все мощные плагины доступны.
5. Более мощные функции в будущем.
HttpCanary — это мощное приложение для захвата и анализа пакетов HTTP / HTTPS / HTTP2, разработанное для платформы Android. Вы можете подумать, что это мобильный скрипач или Чарльз.
ImportantСамое важное: рут не требуется! Корень не требуется! Корень не требуется!
HttpCanary поддерживает захват и внедрение пакетов. С помощью этого приложения вы можете очень легко протестировать свои мобильные API для отдыха. Кроме того, HttpCanary предоставляет несколько браузеров представления, таких как необработанный просмотрщик, просмотрщик шестнадцатеричных изображений, просмотрщик предварительного просмотра и так далее.
* Поддержка протоколов
HTTP1.0, HTTP1.1, HTTP2.0, WebSocket и TLS / SSL.
* Устройства поддержки
Любые устройства Android Arm или x86 включают эмуляторы.
* Инъекция
HttpCanary предоставляет два разных режима для инъекции: статический режим и динамический режим. Вы можете ввести параметры запроса, заголовки, тела и строку состояния. Вы можете создавать инжекторы с различными требованиями, и статический режим поддерживает одновременно несколько форсунок.
* Просмотр браузеров
Необработанный просмотрщик, показывает необработанные пакеты данных.
Просмотрщик текста, показывает данные тела в виде текста.
Hex viewer, показывает данные тела в виде шестнадцатеричной строки.
Json viewer, показывает отформатированные данные json, поддерживает развёртывание и свертывание узлов.
Просмотр изображений, поддержка шоу форматов BPM, PNG, GIF, JPG, WEBP.
Аудио просмотра, поддержка воспроизведения форматов AAC, WAC, MP3, OGG, MPEG.
* Обзор содержимого
HttpCanary отображает многомерный обзор сеанса. Включает URL, протокол http, метод http, код ответа, хост сервера, ip и порт сервера, тип контента, поддержку активности, время, размер данных и т.д.
* Фильтр пакетов
В HttpCanary есть многомерные фильтры, с помощью которых вы можете фильтровать пакеты по приложению, хосту, протоколу, методу, ip, порту и ключевым словам.
* Настройки блокировки
Вы можете заблокировать запросы и ответы, легко отладить REST API.
* Плагины
HttpCanary поддерживает многие плагины, включая экспериментальные плагины и плагины расширения. Теперь в приложение интегрировано несколько экспериментальных плагинов, таких как HostBlock, Mime-TypeBlock, Downloaders и OverviewStatistics. В будущем мы опубликуем расширение plugin-sdk для разработчиков и поддержим плагины расширения.
В конце концов, основные коды HttpCanary открыты в Github, мы надеемся, что HttpCanary сможет помочь большему количеству людей.
Требуется Android: 5.x+
Русский интерфейс: Нет
Источник
Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга
Иногда нужно исследовать работу бэкенда мобильного приложения. Хорошо, если создатели приложения не заморачивались и все запросы уходят по «голому» HTTP. А что, если приложение для запросов использует HTTPS, и отказывается принимать сертификат вашего корневого удостоверяющего центра, который вы заботливо внедрили в хранилище операционной системы? Конечно, можно поискать запросы в декомпилированом приложении или с помощью реверс-инжиниринга вообще отключить применение шифрования, но хотелось бы способ попроще.
Что такое certificate pinning?
Даже при использовании HTTPS пользователь не защищен от атак «Человек посередине», потому что при инициализации соединения злоумышленник может подменить сертификат сервера на свой. Трафик при этом будет доступен злоумышленнику.
Справиться с такой атакой поможет certificate pinning. Эта защитная мера заключается в том, что разработчик «зашивает» в приложение доверенный сертификат. При установке защищенного соединения приложение проверяет, что сертификат, посылаемый сервером, совпадает с (или подписан) сертификатом из хранилища приложения.
Обход certificate pinning
В качестве подопытного выберем приложение Uber. Для анализа HTTP-трафика будем использовать Burp Suite. Также нам понадобится JDK и Android SDK (я использую все последней версии). Из Android SDK нам понадобится только утилита zipalign, так что при желании можно не скачивать весь SDK, а найти ее на просторах интернета.
Заранее облегчим себе жизнь, добавив следующие пути к нужным утилитам в переменную окружения PATH:
Открываем Burp, заходим в Proxy – Options – Add и добавляем Proxy Listener на интерфейсе, который будет доступен подопытному Android-устройству (или эмулятору). На устройстве в свою очередь настраиваем используемую Wi-Fi сеть на использование только что включенного прокси.
Скачаем apk-файл через apkpure.com, установим приложение на устройство и попытаемся войти в свой аккаунт – приложение зависнет на этапе аутентификации.
В логах Burp Suite (вкладка Alerts) при этом мы увидим множественные отчеты о неудачных SSL-рукопожатиях. Обратите внимание на первую строчку – именно через сервер cn-geo1.uber.com в моем случае осуществляется аутентификация, поэтому и не удается войти в приложение.
Дело в том, что Burp Suite при перехвате HTTPS-соединений (а мы помним, что все соединения устройства проксируются через него) подменяет сертификат веб-сервера на свой, который, естественно, не входит в список доверенных. Чтобы устройство доверяло сертификату, выполняем следующие действия. В Burp заходим в Proxy – Options и нажимаем Import/export CA certificate. Далее в диалоге выбираем Export Certificate. Копируем сертификат на устройство, переходим в Настройки – Безопасность – Установить сертификаты и устанавливаем наш сертификат в качестве сертификата для VPN и приложений.
Опять пытаемся войти в свой аккаунт. Сейчас приложение Uber сообщит нам только о неудачной попытке аутентификации – значит прогресс есть, осталось только обойти certificate pinning.
Откроем приложение в вашем любимом архиваторе как zip-архив. В папке res/raw можно заметить файл с говорящим названием ssl_pinning_certs_bk146.bks.
По его расширению можно понять, что Uber использует хранилище ключей в формате BouncyCastle (BKS). Из-за этого нельзя просто заменить сертификат в приложении. Сначала нужно сгенерировать BKS-хранилище. Для этого качаем jar для работы с BKS.
Теперь генерируем BKS-хранилище, которое будет содержать наш сертификат:
На вопрос о доверии сертификату отвечаем «yes». Опять открываем apk в архиваторе и заменяем оригинальное хранилище на наше (сохраняем при этом оригинальное название).
Но на этом все не заканчивается. Каждый apk должен быть подписан сертификатом разработчика. К счастью, это делается не для обеспечения безопасности, а для идентификации приложений, поэтому для наших исследовательских целей мы вполне можем использовать и недоверенный сертификат.
Удаляем из apk папку META-INF со старой подписью приложения и приступаем к генерации новой.
Создаем хранилище ключей и генерируем в нем ключ для подписи apk:
Подписываем только что сгенерированным ключом наш APK:
Теперь осталось выровнять данные в архиве по четырехбайтной границе:
Источник
Перехват HTTPS-траффика между Android-устройством и внешним сервером
Иногда бывает любопытно подсмотреть, что пересылают туда-сюда разные Android-приложения по HTTP и HTTPS протоколам. Иногда даже при разработке собственного ПО удобно видеть весь трафик в реальном времени. Для реализации этих задач давно придумано много хороших программ, таких, к примеру, как Charles или Fiddler2. На самом деле их намного больше, вот только две вышеуказанные дают возможность нормально просматривать не только HTTP, но и HTTPS.
Трудности начинаются тогда, когда речь заходит о перехвате трафика между Андроид-устройством и внешним сервером. В случае незашифрованного (HTTP-протокол) трафика всё весьма тривиально (вот и инструкция есть) — разрешаем Fiddler2 внешние соединения, в Андроиде устанавливаем прокси сервером адрес нашей машины с Fiddler2 — и вуаля, всё работает. А вот на настройку перехвата HTTPS-трафика у меня ушло чуть больше времени.
Теория
Итак, в чём же сложность? В том, что при использовании протокола HTTPS клиент по-умолчанию проверяет, а действительно ли тот сервер, к которому он подключился, является нужным. Для этого используются сертификаты. И вот у настоящего сервера этот сертификат, понятное дело, тоже настоящий и соответствует открытому URL, а вот у нашего прокси — нет. Для решения этой проблемы в десктопных операционных системах в таких случаях есть возможность сгенирировать в Fiddler2 поддельный сертификат, импортировать его в доверенные — и теперь клиент всегда будет верить, что соединение с Fiddler2 вполне безопасно. К сожалению, с мобильным устройством такой легкий финт ушами не прошел.
Во-первых, возможности импортировать внешний сертификат в Андроиде версий младше 4.0 нет. Есть какие-то не внушающие доверия варианты с рутоваными девайсами — но это не наш путь.
Во-вторых, в Андроид даже версии 4.0 импортировать сертификат Fiddler2 не получается. Дело в том, что генерируемый по-умолчанию сертификат не соответствует каким-то там Андроидовским критериям безопасности и не устанавливается. Его нужно генерировать специальным образом.
В-третьих, совсем даже не факт, что все подряд программы сразу поверят поддельному сертификату. Есть нюансы.
Практика
- Берём устройство с Андроидом версии 4.0 или выше. Нет, девайс с 2.3 не подойдет. Да, эмулятор версии 4.0 подойдет.
- Устанавливаем на компьютер последнюю версию Fiddler2.
- Устанавливаем специальные библиотеки генерации Андроид-совместимого сертификата безопасности отсюда.
- Экспортируем из Fiddler2 сертификат безопасности («Tools->Fiddler Options->HTTPS->Export root certificate to Desktop»). Кладём на флешку, в корень (ну или на эмулятор, если вы используете его).
- На Андроиде добавляем сертификат безопасности в доверенные(«Settings > Security > Install from SD card»)
Запускаем Fiddler2, разрешаем в настройках внешние коннекты .
На Андроиде в настройках сети прописываем в качестве прокси адрес нашей десктопной машины с Fiddler2.
Итак, с браузером получилось. К сожалению, не все программы столь доверчивы, как браузер. К примеру, в моей собственной софтине, где я использую Apache HTTP Client, способ не прокатил — плевал апачевский клиент на доверенные сертификаты операционки. В этом случае мне пришлось отключить эту проверку вручную, таким вот образом:
где EasySSLProtocolSocketFactory взят отсюда и разрешает доверие к любым сертификатам.
Не безопасно, только для отладки!
После этого трафик моей программы стал также успешно отображаться в Fiddler2.
Источник
Fiddler = удобный сниффер + прокси сервер
Привет. В данной статье расскажу как и зачем можно изменять HTTP пакеты при отправке на сервер и при получении ответов от сервера.
В статье много практических примеров.
Зачем это делать ?
Пример 1. Анализ трафика.
Пользователи вашей сети пользуются вашим прокси-сервером. Вы можете увидеть на какие сайты заходят пользователи, запрещать дальнейшие переходы на эти сайты.
Пример 2. Сбор данных.
Ваши пользователи пользуются через вас некоторыми веб-ресурсами. Например, они вводят vin-номер своего автомобиля на сайте дилера авто и получают в ответ данные этого автомобиля. Вы можете сохранять эти данные в свою базу данных.
Пример 3. Подмена HTTP-пакетов.
Вам нужно изменить для ваших пользователей внешний вид сайта. Вы можете изменить стили сайта, скрывать любые элементы, добавить свои элементы, вырезать определенные слова или заменить их на другие слова, изменить картинку сайта на любую свою.
Пример 4. Подмена POST-данных.
Вам нужно подправить данные передаваемые на веб-сервер через POST-запрос. Существует множество информации передаваемой в POST-запросах. Пример: отправка логина/пароля на сервер в процессе авторизации. Или онлайн тест отправляет на сервер результаты вашего теста.
Установка Fiddler
Установка простая и быстрая.
Настройка Fiddler
В меню File есть опция «Capture Traffic«. По умолчанию опция включена. Это означает что Fiddler прописывает в реестре Windows себя в качестве прокси-сервера. Браузеры Internet Explorer, Edge, Chrome используют данную настройку, а значит HTTP-пакеты от этих браузеров пойдут через Fiddler.
Если опция «File -> Capture Traffic» выключена, то Fiddler перестает работать как системный прокси-сервер и перехватывает только те пакеты, которые идут непосредственно на адрес Fiddler. Это может быть когда вы настроили ваше приложение или браузер сами для работы через ip/port Fiddler. По умолчанию Fiddler слушает на порту 127.0.0.1:8888
Опция «Keep: All sessions«.
В данном режиме Fiddler не очищает журнал собранных HTTP-пакетов. Если требуется продолжительная работа Fiddler, то при большой нагрузке этих пакетов будет очень много и Fiddler скушает всю доступную оперативную память компьютера. Чтобы этого не случилось переключите в режим «Keep: 100 sessions».
Опция «Decode«.
По умолчанию выключена. В процессе анализа собранных пакетов рекомендуется включить чтобы пакеты автоматически декодировались. Либо можно выделить собранные пакеты через Ctrl+A, вызвать меню нажатием правой кнопки мыши по выделенным пакетам и нажать «Decode Selected Sessions».
Основные настройки
Переходим в «Tools -> Options. «.
Вкладка «HTTPS».
После установки Fiddler не собирает HTTPS-трафик, это необходимо включить. Ставим галочку в опции «Decrypt HTTPS traffic«. После этого Fiddler сгенерирует самоподписанный сертификат и спросит хотите ли установить данный сертификат. Отвечаем да.
Опция «Ignore server certificate errors (unsafe)» — сразу можно не включать. На некоторых порталах бывают ошибки сертификатов, но это редко. Как увидите так включите )
Настройка протоколов. По умолчанию стоит значение » ;ssl3;tls1.0″. Советую сразу установить значение на » ;ssl3;tls1.0;tls1.1;tls1.2″. После изменения настроек необходимо перезапустить программу чтобы настройки вступили в силу.
«Trust Root Certificate» — если сгенерированный Fiddler сертификат вы не установили после включения опции «Decrypt HTTPS traffic», то можно это сделать здесь.
«Export Root Certificate to Desktop» — если вы планируете использовать Fiddler как прокси-сервер локальной сети, то на каждом устройстве пользователя необходимо установить сгенерированный выше сертификат. С помощью этой опции сохраняете сертификат на ваш рабочий стол.
«Reset All Certificates» — в некоторых случаях необходимо сгенерировать новый сертификат взамен старого. В этом случае сбрасываем все Fiddler-сертификаты и генерируем новый сертификат.
Вкладка «Connections».
Здесь устанавливаем на каком порту Fiddler работает как прокси-сервер. Порт по умолчанию «8888».
«Allow remote computers to connect» — включаем опцию чтобы Fiddler начал принимать подключения от других компьютеров.
«Act as system proxy on startup» — по умолчанию опция включена. Если включена, то при запуске опция «File -> Capture Traffic» включена.
После изменения данных настроек необходимо перезапустить программу чтобы настройки вступили в силу.
Вкладка «Gateway».
Здесь устанавливаем куда Fiddler отправляет входящие пакеты, какой прокси использует.
«Use System Proxy (recommended)» — использование системного прокси из реестра текущего пользователя.
«Manual Proxy Configuration» — возможность задать вручную прокси-сервер.
«No proxy» — задаем что выход в Интернет напрямую, без использования прокси.
После изменения данных настроек необходимо перезапустить программу чтобы настройки вступили в силу.
Установка сертификатов на Windows устройствах
После того как сгенерированный сертификат скопирован на рабочий стол этот сертификат необходимо установить на каждое устройство которое будет использовать данный Fiddler в качестве прокси-сервера.
Для установки сертификата используем консоль управления MMC: в коммандной строке вводим команду «mmc».
В меню файл выбираем «Добавить или удалить оснастку«. Из доступных оснасток выбираем «Сертификаты» и с помощью кнопки «Добавить» выбираем данную оснастку. Нажимаем «Ок» и выбираем «учетной записи компьютера«. Это нужно чтобы открыть сертификаты которые установлены для всего компьютера, а затем установить сертификат Fiddler именно в это хранилище. Если открыть сертификаты «моей учетной записи пользователя«, то после установки сертификата Fiddler в это хранилище другие пользователи данного компьютера не смогут подключиться к Fiddler.
Установку сертификата производим в «Доверенные корневые центры сертификации».
Если ваши компьютеры находятся в домене, то используйте инструменты домена для установки сертификата каждому пользователю или на каждый компьютер сети.
Анализ трафика
В процессе работы Fiddler сниффит все HTTP-запросы и их обычно много. Для поиска необходимых запросов можно использовать фильтры. Правой кнопкой мыши выбираем лишний запрос, выбираем «Filter Now» и «Hide ‘. ‘» чтобы скрыть запросы к данному домену. Можно удалять вручную выделенные запросы используя кнопку «Delete«.
Кроме использования фильтров можно искать отдельный текст в теле запросов/ответов: «Ctrl+F» для открытия меню поиска. Найденные запросы подсвечиваются по умолчанию желтым цветом.
Изменение данных запросов
В Fiddler существует инструмент «Fiddler ScriptEditor» (Редактор скриптов) для создания правил модификации трафика. Запуск редактора скриптов через «Ctrl+R» или выбора пункта меню «Rules -> Customize Rules. «.
В редакторе скриптов есть два основных метода: «OnBeforeRequest» и «OnBeforeResponse«:
«OnBeforeRequest» — выполнение скриптов в этом методе происходит перед отправкой пакетов на веб-сервер.
«OnBeforeResponse» — выполнение скриптов в этом методе происходит после получения ответа от веб-сервера.
Ниже приведены примеры скриптов с указанием в каком методе их расположить.
Задача 1: Запрет сайта
Запрещаем переход на адрес сайта содержащий строку.
Задача 2: Запрет загрузки ресурса
Запрещаем загрузку «.svg» файлов для заданного адреса сайта.
Задача 3: Переадресация запроса
Переадресация запроса на адрес сайта содержащий строку.
Задача 4: Сбор данных
Пользователи подключаются через данный прокси-сервер и делают в браузерах некоторые запросы вида «https://myhost.ru?key=abcd&vin=VF38BLFXE81078232&lang=ru«. Задача записать в базу данных событие поиска и передать значение vin-номера. Данный скрипт создает файлы с названием включающем vin-номер. Кроме скрипта необходимо создать утилиту/службу, которая раз в заданный интервал читает каталог «C:\vinsearch\» и записывает данные в базу данных.
Задача 5: Изменить текст в ответе
В данном примере меняем текст «Иванов» на «Петров«.
Задача 6: Заменить ресурс веб-портала на локальный ресурс
Заменим картинку веб-портала на картинку расположенною на локальном диске.
Задача 7: Изменение свойств HTML-объектов
Например, есть картинка с заданными размерами в HTML и нужно эти размеры изменить.
Задача 8: Скрыть элементы по className меняя css-файлы
В данном примере скрываем элементы зная их className в css-файле добавляя свойство «visibility: hidden;«
Задача 9: Заставить страницу открываться в текущем окне
Пример: существует JavaScript, который открывает ссылку в новом окне. Нужно сделать чтобы ссылка открывалась в текущем окне.
Задача 10: Выполнение скриптов для определенных IP
В данном примере меняем текст «Иванов» на «Петров» только для IP = «192.168.0.100«
Задача 11: Меняем css-стили портала
Css-файлы веб-портала можно сохранить на локальном диске, отредактировать и настроить скрипт отдавать стили с локального диска, а не с портала.
Задача 12: Запрет PUT-команды и аналогичных
Запрет команды по ее типу: «PUT«, «DELETE«, etc.
Задача 13: Изменение тела POST-запроса
Изменить тело POST-запроса для заданного портала. При авторизации на данном портале вне зависимости от введенных пользователем данных на веб-портал отправятся данные из скрипта.
Задача 14: Меняем заголовки HTTP-пакета
Заголовки пакетов можно легко редактировать: удалять, добавлять, изменять.
Задача 15: Меняем Cookie
Работа с Cookie: добавление, удаление, редактирование
Источник