TLDR; Коллекция советов по работе с HTTP-прокси. Применяйте прокси на localhost или с мобильного, используя имя своего компьютера или частный ip-адрес из ifconfig (или ipconfig). Цепочка прокси-серверов позволяет использовать возможности всех инструментов одновременно и делает манипуляцию запросами более надежной. Charles Proxy может проверять HTML как часть тестирования.

Рекомендации:

Используйте прокси для доступа к сервисам на localhost, используя имя своего компьютера или частный ip-адрес из ifconfig (или ipconfig).
Мобильные устройства могут использовать прокси на вашей основной машине, если вы найдете ее ip-адрес и настроите инструмент для указания прокси на этом ip-адресе.
Используйте плагин для браузера, например Foxy Proxy Standard, чтобы упростить переключение между прокси.
Charles Proxy может в фоновом режиме проверять HTML в процессе тестирования.

Работа с Localhost

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

Общие методы

Вместо localhost:80

Использовать:

имя машины, например, machinename:80
ваш частный ip-адрес, например 192.168.1.132:80

Существует ряд частных и недоступных из интернета ip-адресов

www.arin.net/reference/research/statistics/address_filters

Ip-адрес вашей машины можно посмотреть с помощью ifconfig или ipconfig (если вы работаете на Windows).

Использование прокси на локальной машине обычно подразумевает использование этого ip-адреса и должно работать независимо от выбранного прокси.

Когда мне нужно найти ip-адрес на mac, я комбинирую ifconfig с grep, чтобы упростить просмотр результатов:

ifconfig | grep "inet "

Charles Proxy

www.charlesproxy.com/documentation/faqs/localhost-traffic-doesnt-appear-in-charles

Charles Proxy поддерживает адрес localhost.charlesproxy.com, поэтому можно добавить порт, на котором он запущен, и трафик появится в Charles.

Fiddler

docs.telerik.com/fiddler/Configure-Fiddler/Tasks/MonitorLocalTraffic

Fiddler поддерживает два специальных адреса, которые можно использовать вместо localhost

Демо-видео

Связывание нескольких HTTP-прокси в цепочку

Я связываю отладочные HTTP-прокси в цепочку.

Таким образом, я могу одновременно использовать их фичи:

Fiddler Autoresponders
построение карты сайта с помощью Burp Suite
множественные брейкпоинты в ZAP
написание скриптов в ZAP для изменения запросов и ответов.

Я также обнаружил, что это полезно при создании сценариев в прокси-серверах. Иногда по какой-то причине сгенерированный http-запрос после внесения поправок скриптом отправляется в браузер или на сервер не полностью. Но когда я выстраиваю цепочку прокси-серверов, и скрипт, вносящий поправки в запрос или ответ, проходит через другой прокси-сервер, прежде чем попасть к адресату, это, похоже, помогает.

Fiddler

Fiddler работает на системе Windows без каких-либо дополнительных настроек. Все остальные прокси указывают на Fiddler как на downstream-прокси.

Когда Fiddler запущен, проверьте настройки, направив браузер через Fiddler.

Burp Suite

Вкладка Burp Suite Options. Upstream Proxy Servers. Добавьте запись для Fiddler:

Destination Host: *
Proxy Host:: localhost
Proxy Port: 8888

На этом этапе еще раз протестируйте настройки. Не стоит соединять все в цепочку и пытаться понять, где проблема. Запустите браузер через Burp Suite и убедитесь, что трафик проходит через него.

Если вы застряли, используйте вкладку Alerts в Burp Suite для проверки ошибок.

ZAP

Tools Options Connection. Направьте его через Burp Suite

Порт: 8082 (или тот, к которому вы привязали Burp Suite).

Найдите порт, к которому вы привязали ZAP в Tools Options Local Proxy.

И теперь направьте браузер через этот порт.

Завершение

У вас должно все получиться.

Если нет, просто вернитесь к предыдущему шагу.

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

Не забудьте вернуть все в исходное положение, когда закончите.

На видео курса Technical Web Testing 101 я показываю этот процесс подробнее.

Полезные ссылки:

Мобильные устройства

Настройка просмотра HTTP-трафика с мобильных браузеров не занимает много времени, но есть несколько подводных камней, о которых следует помнить:

Найти правильный IP-адрес на десктопе.
Изменить настройки прокси на телефоне.
Убедиться, что прокси-сервер разрешает внешние подключения.
Убедиться, что и мобильное устройство и прокси-машина находятся в одной сети.

Я обычно использую:

Телефон, подключенный к сети Wi-Fi.
Компьютер с Windows, подключенный к той же сети через проводное соединение (или ноутбук, подключенный через беспроводное соединение).

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

Запустите Fiddler.
Убедитесь, что в Fiddler включена настройка «Разрешить подключение удаленных компьютеров» (“Allow remote computers to connect”, через Tools Fiddler Options Connections).
Запустите командную строку и с помощью команды «ipconfig» откройте текущий список ip-адресов для вашего компьютера.
Настройте мобильное устройство.

Устройства Android

На мобильном устройстве:

Откройте Настройки.
Настройки Wi-Fi.
Длительным нажатием на пункт «используемая беспроводная сеть» (Wireless Network) откройте настройки подключения (connection settings).
Выберите «Изменить конфигурацию сети» (Modify Network Config).
Настройки прокси (Proxy Settings) — Вручную (Manual).
- Измените имя хоста прокси на IP-адрес вашего компьютера.
- Добавьте порт для отладочного прокси, например 8888 для Fiddler.

После этого ваш браузер должен подключиться к прокси.

(Примечание: приведенное выше относится к Android, но принцип работы одинаков и для других операционных систем).

Другие приложения могут использовать прокси другим образом. Возможно, вам потребуется настроить проброс портов с помощью adb для того чтобы они работали через прокси (не спрашивайте меня, как это сделать, погуглите. Я давно этого не делал, поэтому мои воспоминания о том, как я ковырялся в android-е, чтобы заставить его работать, довольно туманны).

На Android: Chrome, Firefox, Dolphin и встроенный браузер работали без проблем. У меня возникли проблемы с подключением Opera, но я даже не стал пытаться выяснить причину.

Попробуйте и посмотрите, что у вас получится.

Это значительно повышает наглядность тестирования при работе через мобильные устройства.

Дополнительные примечания:

Для Burp Suite в разделе «Proxy Options» измените Proxy Listener to Bind на “All interfaces”.

Как подключить прокси к устройствам iOS

Подключение iOS-устройства к HTTP-прокси происходит примерно так же, как и в случае с Android-устройствами.

Зайдите в настройки iOS:

В разделе Wi-Fi
Выберите значок информации (i) рядом с вашей сетью Wi-Fi.
В нижней части экрана находятся настройки HTTP-прокси.
Установите для него значение Manual.
Введите IP-адрес и порт сервера вашего прокси.

Готово.

Теперь HTTP-трафик должен проходить через десктопный прокси-сервер.

iOS хорошо кэширует, поэтому я либо очищаю кэш перед началом тестирования с помощью настроек Safari и пункта «Очистить Cookies и данные», либо использую ссылку «Private» в нижней части Safari перед началом новой сессии.

Я обнаружил, что iOS не любит подключаться к некоторым сетям, поэтому я настроил локальную точку доступа с помощью connectify.me, и это немного облегчило мне жизнь.

Не забудьте отключить прокси-сервер, когда закончите работу.

Простая настройка Chrome и Firefox

Одним из инструментов, который помог мне извлечь больше преимуществ прокси, является плагин для браузера под названием FoxyProxy.

FoxyProxy Standard — см. getfoxyproxy.org/.

Установив FoxyProxy, я запускаю прокси и выбираю конфигурацию. Большинство прокси по умолчанию используют 8080, поэтому одна конфигурация обычно отвечает большинству моих потребностей.

Без этого мне приходится возиться с настройками браузера или сети, и я никогда бы не стал использовать прокси.

Это также позволяет легко отключить проксирование и вернуться к нормальной работе.

Если вы работаете с HTTP-прокси, я рекомендую установить плагин, который поможет переключаться между ними и отключать их.

Проверка HTML с помощью Charles Proxy

TLDR; Charles Proxy может использовать validator.w3.org и показывать результаты в графическом интерфейсе прокси.

Посмотрев на свой стандартный процесс тестирования для веб и поняв, что он не включает проверку HTML по умолчанию, я решил найти самый простой способ добавить ее в свой процесс. Я вообще считаю, что чем проще я могу добавить что-то в свой процесс, тем больше вероятность того, что я буду это использовать — как и в случае с расширением Foxy Proxy.

Мы все теперь используем Dev Tools по умолчанию

Инструменты Dev Tools (инструменты разработчика) теперь по умолчанию включены в каждый браузер. Раньше нам приходилось загружать плагины и расширения. Но теперь, когда они по умолчанию доступны одним щелчком мыши, у нас нет оправданий.

Но валидация HTML, похоже, отсутствует. Я могу «проверить» производительность страницы в инструментах разработчика Chrome, и считаю проверку использования CSS весьма полезной. Но валидация HTML отсутствует.

Что представляет собой больший технический риск для функциональности ваших продуктов? CSS? Скорость? HTML?

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

Так что же поможет мне разобраться с основами? И сделать это без излишних усилий.

Я упоминал о validator.w3.org в другой статье. Но это требует работы. Приходится проверять каждую страницу по очереди.

Быстрый поиск в Интернете выявил множество инструментов проверки HTML. Некоторые из них на первый взгляд выглядят вполне неплохо. Но они требуют добавления нового типа инструмента в мой рабочий процесс, что означает, что мне придется изменить способ тестирования, а это в свою очередь значит, что мне придется больше работать, чтобы внедрить его.

Что мне действительно было нужно, так это прокси, проверяющий HTML

Я поискал плагины Fiddler для проверки HTML, но не нашел ни одного.
Я не мог вспомнить, чтобы какой-либо из моих прокси предлагал проверку HTML.

Но при поиске в Интернете прокси-серверов, проверяющих HTML, я обнаружил Charles Proxy.

Я уже использовал Charles Proxy, но он, по моему мнению, не отличался какими-либо преимуществами. Видимо, мне не хватало функции проверки HTML.

Но вот она, как на ладони.

Что делает опция Validate в Charles Proxy?

Учитывая урлы, которые вы выделили в «сессии», Charles откроет новую вкладку «валидация» и передаст каждый из этих адресов валидатору w3.org и отформатирует результаты.

Цепочка прокси позволяет воспользоваться этим преимуществом, даже если мы предпочитаем использовать один из других прокси для наблюдения и манипуляций. Я всегда могу добавить Charles в цепочку и использовать его для проверки в процессе работы.

Поскольку Charles является кроссбраузерным, я использую его для тестирования на Windows и Mac.

Резюме

Изучите свой собственный рабочий процесс.
Найдите инструменты, которые вписываются в него.
Узнайте, что умеют делать инструменты, которыми вы уже пользуетесь.
Попытайтесь плавно добавить автоматическую валидацию в свой рабочий процесс.
Charles Proxy может использовать валидатор w3.org для проверки HTML.

Признаю, что с этими пунктами у меня возрос объем работы и количество процессов, требующих наблюдения. Но я все же надеюсь, что эти нововведения положительно скажутся на процессе тестирования в общем.

Советы по тестированию HTTP-прокси