Подмена запроса в браузере

Обновлено: 08.07.2024

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

Принцип работы

Вот типичный пример работы рядового поисковика. Существует программный модуль (паук, spider), который бродит по ссылкам, считывает содержание страниц, и для каждого слова делает запись в индексном файле. Например, для слова «халява» будет создана примерно такая запись в индексном файле: «халява1». Затем в файле, где хранятся ссылки будет сделана запись «1 URL страницы». Пояснение: 1 – это номер, который связывает записи в индексном файле (таблице) и файле ссылок. Потом паук поползёт на другую страницу и наткнётся там опять на слово «халява». Теперь в индексной таблице он создаст запись: «халява12», а в таблице ссылок: «2 URL страницы». Когда пользователь наберет в строке поиска слово «халява», поисковик посмотрит индексный файл, найдет там строчку «халява», прочитает номера 12 и найдет в таблице ссылок адреса, соответствующие номеру 1 и 2, и выдаст их пользователю. Вот основной принцип работы поисковых систем, который носит название индексирование. От чего тогда зависит положение сайтов в результате поиска? Ответ: от релевантности, т.е. от соответствия документа запросу юзера. От чего зависит релевантность? Вообще, алгоритмы оценки релевантности отличаются у разных поисковых системах, и держатся в строжайшем секрете. Вот основные параметры:

Количество повторяющихся слов в документе.
Ключевые слова, заключенные в теги , , , , . Т.е. если страница связана с халявой, то лучше слово «халява» написать между тегами, , и в дальнейшем тексте выделять это слово.
Расстояние между ключевыми словами в документе. Чем меньше расстояние, тем выше релевантность.
Индекс цитирования – величина, обозначающая количество ссылок с других ресурсов на данный сайт. Чем больше сайтов ссылается на данный ресурс, тем больше индекс цитирования. Имеет значение и популярность сайта с которого идет ссылка.
Не менее важный параметр: толщина кошелька владельца ресурса. Поисковые системы делают люди, которым тоже хочется есть, пить пиво, покупать журнал «Хакер». И они показывают рекламу непосредственно в результатах поиска. Оплаченные ссылки, показывающиеся в верхних строчках результата поиска, не очень часто оказываются подходящими к запросу.

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

Обман поисковиков

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

Повышение релевантности

Теперь о том, что нужно сделать, чтобы действительно повысить релевантность ресурса:

Самостоятельно прописывать ключевые слова на каждой странице сайта, стараясь, чтобы они максимально соответствовали тематике страницы;
Не ставить запятые после ключевых слов. Во-первых, это увеличивает размер файла, во-вторых, большинство поисковиков читает только первые 200-250 символов;
Составлять очередность слов в соответствии их важности. Самые важные слова должны стоять вначале;
Лучше, если слова, используемые в тегах , , , , а также в атрибуте ALT будут встречаться в ключевых словах;
Не стоит повторять ключевые слова на разных страницах сайта;
Некоторые поисковики отображают описание страницы из тега , а некоторые из первых строчек документа. Описание надо составлять так, чтобы юзеру захотелось зайти на сайт. Если первые строчки текста на странице адаптировать под описание не хочется, то можно пойти на хитрость. Сделать невидимый слой, с помощью каскадных стилей таблиц (CSS), и разместить его после тега . Т.о. поисковик, который отображает первые строчки документа будет отображать текст в невидимом слое. Стоит отметить, что не стоит составлять большое описание страницы, поскольку поисковики выводят обычно только первые 170 символов.
Поисковые роботы плохо относятся к таблицам.
На каждой странице используй как можно больше ссылок на другие страницы твоего ресурса и как можно меньше на страницы других сайтов.

Как я уже говорил, оценка релевантности различается у разных поисковых систем. Более 90% всех запросов в мире приходится всего на пару десятков поисковиков, поэтому есть смысл рассмотреть технологию работы самых популярных из них.

Советы по оптимизации страниц для Yandex’а

С момента добавления сайта в Апорт до момента его появления в поисковой базе проходит от двух-трех дней до двух недель. Не индексирует страницы, в адресе которых встречается символ «?». Кроме текста, который видит посетитель, Апорт индексирует еще заголовок документа (TITLE), ключевые слова (META KEYWORDS), описания страниц (META DESCRIPTION) и подписи к картинкам (ALT). Кроме того, Апорт индексирует как принадлежащие документу тексты гиперссылок на этот документ с других страниц, находящихся, как внутри сайта, так и за его пределами, а также составленные (или проверенные) редакторами описания сайтов из каталога.

Релевантность в Google зависит от:

индекса цитирования;
ключевых слов;
ключевых слов в ссылках;
выделенных слов.

Поисковой робот Google отличается своим умением глубоко индексировать сайт, т.е. он старается охватить максимальное количество ссылок с одной страницы.

Особенности поиска на AltaVista: большую роль играет наличие ключевых слов в теге , также подписи к картинкам (ALT). Большую роль играют ключевые слова, в первой 1000 символов.

Ну вот и все. Хочу отметить, что оптимизация страниц для поисковиков – это, пожалуй, самый важный этап в раскрутке сайта. Обмануть поисковик можно, но подумай, нужно ли тебе это? Ведь ничего, кроме негативной реакции посетителя ты не добьешься. А правильно оптимизированный сайт будет привлекать куда более активную аудиторию, такой трафик очень качественный и высоко ценится, поскольку пользователь приходит на твой сайт с определенной целью и намерениями.

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

Возникает вопрос, если вдруг нужна подмена личности через отдельные вкладки или окна браузеров с анонимностью 100% по whoer. Какой браузер выбрать и имеет ли смысл собрать такой браузер самому? В идеале подмена всех отпечатков и эмуляция винды на Linux. Новсе-таки более реально что это будет браузер под Windows

Гуглил самые разные браузеры, ничего толкого не нашел.

Есть известные решения вроде:

Antidetect 7.1- им пользуются всякие личности, сам не тестил, но в описании к браузеру нашел что он подменяет только часть отпечаток и не может являться эталоном.

Vektor T13 Browser-якобы "опен-сорс" и бесплатный. Тестил на виртуалке. Боюсь что там закладка, не доверия, иначе почему на протяжении 3-4 месяцев нету кода в паблике если это опен сорс.

Искал другие решения, но ничего путевого не нашел.

Есть якобы еще Linken Sphere Browser, которые меняет все отпечатки, но не пользовался им от слова совсем. Цена у него заоблачная. Есть ли те кто пользовался данным браузером?

Так все таки, какой он этот лучший анонимный браузер с уникальными отпечатками?

Valkiria

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

Возможно, ты желаешь изменить цифровой отпечаток своего браузера ?
В таком случае из твоего поста не понятно, что тебя не устраивает в Antidetect 7.1 или Vektor T13 Browser ?
Твой пост напоминает просьбу: объясните мне то, сам не знаю что.
Поставь конкретный вопрос !
В сети существуют сайты, на которых каждый пользователь имеет возможность протестировать отпечаток своего браузера.
Под цифровым отпечатком подразумевается совокупность следующих показателей: IP адрес, юзер-агент, язык браузера, язык системы, версия системы и так далее..
Ты что хочешь изменить ?

KravchukXoxlometatelb

Я не веду никакого двойного образа жизни, взломом не занимаюсь, это не мое. Я арбитражник. Мне казалось я написал более менее понятно насчет того что возникла необходимость найти браузер для работы в разных окнах разными личностями. Это означает что нужно для каждого окна нужно подменить более 20 отпечатков минимум. Думаю их смысла перечислять нету. Кто в теме, тот поймет. Браузер не устраивают тем что первый Antidetect закрывает только частично отпечакти, а не на 100%. Браузер вектора возможно с закладкой. Что я хочу изменить из отпечатков? Все?

Изменние как вы написали юзер-агента, языков, ничего не даст кроме базовой анонимности. Это не имеет ничего общего с подменой

Большинство из нас многократно слышали про способность сайтов узнавать информацию о посетителе (и всевозможные предупреждения по этому поводу), которую невозможно узнать из IP-адреса. Это такие «личные» данные, как операционная система, используемый браузер, язык системы. Кто же так жестоко палит нас? И как можно это использовать в своих благих намерениях? Об этом и многом другом ты узнаешь, прочитав статью до конца.

Представим ситуацию: некий Иван зашел на сайт, посмотрел на него и решил взломать. Загрузил проверенные соксы, поставил красивый дефейс и через несколько часов/дней сидел в участке. Ведь несложно сопоставить данные взломщика с данными остальных посетителей и найти настоящий IP (очень редко встретишь сайт без логирования). Да, некоторые факторы не учтены, однако, вариант возможный.

Техническая реализация

Я пользуюсь Mozilla Firefox и предпочитаю вместо внешних программ использовать плагины. Tamper Data позволяет перехватывать запросы и редактировать заголовки в реальном времени – незаменимая вещь при ручной проверке. Все просто: в окне плагина жмем «Запустить перехват» и вмешиваемся, когда необходимо. Имеются пресеты и богатые возможности по изменению значений заголовков.

Для постоянной же подмены заголовков лучше использовать плагин Modify Headers. Сразу после установки необходимо открыть настройки и поставить галку на «Always on», дабы подмена происходила всегда. Настройка элементарная – открыть главное окно плагина и добавить правил. Первое поле – выбор действия («Add» – добавить, «Modify» – изменить, «Filter» – исключить из запроса), второе – название заголовка, третье – значение; в четвертом поле можно оставить записку. Правила можно двигать, включать и выключать.

Вектор поиска

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

PHP-include не подходят, ибо файлы никогда не подключают в зависимости от заголовков. Хотя и есть возможные исключения, к примеру, инклуд файла в зависимости от языка. На практике не встречал.

SQL-инъекции подходят. Это самый простой тип, достаточно, как и обычно, подставлять кавычку.

PHP-исполнение кода очень редко встречается вообще, а с участием заголовков – еще реже. Однако бывает. Тут преимущество нашего метода в том, что GET и POST данным менее доверяют.

Итак, теперь необходимо составить строку, которая позволяла бы определить наличие уязвимости. Кавычка обязательна. Далее необходимо выйти из возможных тегов: простейший способ сделать это символами ">. И последнее – алерт, дабы не проспать. В итоге у меня вышло '"><script>alert(document.cookie)</script>. Ставить на обнаружение исполнения кода я не стал; если желаешь, добавь, например, <?'?> чтобы вызвать ошибку и заметить уязвимость. Также можно добавить в конец обратный слеш (пытаясь экранировать закрывающую кавычку), бывают случаи с фильтрацией кавычек, бывают без нее. Считаешь, что строка слишком длинная и может обрезаться? Замени “document.cookie” на «1». Тут главное – приложить фантазию и создать свой идеальной вектор поиска уязвимостей.

Интересные заголовки

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

User-Agent

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

Браузер/Версия (Платформа; Шифрование; Система, Язык[; Что-нибудь еще]) [Дополнения].

В качестве платформы чаще всего можно увидеть X11 или Windows, иногда туда прямиком помещают систему, убирая соответствующий заголовок после. «Шифрование» может принимать три значения: “N” (None) – отсутствует, “I” (International) – слабое шифрование ключом до 40 бит, “U” (USA) – сильное шифрование с ключом 128 бит. Сейчас все браузеры используют только сильное шифрование. После скобки добавляется различная информация вроде движка, плагинов, дополнений.

В качестве браузера для совместимости очень часто указывают Mozilla, а уже после информации дописывают реальное название. Это связано с тем, что издавна девелоперы должны были (или просто любили) делать сайты не в соответствии с принятыми стандартами Консорциума Всемирной паутины (World Wide Web Consortium, W3C), а под наиболее распространенные в данное время браузеры, что приводило к еще большему доминированию последних. И сейчас такая практика существует, однако с тем отличием, что популярным браузерам даны дополнительные возможности, связанные с использованием JavaScript’а (например, на распространенном форуме Invision Power Board, в ветке 2.3.x, посмотрите профиль участника с отфильтрованным заголовком и без). Поэтому советую в строку User-Agent’а в любом случае включать определение распространенного браузера.

Referer

X-Forwarded-For

Нестандартный заголовок, используемый неанонимными прокси-серверами для передачи реального IP клиента. Мы не можем вставить кавычку в определяемый сервером IP, зато можем заставить его думать, что это – всего лишь прокси, а настоящий IP – вот он, в X-Forwarded-For. Конечно, далеко не все скрипты используют и полагаются на XFF, но этот заголовок принято хотя бы логировать. Нельзя забывать проверять веб-приложение на наивность (да-да, некоторые сайты, увидев этот заголовок, забывают про обычный IP и пользуются только тем, что передано в данном заголовке). Формат: X-Forwarded-For: client_ip, proxy1_ip, . proxyN_ip.

Accept-Language

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

Accept-Charset

Сообщает допустимые кодировки и их приоритет. Не самый интересный заголовок, но стоит обратить на него внимание, ибо он может выдать твою систему простым «windows-1251».

X-Requested-With

Authorization

Если серверу необходима авторизация пользователя, он об этом прямо сообщает, а браузер предлагает ввести логин и пароль. Именно в заголовке Authorization они передаются в виде «Basic base64(user:pass)». Такую авторизацию намного удобней брутить, чем те, которые располагаются непосредственно на странице (POST).

Cookie

Собственно, в этом заголовке посылаются (внезапно) куки. Для танкистов поясню: это информация, которую сайт сохраняет на компьютере клиента. Подмена данного заголовка полезна тогда, когда изменение кукисов невозможно другим образом.

Применение

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

С первыми тремя, думаю, понятно. Если в ладах с английским, включи на постоянную подмену Accept-Language, дабы принимали за англичанина. Authorization уместно включать только при проверке конкретного сайта, ибо рискуете не понять, если где-нибудь действительно понадобится авторизация. Про применение заголовков X-Requested-With и Cookie я уже писал, однако поясню последний. В PHP довольно удобно хранить данные в сессиях: собственно данные – на сервере, у клиента – только идентификатор в куке «PHPSESSID» (название можно менять, но делают это, естественно, редко). Так вот, иногда этот идентификатор может состоять только из символов a-z, A-Z, 0-9 и '-,', и при передаче чего-то иного вызывается ошибка, раскрывающая абсолютный путь:

Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /var/www/data/www/login.php on line 2

Первое, на что я наткнулся – это поплывшая разметка. Да, действительно на многих сайтах происходил выход из какого-нибудь тега (бесполезный), и дальше образовывалась каша. Если ты решишь провести собственно исследование – будь готов. Еще одно: если чувствуешь, что что-то идет не так (например, не дают скачать файл, не показывают картинку во всю ширину, не работает перенаправление), выключай подмену Referer’а.

Никто не знает и не узнает, сколько алертов выловили админы, сколько они их увидели у себя в логах, сколько осталось незамеченными. Однако один случай обнаружения интересной активной XSS есть точно – гугловский сервис FeedBurner, который умеет обрабатывать RSS-фиды и логировать трафик сайта. Но последнее делал он не слишком качественно – не фильтровался Referer. Подробнее об этой уязвимости читай на raz0r.name/vulnerabilities/aktivnaya-xss-na-feedburner/ (wp.me/pft5J-4a) (не удивляйся, увидев алерт из-за XFF :)).

MySQL Error = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"')' at line 1

SQL = INSERT INTO oops_sessions (ID,UID,START,LAST,IPS,PAGES,PAGE,DATA,REFFER) VALUES ('dpdu7rh90ehfsc62','0',1238958331,1238958331,'xxx.xxx.xxx.xxx',1,'/','a:1:','SQL-Inj'here')

Подмена заголовков в PHP

Естественно, после ручного анализа SQL-уязвимости наступает работа автоматики. Подбор столбцов, полей, вынимание логинов, паролей и хешей – все уже давно делают скрипты. Однако большинство из них направлено на GET, POST или Cookie. Покажу, как можно получить страницу, посылая нужные заголовки. Предположим, у нас есть массив с такими заголовками и вызов функции request, которая должна возвращать страницу:

Есть несколько основных видов получения страницы из PHP (полные версии функций ищи на диске ][):

Сокет

Заголовки напишешь в любом случае. Генерация пакета:

$packet = "GET HTTP/1.1rn"
. "Host: rn"
. implode("rn", $headers) . "rn"
. "Connection: Closernrn";
- file_get_contents()

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

$opts = array (
'http' => array (
'header' => implode("rn", $headers) . "rn"
)
);
$context = stream_context_create($opts);
return file_get_contents($url, false, $context);

Заключение

Хотелось бы обратить внимание, что подмена заголовков – не панацея от сливания информации. Не стоит забывать о JavaScript’е, Flash’е и интерактивных элементах, которые тоже вправе много чего разболтать. Используй NoScript и прочие AdBlock’и. Всегда экспериментируй и прикладывай выдумку, ищи там, где не ищет никто. Удачи!

Впрочем, возможно перспектива обрисованная мной, слишком пессимистична и текущие коды будут работать еще 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 — Полная невидимость работы для пользователя (все работает быстро, хотя и зависит от хттп парсера), все сертифкаты остаются такими, какими они должны быть.

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