Почему HTTP — первый протокол, который нужно понимать
HTTP — протокол прикладного уровня, по которому браузер общается с сервером. Он stateless: сервер не хранит данные между запросами. Состояние добавляется через cookies и сессионные механизмы. Для пентестера это означает, что каждый запрос и каждый ответ — самостоятельный артефакт, который можно перехватить, модифицировать и проанализировать.
Без понимания структуры HTTP-сообщения невозможно корректно интерпретировать результаты сканирования, находить логические уязвимости или проверять настройки безопасности. Ниже — разбор каждого слоя протокола с акцентом на то, что важно при тестировании на проникновение.
Структура HTTP-сообщения
Каждое сообщение состоит из стартовой строки, заголовков и опционального тела.
Запрос:
Код:
GET /admin/dashboard HTTP/1.1
Host: target.example.com
Cookie: session_id=abc123
Accept: text/htmlОтвет:
Код:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session_id=abc123; Path=/; HttpOnly
<html>...</html>Пентестеру важно уметь читать обе стороны: запрос показывает, что клиент отправляет (и что можно подменить), ответ — что сервер раскрывает и какие ограничения устанавливает.
Методы запросов и их значение для безопасности
| Метод | Назначение | Что проверять |
|---|---|---|
| GET | Получение ресурса | Параметры в URL видны в логах, истории браузера, Referer |
| POST | Отправка данных в теле | Данные не в URL, но всё равно передаются открытым текстом без TLS |
| PUT | Создание/замена ресурса | Может быть разрешён там, где не должен |
| DELETE | Удаление ресурса | Проверка авторизации на деструктивные операции |
| OPTIONS | Запрос поддерживаемых методов | Раскрывает список методов, включая потенциально опасные |
| PATCH | Частичное изменение | Аналогично PUT — проверка контроля доступа |
| HEAD | Как GET, но без тела | Полезен для проверки существования ресурса без загрузки |
| TRACE | Эхо-запрос | Часто отключён из-за риска XST (Cross-Site Tracing). Если включён — может раскрывать внутренние заголовки, добавленные прокси, и использоваться для обхода HttpOnly |
Практический приём: отправьте
OPTIONS на интересующий endpoint. Если сервер возвращает Allow: GET, POST, PUT, DELETE, это сигнал проверить, действительно ли все эти методы требуют авторизации.TRACE заслуживает отдельного внимания: при включённом TRACE сервер возвращает тело запроса без изменений, включая заголовки, которые добавили промежуточные прокси. Это позволяет атакующему прочитать cookie с флагом
HttpOnly через XSS-вектор (атака XST). Именно поэтому большинство серверов отключают TRACE по умолчанию, и его наличие — индикатор слабой конфигурации.Коды ответа: что искать пентестеру
Коды сгруппированы в пять классов по первой цифре.
2xx — успех
- 200 OK — стандартный успешный ответ.
- 201 Created — ресурс создан. Если возвращается после POST без проверки прав — возможная проблема авторизации.
- 204 No Content — операция выполнена, тело пустое. Часто встречается при DELETE.
3xx — перенаправления
- 301 / 302 — постоянное и временное перенаправление. Проверяйте, куда ведёт
Location: открытый редирект — это вектор для фишинга и обхода SSRF-фильтров.
- 307 / 308 — перенаправление с сохранением метода. Важно при тестировании: POST не превращается в GET.
4xx — ошибки клиента
- 401 Unauthorized — требуется аутентификация. Проверяйте, можно ли обойти через другой метод или заголовок.
- 403 Forbidden — аутентификация есть, но прав недостаточно. Разница между 401 и 403 помогает картировать модель авторизации.
- 404 Not Found — ресурс не существует. Но если на один путь возвращается 404, а на другой 403 — это раскрывает структуру приложения.
- 405 Method Not Allowed — метод не поддерживается. Полезно для перечисления допустимых операций.
5xx — ошибки сервера
- 500 Internal Server Error — необработанное исключение. Часто содержит стектрейс или информацию о фреймворке.
- 503 Service Unavailable — сервер перегружен или на обслуживании. Может указывать на rate limiting.
Заголовки, которые раскрывают информацию
Заголовки запроса
| Заголовок | Зачем нужен пентестеру |
|---|---|
Host | Определяет виртуальный хост. Подмена может открыть скрытые сайты на том же IP |
User-Agent | Некоторые WAF и приложения фильтруют по нему |
Referer | Может использоваться для проверки источника запроса |
X-Forwarded-For | Передаёт оригинальный IP клиента через прокси. Подмена может обойти IP-based rate limiting |
Authorization | Несёт учётные данные (Basic, Bearer). Проверяйте формат и стойкость |
Content-Type | Определяет формат тела. Смена может обойти валидацию |
Заголовки ответа
| Заголовок | Что искать |
|---|---|
Server | Раскрывает тип и версию веб-сервера |
X-Powered-By | Указывает на фреймворк (PHP, ASP.NET, Express) |
Set-Cookie | Устанавливает cookies — анализируйте атрибуты |
Content-Security-Policy | Ограничивает источники загрузки ресурсов. Отсутствие или слабая политика — риск XSS |
X-Frame-Options | Защита от clickjacking. Значения: DENY, SAMEORIGIN |
Strict-Transport-Security | Принуждает браузер использовать HTTPS. Отсутствие — риск downgrade-атаки |
Access-Control-Allow-Origin | Настройка CORS. Значение * или отражение произвольного Origin — потенциальная утечка данных |
Cookies: структура и атрибуты безопасности
HTTP-куки — небольшой фрагмент данных, который сервер отправляет браузеру через заголовок
Set-Cookie. Браузер сохраняет его и возвращает с каждым последующим запросом к тому же серверу в заголовке Cookie. Именно cookies добавляют состояние к stateless-протоколу.Синтаксис Set-Cookie
Код:
Set-Cookie: <имя>=<значение>; Expires=<дата>; Max-Age=<секунды>; Domain=<домен>; Path=<путь>; Secure; HttpOnly; SameSite=StrictАтрибуты и их влияние на безопасность
Expires / Max-Age — определяют время жизни. Если ни один не задан, cookie является сессионным и удаляется при закрытии браузера. Однако многие браузеры восстанавливают сессию, поэтому сессионные cookies могут жить дольше ожидаемого. Если заданы оба атрибута,
Max-Age имеет приоритет.Domain — указывает, каким хостам отправляется cookie. По умолчанию — текущий хост без поддоменов. Если задан явно (например,
Domain=example.com), cookie отправляется и на все поддомены. Это важно: уязвимый поддомен может установить cookie для родительского домена, что открывает путь к атаке фиксации сессии.Path — ограничивает URL-пути, для которых cookie отправляется.
Path=/ означает отправку со всеми запросами. Path=/docs/ ограничивает отправку запросами к директории docs и её поддиректориям.Secure — cookie отправляется только по HTTPS. Не обеспечивает шифрования самого значения. Начиная с Chrome 52 и Firefox 52, сайты на
http: не могут устанавливать cookies с этим флагом.HttpOnly — запрещает доступ к cookie из JavaScript через
document.cookie. Критически важен для защиты от кражи сессионных токенов через XSS.SameSite — управляет отправкой cookie при межсайтовых запросах:
Strict— cookie отправляется только при запросах с того же сайта.
Lax— cookie не отправляется при межсайтовых подзапросах (изображения, фреймы), но отправляется при навигации по ссылке.
None— cookie отправляется всегда, но требует одновременного наличияSecure.
Если
SameSite не указан, современные браузеры применяют Lax по умолчанию.Префиксы cookie-имён
Два префикса обеспечивают дополнительные гарантии:
__Secure-— cookie должна быть установлена с флагомSecureи с HTTPS-страницы.
__Host-— требуетSecure,Path=/и запрещает атрибутDomain. Это самая строгая защита: cookie привязана к конкретному хосту и не может быть перехвачена поддоменом.
Код:
Set-Cookie: __Host-session=token123; Secure; Path=/Браузер отклонит установку, если любое условие нарушено. Бэкенд обязан обращаться по полному имени cookie, включая префикс — пользовательские агенты не удаляют префикс перед отправкой.
Сессии: как они работают и что проверять
Типичный механизм сессии:
- Пользователь отправляет учётные данные (POST на
/login).
- Сервер создаёт сессию, генерирует идентификатор и возвращает его через
Set-Cookie.
- Браузер отправляет cookie с каждым запросом.
- Сервер по идентификатору находит сессию в хранилище (память, база, Redis).
Чек-лист проверки сессионного механизма
- Энтропия идентификатора. Сессионный токен должен быть криптографически случайным. Последовательные числа или предсказуемые паттерны — критическая уязвимость.
- Атрибуты cookie. Проверьте наличие
HttpOnly,Secure,SameSite. ОтсутствиеHttpOnlyна сессионной cookie — прямой путь к краже через XSS.
- Регенерация при логине. После успешной аутентификации идентификатор сессии должен меняться. Если старый token продолжает работать — возможна фиксация сессии.
- Инвалидация при выходе. После logout сервер должен уничтожить сессию. Если cookie удаляется только на клиенте, а серверная сессия живёт — токен можно переиспользовать.
- Таймаут неактивности. Сессия должна истекать после периода бездействия.
- Поведение при параллельных сессиях. Можно ли войти с двух устройств одновременно? Это не всегда уязвимость, но должно быть осознанным решением.
Перехват и модификация трафика
Для анализа HTTP-трафика пентестер использует прокси-сервер, который sits между браузером и целевым приложением. Burp Suite и OWASP ZAP — основные инструменты.
Типовой workflow в учебной лаборатории:
- Настроить браузер на прокси (обычно
127.0.0.1:8080).
- Установить CA-сертификат прокси для перехвата HTTPS.
- Перехватить запрос, изучить заголовки и параметры.
- Модифицировать и отправить повторно (Repeater в Burp Suite).
- Сравнить ответы: изменился ли код, появились ли ошибки, раскрылась ли информация.
Bash:
## Альтернатива для быстрой проверки без GUI — curl
## Отправка запроса с кастомным заголовком на локальную лабораторию
curl -v -H "X-Forwarded-For: 127.0.0.1" http://localhost:8080/adminФлаг
-v выводит полные заголовки запроса и ответа — удобно для быстрого анализа без запуска прокси.Типичные ошибки при анализе HTTP
- Игнорирование кодов 3xx. Перенаправление может скрывать реальный endpoint или уводить от уязвимого пути.
- Проверка только GET. Уязвимость может проявляться только при PUT или DELETE, которые не видны в обычном браузере.
- Доверие клиентской валидации. Если поле
disabledв HTML или проверка на JavaScript — это не защита. Серверная валидация обязательна.
- Непроверка CORS. Если сервер возвращает
Access-Control-Allow-Origin: *одновременно сAccess-Control-Allow-Credentials: true, браузер блокирует доступ к ответу согласно спецификации CORS. Однако само наличие такого сочетания указывает на некорректную серверную конфигурацию: сервер не проверяет Origin и, вероятно, отражает произвольные значения. В сочетании с конкретным Origin (а не*) иcredentials: trueэто уже эксплуатируемая утечка данных.
- Пропуск заголовков безопасности. Отсутствие
Content-Security-Policy,X-Content-Type-Options: nosniff,Strict-Transport-Security— это не уязвимость сама по себе, но индикатор слабого security posture.
Итоговый чек-лист для анализа HTTP-приложения
- Перехватите трафик через прокси, изучите структуру запросов и ответов.
- Отправьте
OPTIONSна ключевые endpoint'ы — перечислите доступные методы.
- Проверьте коды ответа на несанкционированный доступ (401 vs 403 vs 200).
- Проанализируйте
Set-Cookie: наличиеHttpOnly,Secure,SameSite, предсказуемость значений.
- Проверьте регенерацию сессионного токена при логине и инвалидацию при logout.
- Изучите заголовки безопасности ответа: CSP, HSTS, X-Frame-Options, CORS.
- Попробуйте подменить
Host,X-Forwarded-For,Content-Type— оцените реакцию сервера.
- Зафиксируйте все находки с полными запросами и ответами для отчёта.
Все проверки проводите только в рамках согласованного scope: собственная лаборатория, CTF-платформа или авторизованный пентест. DNS для начинающего пентестера: записи, резолвинг и безопасная диагностика в учебной сети поможет разобраться с DNS-диагностикой, если нужно определить инфраструктуру цели до начала HTTP-анализа.
