Как отследить http запросы с компьютера

Обновлено: 02.07.2024

Меня всегда напрягало то, как навязчиво Google AdSense подсовывал контекстную рекламу в зависимости от моих старых запросов в поисковике. Вроде бы и времени с момента поиска прошло достаточно много, да и куки и кеш браузера чистились не раз, а реклама оставалась. Как же они продолжали отслеживать меня? Оказывается, способов для этого предостаточно.

Небольшое предисловие

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

Явные идентификаторы

Данный подход довольно очевиден, все, что требуется, — сохранить на стороне пользователя какой-то долгоживущий идентификатор, который можно запрашивать при последующем посещении ресурса. Современные браузеры предоставляют достаточно способов выполнить это прозрачно для пользователя. Прежде всего это старые добрые куки. Затем особенности некоторых плагинов, близкие по функционалу к кукам, например Local Shared Objects во флеше или Isolated Storage в силверлайте. HTML5 также включает в себя несколько механизмов хранения на стороне клиента, в том числе localStorage , File и IndexedDB API . Кроме этих мест, уникальные маркеры можно также хранить в кешированных ресурсах локальной машины или метаданных кеша ( Last-Modified , ETag ). Помимо этого, можно идентифицировать пользователя по отпечаткам, полученным из Origin Bound сертификатов, сгенерированных браузером для SSL-соединений, по данным, содержащимся в SDCH-словарях, и метаданным этих словарей. Одним словом — возможностей полно.

Cookies

Local Shared Objects

Удаление данных из localStorage в Firefox

Изолированное хранилище Silverlight

Программная платформа Silverlight имеет довольно много общего с Adobe Flash. Так, аналогом флешевого Local Shared Objects служит механизм под названием Isolated Storage . Правда, в отличие от флеша настройки приватности тут никак не завязаны с браузером, поэтому даже в случае полной очистки куков и кеша браузера данные, сохраненные в Isolated Storage , все равно останутся. Но еще интересней, что хранилище оказывается общим для всех окон браузера (кроме открытых в режиме «Инкогнито») и всех профилей, установленных на одной машине. Как и в LSO, с технической точки зрения здесь нет каких-либо препятствий для хранения идентификаторов сессии. Тем не менее, учитывая, что достучаться до этого механизма через настройки браузера пока нельзя, он не получил такого широкого распространения в качестве хранилища для уникальных идентификаторов.

Где искать изолированное хранилище Silverlight

HTML5 и хранение данных на клиенте

Настройка локального хранилища для Flash Player

Кешированные объекты

ETag и Last-Modified

Сервер возвращает клиенту ETag

HTML5 AppCache

Application Cache позволяет задавать, какая часть сайта должна быть сохранена на диске и быть доступна, даже если пользователь находится офлайн. Управляется все с помощью манифестов, которые задают правила для хранения и извлечения элементов кеша. Подобно традиционному механизму кеширования, AppCache тоже позволяет хранить уникальные, зависящие от пользователя данные — как внутри самого манифеста, так и внутри ресурсов, которые сохраняются на неопределенный срок (в отличие от обычного кеша, ресурсы из которого удаляются по истечении какого-то времени). AppCache занимает промежуточное значение между механизмами хранения данных в HTML5 и обычным кешем браузера. В некоторых браузерах он очищается при удалении куков и данных сайта, в других только при удалении истории просмотра и всех кешированных документов.

SDCH-словари

SDCH — это разработанный Google алгоритм компрессии, который основывается на использовании предоставляемых сервером словарей и позволяет достичь более высокого уровня сжатия, чем Gzip или deflate. Дело в том, что в обычной жизни веб-сервер отдает слишком много повторяющейся информации — хидеры/футеры страниц, встроенный JavaScript/CSS и так далее. В данном подходе клиент получает с сервера файл словаря, содержащий строки, которые могут появиться в последующих ответах (те же хидеры/футеры/JS/CSS). После чего сервер может просто ссылаться на эти элементы внутри словаря, а клиент будет самостоятельно на их основе собирать страницу. Как ты понимаешь, эти словари можно с легкостью использовать и для хранения уникальных идентификаторов, которые можно поместить как в ID словарей, возвращаемые клиентом серверу в заголовке Avail-Dictionary , так и непосредственно в сам контент. И потом использовать подобно как и в случае с обычным кешем браузера.

Прочие механизмы хранения

Протоколы

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

Характеристики машины

Все рассмотренные до этого способы основывались на том, что пользователю устанавливался какой-то уникальный идентификатор, который отправлялся серверу при последующих запросах. Есть другой, менее очевидный подход к отслеживанию пользователей, полагающийся на запрос или измерение характеристик клиентской машины. Поодиночке каждая полученная характеристика представляет собой лишь несколько бит информации, но если объединить несколько, то они смогут уникально идентифицировать любой компьютер в интернете. Помимо того что такую слежку гораздо сложнее распознать и предотвратить, эта техника позволит идентифицировать пользователя, сидящего под разными браузерами или использующего приватный режим.

«Отпечатки» браузера

Наиболее простой подход к трекингу — это построение идентификаторов путем объединения набора параметров, доступных в среде браузера, каждый из которых по отдельности не представляет никакого интереса, но совместно они образуют уникальное для каждой машины значение:

Сетевые «отпечатки»

Еще ряд признаков кроется в архитектуре локальной сети и настройке сетевых протоколов. Такие знаки будут характерны для всех браузеров, установленных на клиентской машине, и их нельзя просто скрыть с помощью настроек приватности или каких-то security-утилит. Они включают в себя:

Поведенческий анализ и привычки

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

И это лишь очевидные варианты, которые лежат на поверхности. Если копнуть глубже — можно придумать еще.

Подытожим

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

Но при работе с веб-сервисами (web services), когда, например, нужно отследить по какому URL адресу сервис осуществил запрос, без дополнительной настройки программы Fiddler данного действия не увидеть. Это возможно, если сайт работает через инструмент Cassini, но в случае с IIS - Fiddler не покажет необходимую информацию о трафике сервиса.

Причина кроется в учетных записях, от имени которых работают IIS и Fiddler. Они оба запускаются под администратором. А вот приложения (сайты, сервисы) под управлением IIS работают уже из-под учетной записи "Network Service". Если бы можно было запустить Fiddler под Network Service, проблема была бы решена, но к сожалению, это невозможно.

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

Сделаем следующие шаги:

1) Добавим пользователя, обладающего правами администратора, в группу IIS_IUSRS (для IIS 7 и младше) или в группу IIS_WPG (для IIS 6 и старше) (группа обладает правами сетевой службы).

Для этого переходим:

Computer Management -> Local Users and Groups -> Groups -> IIS_IUSRS/IIS_WPG и добавляем в группу администратора.

2) Теперь необходимо настроить пул веб-приложения (Application Pool) для его запуска под учетной записью администратора.

Здесь может быть два варианта. Если для сайта, который нужно отслеживать, выделен отдельный пул, то настройку можно производить конкретно для него. Либо создать новый пул специально для подобных процедур и затем при необходимости привязывать его к нужным приложениям.

Итак, заходим в IIS, в списке пулов (Application Pools) выбираем нужный пул и переходим в его расширенные настройки (Advanced Settings):

В настройках пула в параметре Identity выбираем Custom account и по нажатию на Set - прописываем учетные данные администратора (логин и два раза пароль):

При необходимости связываем пул приложения (Application Pool) с веб-приложением. Для этого переходим в расширенные настройки нужного сайта/приложения и указываем пул:

Теперь можно запускать Fiddler, стартовать сайт/сервис и программа будет отслеживать все его запросы.

Спутник - оптимизация и SEO продвижение сайта в этом поисковом сервисе или Спутник для вебмастера

Установка CentOS 7 на виртуальную машину Hyper-V второго поколения (Generation 2)

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

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

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 доступны следующие фильтры:

Использовал скрипач, но это только исходящие, а не входящие (извне машины), или я настроил его неправильно?

Это мое веб-приложение, которое должно получать POST от внешнего сервера.

Ребята нашли идеальный способ отслеживать ВЕСЬ трафик, который идет локально между запросами с моей машины на мою машину:

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

Для этого добавьте маршрут с помощью <ip address> <gateway> :

Затем запустите захват на wirehark (убедитесь, что вы выбрали интерфейс, через который проходят байты), затем отфильтруйте.

Новые добавленные маршруты будут отображаться черным цветом. (поскольку это локальные адреса)

На веб-сайте Fiddler есть инструкции по 2 различным способам сделать это. Вот копия шагов:

Шаг № 0

Прежде чем любой из следующих вариантов будет работать, вы должны разрешить другим компьютерам подключаться к Fiddler. Для этого нажмите «Инструменты»> «Параметры Fiddler»> «Подключения» и установите флажок «Разрешить удаленным компьютерам подключаться». Затем закройте Fiddler.

Вариант 1. Настройте Fiddler как обратный прокси

Вариант 2. Напишите правило FiddlerScript

В качестве альтернативы вы можете написать правило, которое делает то же самое.

Предположим, вы запускаете веб-сайт на 80-м порту машины с именем WEBSERVER. Вы подключаетесь к веб-сайту с помощью Internet Explorer Mobile Edition на устройстве Windows SmartPhone, для которого вы не можете настроить веб-прокси. Вы хотите захватить трафик с телефона и ответ сервера.

Запросы со смартфона появятся в Fiddler. Запросы перенаправляются с порта 8888 на порт 80, на котором работает веб-сервер. Ответы отправляются обратно через Fiddler на смартфон, который не знает, что контент изначально поступил с порта 80.

Вы можете скачать его здесь

Настройте Fiddler как «обратный прокси» в Windows

(для Mac см. ссылку в комментарии Партизано ниже)

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

Что значит настроить Fiddler как «обратный прокси»?

ПРИМЕЧАНИЕ. Чтобы это сработало, любой запрос, который вы хотите перехватить, должен быть отправлен на порт 8888 .

Вы делаете это, добавляя: 8888 к вашему имени хоста , например, так для маршрута MVC:

Запустите Fiddler от имени администратора. Перейдите в Инструменты> Параметры Fiddler> Подключения и убедитесь, что установлен флажок «Разрешить удаленным компьютерам подключаться», а для параметра «Fiddler прослушивает порт» установлено значение 8888:

Настройте Fiddler для пересылки запросов, полученных через порт 8888, на порт 80

Убедитесь, что порт 8888 открыт на брандмауэре.

Вы должны убедиться, что порт 8888 открыт для внешних запросов (это не будет по умолчанию, если ваш сервер защищен брандмауэром)

Вот и все! Теперь Fiddler должен быть настроен как обратный прокси-сервер, чтобы перехватывать все запросы с порта 8888 (чтобы вы могли просматривать их в Fiddler), а затем он будет перенаправлять их на ваш веб-сервер для фактической обработки.

Проверить запрос

В качестве альтернативы вы можете составить запрос, используя другой экземпляр Fiddler на удаленном компьютере, используя URL-адрес, аналогичный указанному выше. Это позволит вам сделать запрос GET или POST.

ВАЖНО: после того, как вы закончите просмотр своих запросов, вернитесь в Инструменты> Параметры Fiddler> Подключения и удалите параметр «Разрешить удаленным компьютерам подключаться», иначе третьи стороны смогут перебрасывать трафик через ваш сервер.

Microsoft Message Analyzer является преемником Microsoft Network Monitor 3.4.

Сценарий трассировки: «Локальные сетевые интерфейсы (Win 8 и более ранние версии)» или «Локальные сетевые интерфейсы (Win 8.1 и более поздние версии)» зависят от вашей ОС

Уровень синтаксического анализа: полный

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

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

Используйте TcpView для просмотра прослушиваемых портов и подключений. Однако это не даст вам запросов.

Чтобы видеть запросы, вам понадобится обратный прокси, о котором я не знаю ни одного такого инструмента.

Используйте трассировку, чтобы предоставить вам части запросов (первые 1 КБ запроса ).

Возможно, вам придется запустить два экземпляра Wireshark, один для локального захвата, а один для удаленного захвата. Я не уверен.

Нагрузка на сервер является важным звеном администрирования веб сервера, отслеживание запросов помогает быстро искать ошибочные запросы и устранять их раньше чем они вернуться к вам со статистикой вебмастера. По умолчанию в конфигурационном файле веб сервера апаче закоментрировано определение хоста в dns что в свою очередь еще больше усложняет понимание того, что приходит на сайте. Упростить все это удалось написанием скрипта отображающего все запросы к веб серверу в режиме реального времени. Сохраняя несколько сотен запросов удалось посчитать время загрузки. Это процент от реально прошедшего времени суммы времени потраченных на вывод ресурсов. Удобный вывод времени затраченного на выполнение каждой страницы сайта стал незаменим в поиске слабых мест. Небольшой массив со списком шаблонов поисковых систем позволил выделить их отдельным цветом в ленте запросов.

Запускается вывод с использованием консоли линукс пробросом по ssh вывода из логов. Плюсом стала минимальная нагрузка при этом на сервер, так как все вычисления происходят на локальной странице. Помогает в подсчетах небольшой php скрипт на вход которого поступает вывод данных из /var/log/apache2/access.log который в свое время подсвечивает важные части лога яркой подсветкой.

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

Важно видеть в подобной ленте ботов, эту задачу помогла решить установка вывода в лог ДНС имени клиента. Эта настройка также выключена по умолчанию в конфигурационном файле.

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

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