Если когда-нибудь вам в голову приходила мысль: "Что если бы на этом сайте был тот или иной функционал? Это было бы круто!" — эта статья как раз для вас. В ней вы узнаете, как сайты взаимодействуют с серверами, как получают данные и как можно разобраться в том, как работает определённый сайт.

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

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

Что такое API?

API (интерфейсы программирования приложений) позволяют двум компьютерным программам общаться друг с другом. Вы запрашиваете данные через API для использования в своём проекте, а API получает их для вас. Эти API могут быть локальными (например, Windows API, Web API и так далее) или удалёнными (например, API, которые разработчики предоставляют через интернет, такие как API погоды или API сайтов). В этой статье мы сосредоточимся на удалённых API, так как именно такой подход чаще всего используется на современных сайтах. Сайты используют API для отображения данных на основе ответа от сервера. Некоторые компании могут предоставить доступ к своим API, чтобы вы могли разрабатывать на их основе, но это не всегда так. Иногда API может не предоставить нужную вам функциональность или дизайн. Поэтому сначала стоит изучить, что сайт предлагает, и использовать это для создания нужных вам функций. В этом туториале вы научитесь понимать и исследовать API, стоящие за сайтом, чтобы использовать их в своих проектах.

Как работает API?

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

API‑запросы (реквесты) и ответы (респонсы) обычно имеют схожую структуру, которая выглядит так:

Запросы:

• Эндпоинты: целевой URL API.

• Методы: указывают серверу, что нужно делать с данными, например, получить данные, обновить их, удалить и так далее.

• Параметры: дополнительные детали, которые вы передаёте серверу для уточнения запроса, такие как тема, категория и так далее.

• Заголовки: это пары ключ‑значение, которые предоставляют информацию о клиенте, аутентификации и других аспектах.

• Тело запроса: это фактические данные, которые клиент хочет получить от сервера.

Ответы:

• Статус‑код: трёхзначный HTTP‑статус‑код, который сообщает клиенту результат работы сервера.

• Заголовки: аналогично заголовкам запроса, но с информацией о сервере. Это может быть установка cookies или другие детали.

• Тело ответа: содержит фактические данные, которые пришли от сервера.

Теперь, когда вы знаете немного о API и HTTP‑запросах, можно переходить к реверс‑инжинирингу сайта.

Что такое реверс-инжиниринг?

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

Что касается сайтов, то процесс реверс‑инжиниринга поможет вам понять, какие API использует сайт и как они работают. Это позволяет создавать собственные программы, используя API этого сайта. Иногда реверс‑инжиниринг используется для поиска багов, взлома программ или использования API без разрешения. Разработчики сайтов обычно предотвращают такие действия, предоставляя официальный API для их сайта, устанавливая лимиты на использование API и устраняя несанкционированный доступ. По этой причине, когда вы начинаете заниматься реверс‑инжинирингом программы, важно учитывать условия использования и юридическую сторону работы, чтобы не нарушить закон или этику.

Как сделать реверс-инжиниринг сайта

Чтобы сделать реверс‑инжиниринг сайта, вам нужно выполнить два шага: сначала исследовать сайт, чтобы понять, как он работает, и узнать, какие данные и эндпоинты он предоставляет. Во‑вторых, нужно сформулировать предположения о том, как это работает, и попробовать их подтвердить. Простое предположение может быть таким: после входа на сайт, он получает информацию для аутентификации через API‑запросы. Получив эту информацию, вы сможете использовать API сайта без необходимости входить каждый раз. Для того чтобы проверить это предположение, вам нужно будет исследовать запросы, которые сайт отправляет и получает. Затем вам нужно будет отправить эти запросы самостоятельно, например, с помощью терминала через CURL или HTTP‑клиент, такой как Postman.

Я создал демонстрационный сайт, который мы будем реверс‑инженерить. Вы запустите этот сайт на своём компьютере и затем выполните реверс‑инжиниринг. Сайт представляет собой простую страницу входа и содержит некоторые данные о клиентах. Ваша цель — получить данные о недавних продажах клиента. Вот несколько скриншотов сайта и того, что вас ждёт:

Исследуем сайт

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

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

Чекнем данные о продажах

Ваша цель — проверить продажи на сайте, поэтому вам нужно будет войти на сайт и перейти на страницу с данными о продажах. На странице продаж вам нужно будет сделать следующее:

Откройте инструменты разработчика Chrome (нажмите F12 или правой кнопкой мыши кликните по странице и выберите «Инспектор»), чтобы увидеть, какие API предоставляет сайт.

Затем, после открытия инструментов разработчика, вам нужно перейти на вкладку «Сеть» (Network), чтобы проверить сетевые запросы и увидеть, что сайт отправляет на сервер.

Вкладка «Сеть» (Network) показывает вам запросы, отправляемые с сайта на сервер, и то, как сервер на них отвечает.

Как видно на предыдущем изображении, у вас пустая сеть в инструментах разработчика. Это происходит, когда вы открываете инструменты разработчика после того, как сайт уже отправил запросы. Обновление страницы (нажатием F5) будет достаточно, чтобы увидеть эти запросы.

На следующем изображении вы можете увидеть запросы, отправляемые с сайта на сервер. Если проанализировать названия запросов, вы найдёте один из них под названием sales, который содержит данные о продажах. Вы можете открыть этот запрос и посмотреть, какой результат он возвращает.

Если вы кликнете на запрос, то увидите различные данные, такие как заголовки (headers), cookies, ответы (responses) и другие детали. Эти данные помогут вам понять, как сервер обрабатывает запрос и какие данные он отправляет в ответ.

Эти вкладки помогут вам понять результат запроса, его источник, а также сам запрос и ответ. Если вы перейдёте на вкладку «Ответ» (Response), то сможете увидеть данные о продажах в формате JSON, которые использует сайт.

Теперь, когда у вас есть этот запрос, вы можете использовать его в браузере для получения результата. Для этого нужно использовать функцию fetch из JavaScript. Это поможет вам увидеть результат функции и понять, как она работает.

Простой способ сделать это — кликнуть на запрос, затем перейти в меню «Copy» (Копировать) и выбрать «Copy as fetch» (Копировать как fetch). В этом случае «fetch it» означает копирование запроса для повторного использования как вызова fetch в JavaScript, включая все заголовки и тело запроса в скопированном тексте.

Вот этот код:

let fetchResult = fetch("http://localhost:3000/api/sales", {
"headers": {
"accept": "*/*",
"accept-language": "en,tr-TR;q=0.9,tr;q=0.8,en-US;q=0.7,ar;q=0.6,it;q=0.5",
"sec-ch-ua": "\"Chromium\";v=\"124\", \"Google Chrome\";v=\"124\", \"Not-A.Brand\";v=\"99\"",
"sec-ch-ua-mobile": "?0",
"sec-ch-ua-platform": "\"Windows\"",
"sec-fetch-dest": "empty",
"sec-fetch-mode": "cors",
"sec-fetch-site": "same-origin"
},
"referrer": "http://localhost:3000/dashboard",
"referrerPolicy": "strict-origin-when-cross-origin",
"body": null,
"method": "GET",
"mode": "cors",
"credentials": "include"
})

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

fetchResult.then(res => res.json()).then(console.log)

И вот результат:

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

Выполнение запроса через инструменты разработчика браузера предполагает, что вы выполняете его от имени сайта. Это добавит дополнительные заголовки к запросу API, такие как имя хоста текущего сайта в заголовках и текущие cookies, прикреплённые к запросу API.

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

Использование данных за пределами хоста сайта потребует указания другого имени хоста в заголовках и других cookies, связанных с запросом API. Для таких случаев вам нужно будет использовать Postman, программу для тестирования HTTP‑запросов, которая помогает вам тестировать, исследовать и читать данные запросов API.

Как использовать чужой API на вашем сайте

Поскольку вы получили API‑эндпоинт в предыдущем разделе, который выглядел так:

http://localhost:3000/api/sales

Вы могли бы ожидать, что этот URL позволит вам получить данные, которые вы использовали ранее, и что он сразу же будет работать в Postman, а также на вашем сайте. Но это не так, потому что запрос fetch не содержит данных об аутентификации.

Вы можете сами попробовать это в Postman, чтобы увидеть ошибку. Postman предоставляет два способа записать URL запроса: первый — это написать запрос вручную в интерфейсе Postman, а второй — импортировать API‑запрос, чтобы попробовать его (как видно на изображении ниже).

Чтобы импортировать запрос fetch в Postman, сначала нужно кликнуть на запрос во вкладке «Сеть» (Network) и скопировать его как:

1. cURL (Bash) — это позволит вам получить заголовки и все связанные данные с сайта, такие как cookies и так далее.

2. URL only — это будет просто URL без дополнительной информации.

Для начала скопируйте запрос как URL и вставьте его в Postman. Это позволит вам получить чистый API‑запрос без связанных заголовков и cookies. Затем нажмите на кнопку «Send» в Postman, чтобы отправить запрос и получить результат от API.

Когда вы нажмёте на кнопку «Send» в Postman, вы увидите сообщение об неавторизованном доступе в теле ответа и статус‑код 200. Сообщение о неавторизованном доступе появилось потому, что вы не вошли в сайт через Postman, а статус‑код 200 связан с дизайном API. Некоторые API могут возвращать статус‑код 401: Unauthorized, с которым вы можете столкнуться на других сайтах.

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

В этом примере мы используем приватный API, который требует авторизации. Здесь вы получаете данные, к которым вам разрешено получить доступ.

Как авторизоваться

На основе предыдущего раздела, когда вы пытались выполнить API‑запрос, вы получили сообщение о том, что доступ не авторизован. Запрос требует авторизации.

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

После того как вы войдете в систему, вы сможете использовать API‑запрос, чтобы получить нужные данные.

Чтобы попробовать, выполните следующие шаги:

1. Для того чтобы узнать, как сайт авторизовывает запросы, скопируйте запрос как bash и посмотрите, какие дополнительные cookies и параметры он получает.

2. Попробуйте войти в систему и посмотреть, какие данные со страницы входа и как передаются в запросе

Проверяем как работает логин

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

1. Перейдите на страницу входа.

2. Откройте инструменты разработчика.

3. Перейдите на вкладку «Сеть» (Network).

4. Активируйте опцию «Preserve log» (Сохранить журнал), чтобы сохранить логи, когда вы будете переходить по разным страницам или если сайт перенаправит вас.

5. Кликните на кнопку входа.

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

Вот ответ:

На предыдущем изображении вы видите, что получили сообщение с текстом «ok», что не даёт много информации. Сейчас вам нужно проверить заголовки и cookies, чтобы увидеть, что сервер отправил, и можно ли использовать заголовки сервера для авторизации.

Если вы проверите заголовки, то обнаружите заголовок ответа set‑cookie, который отвечает за установку cookies на вашем устройстве. В этом заголовке будет значение loggedin=true, что указывает на флаг авторизации, который сайт может использовать.

На вкладке cookies вы увидите то же самое значение.

Здесь вы можете предположить, что наличие cookies, отправленных вместе с заголовком запроса «sales», может авторизовать запрос. Чтобы дважды это проверить, откройте запрос sales в инструментах разработчика и посмотрите, какие дополнительные данные содержат заголовки запроса, включая заголовки и cookies.

И если вы вернетесь на вкладку cookies, вы заметите, что значения там опять те же самые.

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

1. Откройте вкладку Headers

2. Добавьте заголовок Cookie и вставьте значение из запроса в тулзах

3. Отправьте запрос

4. Проверьте результат

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

Проверка с помощью cURL (Bash)

Более простой и удобный способ сделать это — скопировать запрос как cURL (Bash), и импортировать его в Postman. Затем вам нужно будет проанализировать параметры и посмотреть, какие заголовки сервер отправил для авторизации.

Вы можете посмотреть следующее изображение, на котором URL вставлен как cURL (Bash):

На изображении видно, что вы добавили 12 дополнительных заголовков, и теперь вы можете их проверить и проанализировать. Иногда вы можете найти заголовок Authorization, в других случаях могут быть другие токен‑заголовки, которые нужно учитывать.

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

Заключение

Авторизация и безопасность — важные вопросы. Как вы заметили на сайте, для демонстрации авторизации вам пришлось использовать cookies, что подходит для некоторых сайтов.

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

Некоторые сайты используют стандарты OAuth для авторизации, сохраняя токен на сайте для отправки запросов. По мере того как вы будете исследовать больше сайтов через реверс‑инжиниринг, вы начнёте замечать различные паттерны и сможете лучше их понимать и применять на практике.

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

В реальных примерах всё гораздо сложнее, и вам нужно будет провести более глубокое исследование. Однако основные принципы остаются одинаковыми в любых ситуациях: один эндпоинт отвечает за данные авторизации/аутентификации, а другой — за связанные данные.

Реверс‑инжиниринг — это не простая задача, и она требует терпения, усердия и настойчивости. Как вы увидели, понимание того, как работает сайт, требует много времени. Не все сайты имеют чистые API‑запросы, и некоторые запросы могут быть перепутаны с другими файлами, необходимыми для работы сайта, такими как CSS‑скрипты или изображения. Всё, что вам нужно, — это быть терпеливым и думать нестандартно.

В рамках курса «Информационная безопасность. Basic» вы научитесь анализировать взаимодействие между клиентом и сервером, разбираться в механизмах авторизации и понимать принципы защиты данных. Приходите на открытые уроки, которые проведут преподаватели курса бесплатно в рамках набора:

• 29 октября. «Инфраструктура открытых ключей (PKI), удостоверяющие центры и сертификаты — что нужно знать начинающему специалисту». Записаться

• 6 ноября. «Основы DevSecOps». Записаться

• 19 ноября. «Нормативка по ИБ в 2025 году: как разобраться и не пропустить важное!». Записаться

Рост в IT быстрее с Подпиской — дает доступ к 3-м курсам в месяц по цене одного. Подробнее