The book of Magnus

IT-заметки и знания

Основы пентеста. Структура HTTP

Tags = [ Pentest_base, HTTP ]

Pentest (penetration testing) или тестирование на проникновение – метод оценки безопасности компьютерных систем, сетей или приложений средствами моделирования атаки злоумышленника. Процесс включает в себя несколько этапов о которых мы поговорим позднее и направлен на выявление потенциальных уязвимостей, которые могут спровоцировать некорректную работу целевой системы, либо полный отказ в обслуживании.

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

Структура протокола HTTP

Протокол HTTP (HyperText Transfer Protocol) — это протокол прикладного уровня для передачи гипертекста в Интернете. Он работает по модели клиент-сервер, где клиент (например, браузер) отправляет запросы, а сервер возвращает ответы. Структура HTTP состоит из запросов и ответов с определённым форматом.

Структура HTTP-запроса

HTTP-запрос состоит из трёх основных частей:

  • Стартовая строка (Request Line) Содержит метод запроса, URI ресурса и версию протокола. Формат: Метод URI Версия_протокола Метод: Действие (например, GET, POST, PUT, DELETE, HEAD, OPTIONS). URI: Путь к ресурсу (например, /index.html). Версия протокола: Обычно HTTP/1.1 или HTTP/2.0. Пример:
GET /api/users HTTP/1.1
  • Заголовки (Headers) Содержат метаданные о запросе (информация о клиенте, формате данных, аутентификации и т.д.). Формат: Имя_заголовка: Значение. Примеры:
Host: example.com — домен сервера.
User-Agent: Mozilla/5.0 — информация о клиенте.
Content-Type: application/json — тип отправляемых данных.
Authorization: Bearer token — данные для аутентификации.

Заголовки разделяются строками с символами \r\n.

  • Тело запроса (Body, опционально) Содержит данные, отправляемые на сервер (например, при POST или PUT). Используется для передачи параметров формы, JSON, XML и т.д. Для методов вроде GET тело обычно отсутствует. Пример:
{ "name": "John", "age": 30 }

Структура HTTP-ответа

HTTP-ответ также состоит из трёх основных частей:

  • Строка статуса (Status Line) Содержит версию протокола, код состояния и текстовое описание. Формат: Версия_протокола Код_состояния Текстовое_описание Версия протокола: Например, HTTP/1.1. Код состояния: Числовой код результата (например, 200, 404, 500). Текстовое описание: Краткое пояснение кода (например, OK, Not Found). Пример:
HTTP/1.1 200 OK
  • Заголовки (Headers) Содержат метаданные об ответе (тип контента, длина, дата и т.д.). Формат: Имя_заголовка: Значение. Примеры:
Content-Type: text/html — тип возвращаемого контента.
Content-Length: 1024 — размер тела ответа в байтах.
Server: Apache/2.4.41 — информация о сервере.
Set-Cookie: session=abc123 — установка cookies.
  • Тело ответа (Body, опционально) Содержит данные, возвращаемые сервером (HTML, JSON, изображения и т.д.). Для некоторых ответов (например, 204 No Content) тело отсутствует. Пример:
<html> <body> <h1>Hello, World!</h1> </body> </html>

Основные особенности протокола

Состояние: HTTP — протокол без сохранения состояния (stateless). Каждый запрос независим, но состояние можно поддерживать через cookies, сессии или токены. Методы:

GET: Запрос данных.
POST: Отправка данных на сервер.
PUT: Обновление ресурса.
DELETE: Удаление ресурса.
HEAD: Запрос только заголовков.
OPTIONS: Запрос доступных методов.

Коды состояния:

1xx: Информационные (например, 100 Continue).
2xx: Успех (например, 200 OK).
3xx: Перенаправление (например, 301 Moved Permanently).
4xx: Ошибка клиента (например, 404 Not Found).
5xx: Ошибка сервера (например, 500 Internal Server Error).

Соединение:

HTTP/1.0: Соединение закрывается после каждого запроса.
HTTP/1.1: Поддержка постоянного соединения (Keep-Alive).
HTTP/2 и HTTP/3: Мультиплексирование и сжатие заголовков.

Пример HTTP-взаимодействия

Запрос:

GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: text/html

Ответ:

HTTP/1.1 200 OK Content-Type: text/html Content-Length: 138 Date: Mon, 02 Jun 2025 19:03:00 GMT
Welcome to Example.com!

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

  • HTTP/1.0: Простая модель запрос-ответ, одно соединение на запрос.
  • HTTP/1.1: Поддержка постоянных соединений, заголовков Host, методов PUT, DELETE.
  • HTTP/2: Мультиплексирование, сжатие заголовков, бинарный формат.
  • HTTP/3: Использует UDP (QUIC) вместо TCP для повышения скорости и надёжности.

Стартовая строка в протоколе HTTP

Стартовая строка (или строка запроса/статуса) — это первая строка в HTTP-запросе или HTTP-ответе. Она задаёт основную информацию о запросе или ответе и является обязательной частью сообщения в протоколе HTTP. Рассмотрим стартовые строки для запроса и ответа подробнее.

Стартовая строка HTTP-запроса (Request Line)

Формат: Метод URI Версия_протокола

  • Метод: Указывает тип действия, которое клиент хочет выполнить. Основные методы:
GET: Запросить данные.
POST: Отправить данные на сервер.
PUT: Обновить ресурс.
DELETE: Удалить ресурс.
HEAD: Запросить только заголовки.
OPTIONS: Узнать доступные методы.
  • URI (Uniform Resource Identifier): Указывает путь к ресурсу на сервере (например, /index.html, /api/users).
  • Версия протокола: Указывает используемую версию HTTP (например, HTTP/1.1, HTTP/2.0).
GET /api/users HTTP/1.1

Здесь:

  • GET — метод.
  • /api/users — URI ресурса.
  • HTTP/1.1 — версия протокола.

Особенности

Стартовая строка завершается символами возврата каретки и перевода строки (\r\n). URI может включать параметры запроса (query string), например: /search?q=example. В HTTP/1.1 поле Host в заголовках обязательно, так как URI указывает только путь, а не полный адрес сервера.

Стартовая строка HTTP-ответа (Status Line)

Формат: Версия_протокола Код_состояния Текстовое_описание

  • Версия протокола: Указывает версию HTTP, используемую сервером (например, HTTP/1.1).
  • Код состояния: Числовой код, описывающий результат обработки запроса. Основные категории:
1xx: Информационные (например, 100 Continue).
2xx: Успех (например, 200 OK).
3xx: Перенаправление (например, 301 Moved Permanently).
4xx: Ошибка клиента (например, 404 Not Found).
5xx: Ошибка сервера (например, 500 Internal Server Error).
  • Текстовое описание: Краткое пояснение кода состояния (например, OK, Not Found). Пример
HTTP/1.1 200 OK

Здесь:

HTTP/1.1 — версия протокола.
200 — код состояния.
OK — текстовое описание.

Особенности

Как и в запросе, строка завершается \r\n. Код состояния и текстовое описание разделены пробелом. Текстовое описание не стандартизировано строго, но обычно следует общепринятым формулировкам (например, OK для 200, Not Found для 404).

Пример HTTP-взаимодействия

Запрос
http
GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: text/html
Ответ
http
HTTP/1.1 200 OK Content-Type: text/html Content-Length: 138 Date: Wed, 04 Jun 2025 16:25:00 CEST
Welcome to Example.com!

Отличия в версиях протокола

  • HTTP/1.0: Простой формат стартовой строки, каждый запрос требует нового соединения.
  • HTTP/1.1: Добавлена поддержка постоянных соединений (Keep-Alive) и обязательный заголовок Host, что влияет на интерпретацию URI в стартовой строке.
  • HTTP/2: Стартовая строка не используется напрямую, так как протокол работает в бинарном формате, но концептуально сохраняется (данные передаются в виде фреймов).
  • HTTP/3: Основан на UDP (QUIC), но логика стартовой строки аналогична HTTP/2, с акцентом на оптимизацию скорости.

Важные замечания

Кодировка: Стартовая строка использует ASCII, что обеспечивает совместимость. Чувствительность к пробелам: Пробелы между элементами стартовой строки обязательны, лишние пробелы недопустимы. Ошибки в стартовой строке: Неправильный формат (например, неверный метод или версия) может привести к ошибке 400 Bad Request.

HTTP-методы

HTTP-методы (или глаголы) определяют тип действия, которое клиент (например, браузер или приложение) хочет выполнить на сервере в рамках протокола HTTP. Каждый метод имеет свою семантику и предназначение, описывая, как сервер должен обработать запрос. Методы стандартизированы в спецификациях HTTP (например, RFC 7231 для HTTP/1.1) и широко используются в веб-разработке, API и других сетевых взаимодействиях. Рассмотрим основные HTTP-методы, их свойства и примеры использования.

Основные HTTP-методы

GET Описание:

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

Характеристики:

Безопасный (не изменяет состояние сервера).
Идемпотентный (повторные вызовы дают тот же результат).
Тело запроса обычно отсутствует.

Параметры передаются через строку запроса (query string) в URI (например, /search?q=term). Пример использования:

Получение веб-страницы: GET /index.html HTTP/1.1.
Запрос данных из API: GET /api/users/123 HTTP/1.1.

Пример запроса:

GET /api/users HTTP/1.1 Host: example.com Accept: application/json

POST Описание:

Отправляет данные на сервер для создания или обновления ресурса. Часто используется для отправки форм или загрузки данных.

Характеристики:

Не безопасный (изменяет состояние сервера).
Не идемпотентный (повторные вызовы могут создавать новые ресурсы).
Тело запроса содержит данные (например, JSON, XML, данные формы).

Пример использования:

Отправка формы: регистрация пользователя.
Создание ресурса в API: POST /api/users HTTP/1.1.

Пример запроса:

POST /api/users HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 45 {"name": "John Doe", "email": "john@example.com"}

PUT Описание:

Обновляет существующий ресурс или создаёт новый, если он не существует, по указанному URI.

Характеристики:

Не безопасный (изменяет состояние сервера).
Идемпотентный (повторные вызовы не изменяют результат после первого обновления).
Тело запроса содержит полное или частичное представление ресурса.

Пример использования: Обновление профиля пользователя: PUT /api/users/123 HTTP/1.1. Пример запроса:

PUT /api/users/123 HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 45 {"name": "John Smith", "email": "john.smith@example.com"}

DELETE Описание:

Удаляет указанный ресурс на сервере.

Характеристики:

Не безопасный (изменяет состояние сервера).
Идемпотентный (повторные вызовы не изменяют результат после удаления).
Тело запроса обычно отсутствует.

Пример использования: Удаление ресурса: DELETE /api/users/123 HTTP/1.1. Пример запроса:

DELETE /api/users/123 HTTP/1.1 Host: example.com

HEAD Описание:

Аналогичен GET, но запрашивает только заголовки ответа, без тела.

Характеристики:

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

Пример использования: Проверка доступности ресурса или его метаданных: HEAD /index.html HTTP/1.1. Пример запроса:

HEAD /index.html HTTP/1.1 Host: example.com

OPTIONS Описание:

Запрашивает информацию о доступных методах и возможностях сервера для указанного ресурса.

Характеристики:

Безопасный и идемпотентный.
Используется в CORS (Cross-Origin Resource Sharing) для проверки разрешённых методов.

Пример использования: Проверка, какие методы поддерживает API: OPTIONS /api/users HTTP/1.1. Пример запроса:

OPTIONS /api/users HTTP/1.1 Host: example.com

PATCH Описание:

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

Характеристики:

Не безопасный.
Не обязательно идемпотентный (зависит от реализации).
Тело запроса содержит только изменения (например, JSON Patch).

Пример использования: Изменение одного поля ресурса: PATCH /api/users/123 HTTP/1.1. Пример запроса:

PATCH /api/users/123 HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 22 {"email": "new@example.com"}

TRACE Описание:

Выполняет диагностический запрос, возвращая серверу полученный запрос для проверки (редко используется).

Характеристики:

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

Пример использования: Проверка маршрута запроса: TRACE /index.html HTTP/1.1. Пример запроса:

TRACE /index.html HTTP/1.1 Host: example.com

CONNECT Описание:

Устанавливает туннель к серверу (обычно для прокси или HTTPS).

Характеристики:

Не безопасный и не идемпотентный.
Используется для создания соединения через прокси.

Пример использования: Установка туннеля для HTTPS: CONNECT example.com:443 HTTP/1.1. Пример запроса:

CONNECT example.com:443 HTTP/1.1 Host: example.com

Свойства методов

Безопасность: Метод считается безопасным, если он не изменяет состояние сервера (например, GET, HEAD, OPTIONS). Безопасные методы предназначены только для чтения.

Идемпотентность: Метод идемпотентный, если повторные вызовы с одинаковыми параметрами дают тот же результат (например, GET, PUT, DELETE). POST и PATCH обычно не идемпотентны.

Кэшируемость: Некоторые методы (например, GET, HEAD) могут кэшироваться, чтобы ускорить повторные запросы.

Использование в REST API

В RESTful API методы HTTP играют ключевую роль в реализации CRUD-операций (Create, Read, Update, Delete):

  • Create: POST (создание ресурса).
  • Read: GET (получение ресурса).
  • Update: PUT или PATCH (обновление ресурса).
  • Delete: DELETE (удаление ресурса). Пример REST API:
POST /api/users HTTP/1.1 # Создать пользователя GET /api/users/123 HTTP/1.1 # Получить пользователя PUT /api/users/123 HTTP/1.1 # Обновить пользователя DELETE /api/users/123 HTTP/1.1 # Удалить пользователя

Расширения и кастомные методы

HTTP позволяет определять кастомные методы, но они редко используются из-за проблем с совместимостью.

Пример: WebDAV добавляет методы, такие как PROPFIND, MKCOL, COPY, MOVE.

Особенности в разных версиях HTTP

  • HTTP/1.0: Поддерживает только GET, POST, HEAD.
  • HTTP/1.1: Добавлены PUT, DELETE, OPTIONS, TRACE, CONNECT, а также поддержка PATCH.
  • HTTP/2 и HTTP/3: Методы остаются такими же, но их обработка оптимизирована благодаря мультиплексированию и бинарному формату.

Пример взаимодействия с методами

Запрос (POST)

POST /api/users HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 45 {"name": "John Doe", "email": "john@example.com"}

Ответ

HTTP/1.1 201 Created Content-Type: application/json Content-Length: 55 Date: Wed, 04 Jun 2025 16:26:00 CEST {"id": 123, "name": "John Doe", "email": "john@example.com"}

Замечания

  • Выбор метода: Неправильное использование метода (например, использование GET для изменения данных) может нарушить семантику HTTP и привести к проблемам безопасности.
  • CORS: Для кросс-доменных запросов метод OPTIONS часто используется для проверки разрешённых методов.
  • Безопасность: Методы вроде DELETE и PUT требуют строгой авторизации, чтобы предотвратить несанкционированные действия.

HTTP-заголовки

HTTP-заголовки (Headers) — это метаданные, передаваемые в HTTP-запросах и ответах, которые предоставляют дополнительную информацию о запросе, ответе или передаваемом ресурсе. Они играют ключевую роль в управлении взаимодействием между клиентом и сервером, определяя такие аспекты, как формат данных, аутентификация, кэширование, управление соединением и т.д. Заголовки следуют за стартовой строкой в HTTP-сообщении и предшествуют телу (если оно есть).

Формат заголовков

Синтаксис: Имя_заголовка: Значение Имя заголовка нечувствительно к регистру. Значение может содержать пробелы, но не переносы строк. Заголовки разделяются символами \r\n. Пример:

Host: example.com Content-Type: application/json Accept: text/html
Пустая строка (\r\n) отделяет заголовки от тела сообщения (если тело присутствует).

Категории HTTP-заголовков

HTTP-заголовки делятся на несколько категорий в зависимости от их назначения: Общие заголовки (General Headers) Применяются как к запросам, так и к ответам, описывая общие аспекты сообщения. Примеры: Date: Дата и время создания сообщения.

Date: Wed, 04 Jun 2025 16:27:00 CEST
Connection: Управление соединением (например, Keep-Alive, close).

Connection: Keep-Alive
Cache-Control: Правила кэширования (например, no-cache, max-age=3600).

Cache-Control: public, max-age=3600

Заголовки запроса (Request Headers) Используются клиентом для передачи информации о запросе или клиенте. Примеры: Host: Доменное имя сервера (обязателен в HTTP/1.1).

Host: example.com
User-Agent: Информация о клиенте (браузер, устройство, ОС).

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/123.0.0.0
Accept: Форматы данных, которые клиент может принять.

Accept: text/html, application/json
Authorization: Данные для аутентификации (например, токен).

Authorization: Bearer abc123
Content-Type: Тип данных в теле запроса (для POST, PUT).

Content-Type: application/json
Content-Length: Размер тела запроса в байтах.

Content-Length: 45

Заголовки ответа (Response Headers) Используются сервером для передачи информации об ответе. Примеры: Server: Информация о сервере.

Server: Apache/2.4.41
Content-Type: Тип возвращаемого контента.

Content-Type: text/html; charset=UTF-8
Content-Length: Размер тела ответа в байтах.

Content-Length: 138
Set-Cookie: Установка cookies для клиента.

Set-Cookie: session=abc123; Path=/; HttpOnly
Location: URL для перенаправления (используется с кодами 3xx).

Location: https://example.com/new-page

Заголовки сущности (Entity Headers) Описывают тело сообщения (если оно есть), его формат и характеристики. Примеры: Content-Type: MIME-тип содержимого (например, application/json, image/png).

Content-Type: application/json
Content-Length: Длина тела в байтах.

Content-Length: 1024
Content-Encoding: Кодировка содержимого (например, gzip, br).

Content-Encoding: gzip
Last-Modified: Дата последнего изменения ресурса.

Last-Modified: Tue, 03 Jun 2025 12:00:00 GMT

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

  • Чувствительность к регистру: Имена заголовков нечувствительны к регистру (Content-Type = content-type), но значения могут быть чувствительны.
  • Множественные значения: Некоторые заголовки (например, Accept) поддерживают несколько значений, разделённых запятыми.
  • Кастомные заголовки: Разрешено использование нестандартных заголовков с префиксом X- (например, X-Custom-Header), но они не стандартизированы.
  • Разделение: Каждый заголовок занимает отдельную строку, завершающуюся \r\n.

Примеры использования заголовков

Запрос

POST /api/users HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Accept: application/json Content-Type: application/json Content-Length: 45 Authorization: Bearer abc123 {"name": "John Doe", "email": "john@example.com"}

Ответ

HTTP/1.1 201 Created Date: Wed, 04 Jun 2025 16:27:00 CEST Server: Apache/2.4.41 Content-Type: application/json Content-Length: 55 Set-Cookie: session=abc123; Path=/; HttpOnly {"id": 123, "name": "John Doe", "email": "john@example.com"}

Популярные заголовки и их назначение

  • Аутентификация:
Authorization: Передача учетных данных (Basic, Bearer, etc.).
WWW-Authenticate (в ответе): Указывает метод аутентификации.
  • Кэширование:
Cache-Control: Управление кэшированием (no-cache, max-age).
ETag: Уникальный идентификатор версии ресурса.
If-None-Match: Проверка изменения ресурса.
CORS (Cross-Origin Resource Sharing):
Access-Control-Allow-Origin: Указывает домены, которым разрешён доступ.
Access-Control-Allow-Methods: Разрешённые методы для CORS.
  • Управление соединением:
Connection: Keep-Alive или close.
Keep-Alive: Параметры постоянного соединения.
  • Сжатие:
Accept-Encoding: Какие методы сжатия поддерживает клиент (gzip, br).
Content-Encoding: Метод сжатия ответа.

Особенности в разных версиях HTTP

  • HTTP/1.0: Ограниченный набор заголовков, отсутствие обязательного Host.
  • HTTP/1.1: Заголовок Host обязателен для запросов, добавлены заголовки для кэширования и управления соединением.
  • HTTP/2: Заголовки сжимаются с помощью алгоритма HPACK, что уменьшает объём передаваемых данных.
  • HTTP/3: Использует те же заголовки, но передача оптимизирована через QUIC.

Замечания

  • Безопасность: Заголовки, такие как Authorization или Set-Cookie, требуют осторожного обращения, чтобы избежать утечек данных.
  • CORS: Заголовки вроде Access-Control-* критичны для кросс-доменных запросов.
  • Кастомные заголовки: Использование X- заголовков устаревает; вместо них рекомендуется использовать стандартные или регистрировать новые в IANA.
  • Ограничения: Слишком большое количество заголовков или их объём может привести к ошибке 431 Request Header Fields Too Large.