Автоматизация Instagram

Содержание

• 1. Авторизация

  • 1.1. Анализ

  • 1.2. Проблема

  • 1.3. Первая дыра в безопасности

  • 1.4. Решение проблемы и вторая дыра в безопасности

• 2. Сборка данных

  • 2.1. Данные без пагинации

  • 2.2. Данные с пагинацией

• 3. Итог

По работе попалась интересная задача по автоматизации Instagram, а именно надо было просто провести розыгрыш. Сервисов для организации этой затеи достаточно, есть даже бесплатные. Но были дополнительные (читай премиум) условия, к тому же мне очень захотелось самому посмотреть, что там внутри этой популярной инстаграмы и быть может набраться опыта в построении API.

Первым делом пошел смотреть что там говорят интернеты. Чтение официальных доков по API instagram дали четко понять, что владельцы не хотят давать доступ к неограниченной автоматизации, можно автоматизировать работу со своим аккаунтом в базовом варианте, но это не подходило под мою задачу, а «бизнес» вариант API требовал верификации компании, что естественно мне не подходит. (Может быть уже что-то изменилось …)

Тогда я пошел смотреть что говорят интернеты по поводу работы с тем API что есть на сайте Instagram. Все было радужно и ничего не предвещало проблем. На github были даже проекты на php, предоставляющие API для автоматизации вплоть до постинга. Статьи на Хабре гласили о легкости автоматизации. Многие из источников были нормальной свежести (пару месяцев, а то и недель). Однако …

Авторизация

Начинаем снифать (fiddler + waterfox) запросы на сайте instagram и смотреть что там. Понятное дело принимаем куки и устанавливаем их куда следует. Этот этап пропустим.

Анализ

Далее, надо авторизоваться.

При беглом осмотре стало понятно — за авторизацию отвечает POST запрос https://www.instagram.com/accounts/login/ajax/ с интересным набором параметров. Интерес вызывает именно enc_password — склеенная строка, логически разделяемая : и состоящая (судя по всему, на основании этих данных) из:

• описания входящего пароля (PWDINSTAGRAMBROWSER)

• версии шифрования (10)

• времени шифрования (unixtime 1591030811)

• шифрованной строки с паролем

Немного поигравшись не трудно догадаться что unixtime принимает участие в шифровании, так как шифрованная строка при каждом запросе разная.

Погуглив, можно найти варианты авторизации без шифрования пароля, однако эти методы на момент написания данного материала уже не работали. На просторах github можно найти вариант шифрования пароля на nodejs. Обнадежил этот вариант, но оказался не рабочим.

Проблема

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

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

Первая дыра в безопасности

Прежде чем окончательно забросить идею авторизации в instagram на php, я решил проверить как там обстоят дела с авторизацией на основании сгенерированных данных на js. Для этого взял эти данные из перехваченного трафика (можно из консоли где xhr запросы, но я взял из fiddler) и попробовал авторизоваться через php на локальном сервере. Наконец-то получил заветный позитивный ответ об успешной авторизации и токен.

Перекинул эти данные на хосинг … получилось авторизоваться. Запустил авторизация с этими данными через 7 дней — авторизация прошла, то есть эти критически важные данные никаким образом не привязаны ни к чему-либо (ни к геолокации, ни к ip), и перехватив их злоумышленник без труда получит доступ к аккаунту).

Решение проблемы и вторая дыра в безопасности

Тогда я вспомнил мое недавнее знакомство с nodejs и puppeteer и решил попробовать скинуть этап авторизации на указанные технологии. И получилось 🙂

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

Перехватив один раз заголовки после авторизации, последующую неделю удавалось их спокойно использовать (есесно совместно с куками):

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

Сборка данных

Данные без пагинации

Теперь настало время сборки необходимых данных. Первым делом нужно достать информацию о посте. Она находится в html ответе на запрос вида:

Данные с пагинацией

А теперь самое интересное 🙂

Нужно вытащить все комментарии, лайки, подписчиков. Опять идем и анализируем запросы. Instagram API использует graphql (что-то типа свой rust-full со своими приколами). Запрос выглядит следующим образом.

где:

• query_hash — это хэш запрашиваемых данных:

  • лайки — d5d763b1e2acf209d62d22d184488e57

  • комментарии — bc3296d1ce80a24b1b6e40b1e72903f5

  • подписчики — c76146de99bb02f6415203be841dd25a

  • отметки — ff260833edf142911047af6024eb634a

• variables — это json (urlencode естественно), данные внутри для каждого запроса могут немного отличаться, однако, в каждом запросе, который запрашивает массив данных и предполагает постраничную навигацию есть:

  • first — количество запрашиваемых данных (даже если запросить больше 50 вернется только 50)

  • after — предположительно это хэш записи от которой отсчитывается ffirst. fafter не нужен в первом запросе, и возвращается в каждом запросе, если есть еще данные для чтения (иначе null)

Например сборка лайков:

Итог

В итоге на организацию коленочного API ушло около 20 часов.

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

Instagram заставил попотеть и испытать различные эмоции от использования API, но поставленная цель была достигнута в полном объёме. Автор: Виталий Бутурлин