Понимание HTTP [Complete web app pentesting series #1]
Введение
Веб-сайты и API повсюду вокруг нас: от ежедневных денежных транзакций до стриминговых сервисов, развлечений, СМИ и музыки. Тестирование веб-приложений поэтому становится одним из самых ценных навыков, и поскольку прошло уже довольно много времени, давайте начнём. Наш первый блог в серии будет связан с HTTP.
Базовое введение в HTTP и URL
Если у вас были уроки информатики в средней или старшей школе, то вы знаете, что каждый учитель информатики хотя бы раз учил вас, что http означает hyper text transfer protocol, а https — то же самое, но s в https означает secure. И они могли даже напомнить вам о схеме URL, которая начинается с https:// перед доменом сайта. Понимание http действительно важно, потому что сайты, которые мы видим и используем ежедневно, общаются через протокол http. Поэтому, чтобы тамперировать или манипулировать сайтами, мы должны понимать http хотя бы на поверхностном уровне.
HTTP претерпел значительные трансформации с момента своего основания:
- HTTP/0.9: Первая версия HTTP, выпущенная в 1991 году: Очень простая, единственный разрешённый API — GET без каких-либо заголовков или кодов ответа. Вот пример типичного запроса.
GET /something.txt
- HTTP/1.0: Введены коды статуса, заголовки и разрешены более сложные взаимодействия, эта версия вышла в 1996 году; простой запрос в этой версии может выглядеть так:
something:webpage.php GET /something/webpage.php HTTP/1.0 Host: www.example.com
- HTTP/1.1: Эта версия была опубликована в 1999 году, с новыми вещами, такими как постоянные соединения, чанкед-трансфер энкодинг и более чистое управление заголовками. Пример запроса может выглядеть так:
POST /submit HTTP/1.1 Host: www.example.com User-Agent: MyBrowser/1.0 Content-Type: www-form-urlencoded application/x Content-Length: 27 name=John&age=30
- HTTP/2 и HTTP/3: Современные итерации с фокусом на производительность и безопасность.
- HTTP/2 использует:
1. Мультиплексирование (Мультиплексирование позволяет вашему браузеру отправлять несколько запросов одновременно по одному соединению и получать ответы в любом порядке)
2. Бинарный фрейминг (Это слой, который делает возможными все другие функции и оптимизации производительности в HTTP/2 и dictates, как HTTP-сообщения упаковываются и транспортируются по проводу от клиента к серверу и наоборот)
В то время как HTTP/3 использует QUIC (построенный на UDP) для снижения задержки и улучшения устойчивости.
Узнайте больше о протоколе QUIC здесь и здесь
На сегодняшний день HTTP/2 и HTTP/3 являются рекомендуемыми стандартами благодаря их повышенной скорости и эффективности.
Ссылки: RFC 9113 (HTTP/2) и RFC 9114 (HTTP/3).
Введение в URL
Пентестинг и эксплуатация мисконфигураций выполняются путём понимания URL. URL состоит из следующих частей:
protocol://username:password@host:port/path?query#fragment
- Protocol: HTTP, HTTPS, FTP, SMB и т.д.
- Host: Домен или IP (например, example.com).
- Port: По умолчанию 80 для HTTP и 443 для HTTPS, но может варьироваться.
- Path: Местоположение ресурса (например, /index.html).
- Query: Пары ключ-значение (например, ?id=1&name=test).
- Fragment: Раздел в ресурсе (например, #section1).
Эксплуатация схем URL в CTF
Если это ваш первый раз, когда вы слышите слово CTF, то не беспокойтесь, CTF или Capture the Flag — это конкурс по кибербезопасности, где вам дают задачи, требующие критического, аналитического мышления и применения различных концепций кибербезопасности для решения задачи, и как только вы правильно решите задачу, вы получите значение под названием flag, которое даст вам очки. Лучшие места для начала с CTF — tryhackme и hackthebox, не стесняйтесь проверить эти сайты.
Определённые протоколы, такие как FTP (протокол передачи файлов, используется для обмена файлами) или SMB (Server Message Block, используется для совместного использования ресурсов удалённо), встроенные в URL, могут быть злоупотреблены для получения файлов или получения несанкционированного доступа:
ftp://username:password@ftp.example.com/file.txt
Hackthebox имеет крутую машину под названием forge, в которой мы должны получить файлы из FTP используя HTTP URL. Это может быть достигнуто путём создания URL вроде этого.
http://admin.forge.htb/upload?u=ftp://user:heightofsecurity123!@127.0.0.1/
smb://username:password@share.example.com/resource
Такие манипуляции бесценны в вызовах CTF, часто приводя к обнаружению флага.
HTTP-запросы и ответы
HTTP работает через модель Request-Response. Обратите внимание, что HTTP — это протокол запрос-ответ, построенный на TCP/IP. Типичная сессия включает запрос клиента и ответ сервера, который выглядит примерно так:
GET /index.html HTTP/1.1 Host: www.example.com User-Agent: curl/7.85.0 Accept: text/html
HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1256 <html>...</html>
Обратите внимание, что вы можете просматривать эти запросы и ответы через:
- Перехватывающие прокси, такие как burp suite или zap или caido
- Используя инструменты вроде curl
- Dev tools браузера
Ключевые особенности в современных HTTP запросе и ответе:
- Headers: Метаданные вроде Content-Type, Authorization и Accept-Encoding.
- Persistent Connections: Держит TCP-соединения открытыми для нескольких запросов (включено по умолчанию в HTTP/1.1).
- Chunked Transfers: Позволяет потоковую передачу больших ответов в меньших, управляемых чанках.
HTTP-методы
HTTP-методы — это как команды, которые вы даёте серверу, чтобы сказать ему, что вы хотите сделать. Представьте, что сервер — как библиотекарь, а эти методы — запросы, которые вы делаете:
- Читает информацию о сервере. (Не делает ничего на сервере.)
- Пример: Получение данных пользователя или открытие веб-страницы.
- Создаёт или обрабатывает данные на сервере. (Здесь вы отправляете данные на сервер для обработки.)
- Пример: Что-то, что требует логина, например, форма логина или новый пользователь.
- (используется осторожно, потому что удаляет данные.) Удаляет ресурс.
- Пример: Удаление аккаунта пользователя.
- Получает только заголовки без скачивания данных. Полезно для валидации чего-то без скачивания данных.
- Пример: Как проверить, изменилась ли веб-страница, посмотрев на метаданные.
- Перечисляет возможности сервера.
- Пример: Используется для проверки, поддерживает ли сервер CORS (Cross-Origin Resource Sharing).
Коды статусов HTTP
Промежуточный ответ, он указывает, что клиент должен продолжить запрос или игнорировать этот ответ, если запрос уже завершен.
Этот код отправляется в ответ на заголовок запроса Upgrade от клиента и указывает протокол, на который переключается сервер.
Сервер получил и обрабатывает запрос, но ответа пока нет.
Этот код в первую очередь предназначен для использования с заголовком Link, позволяя пользовательскому агенту начать предварительную загрузку ресурсов или осуществить предварительное соединение к источнику ресурсов, пока сервер готовит ответ.
Запрос успешно выполнен. Значение результата «успех» зависит от метода HTTP:
- GET: Ресурс был получен и передан в теле сообщения.
- HEAD: Ответ содержит заголовки, но тела сообщения нет.
- PUT или POST: Ресурс, описывающий результат действия, передан в теле сообщения.
- TRACE: Тело сообщения содержит сообщение запроса, полученное сервером.
Запрос выполнен успешно, и в результате был создан новый ресурс. Обычно это ответ, отправляемый на запросы POST или PUT.
Запрос получен, но еще не обработан. Это «уклончивый» ответ, поскольку в HTTP нет возможности позже отправить асинхронный ответ с результатом обработки запроса. Этот код предназначен для случаев, когда запрос обрабатывается другим процессом или сервером, а также для пакетной обработки.
203 Non-Authoritative Information
Возвращенные метаданные не полностью совпадают с теми, которые доступны на исходном сервере, а получены из другого источника. Чаще всего это используется для зеркал или резервных копий ресурсов. За исключением таких случаев предпочтительнее использовать ответ 200 OK.
Для этого запроса нет содержимого для отправки, но заголовки ответа могут быть полезны. Пользовательский агент может использовать их для обновления закешированных заголовков, полученных ранее для этого ресурса.
Сообщает пользовательскому агенту, что необходимо сбросить отображение документа, который отправил этот запрос.
Этот код ответа используется, когда от клиента отправляется заголовок Range для запроса только части ресурса.
Передаёт информацию о нескольких ресурсах в случаях, когда могут быть уместны несколько кодов состояния.
Используется внутри элемента ответа <dav:propstat>, чтобы избежать повторного перечисления «привязок» и дублирования данных.
226 IM Used (HTTP Delta encoding)
Используется для ответа на запросы GET в тех случаях, когда сервер хочет отправить только изменённую часть ресурса (то есть «дельту»).
У запроса более одного возможного ответа. Пользовательский агент или пользователь должен выбрать один из них. Не существует стандартизированного способа выбора одного из ответов, но рекомендуется использовать HTML-ссылки на возможные варианты, чтобы у пользователя была возможность выбора.
URL-адрес запрошенного ресурса был изменен навсегда. Новый URL-адрес указан в ответе.
URI запрошенного ресурса был временно изменен. В будущем могут быть внесены дальнейшие изменения в URI. Следовательно, этот же URI должен использоваться клиентом в будущих запросах.
Клиенту необходимо получить запрошенный ресурс по другому URI с помощью запроса GET.
Этот код используется для целей кэширования. Он сообщает клиенту, что ответ не был изменен, поэтому клиент может продолжать использовать кэшированную версию ответа.
Запрошенный ответ должен быть доступен через прокси. Этот код определен в предыдущей версии спецификации HTTP и в настоящее время устарел из-за проблем безопасности, связанных с внутренней настройкой прокси-сервера.
Этот код ответа зарезервирован. Использовался в предыдущей версии спецификации HTTP/1.1.
Клиенту необходимо получить запрошенный ресурс по другому URI тем же методом, который использовался в предыдущем запросе. Он имеет ту же семантику, что и код ответа 302 Found, за исключением того, что пользовательский агент не должен изменять используемый метод: если в первом запросе использовался POST, то POST должен использоваться и во втором запросе.
Ресурс теперь находится по другому URI, указанному в заголовке ответа Location. Он имеет ту же семантику, что и код ответа 301 Moved Permanently, за исключением того, что пользовательский агент не должен изменять используемый метод: если в первом запросе использовался POST, то POST должен использоваться и во втором запросе.
Сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, неправильный синтаксис, формат или маршрутизация запроса).
Хотя стандарт HTTP определяет этот ответ как «неавторизованный», семантически он означает «неаутентифицированный». Это значит, что клиент должен аутентифицировать себя, чтобы получить запрошенный ответ.
Этот код ответа зарезервирован для использования в будущем. Первоначальной целью создания этого кода было использование его для цифровых платежных систем, однако он используется очень редко и стандартного соглашения не существует.
Клиент не имеет прав доступа к контенту, то есть он неавторизован, поэтому сервер отказывается предоставить запрошенный ресурс. В отличие от 401 Unauthorized, личность клиента известна серверу.
Сервер не может найти запрошенный ресурс. В браузере это означает, что URL-адрес не распознан. В API это также может означать, что адрес правильный, но ресурс не существует. Сервер также может отправить этот код ответа вместо 403 Forbidden, чтобы скрыть существование ресурса от неавторизованного клиента. Это самый известный код ответа из-за его частого появления в сети.
Метод запроса известен серверу, но не поддерживается целевым ресурсом. Например, API может не разрешать вызов DELETE для удаления ресурса.
Сервер после выполнения согласования контента не нашёл содержимого, соответствующего критериям, заданным пользовательским агентом.
407 Proxy Authentication Required
Этот код ответа похож на 401 Unauthorized, но аутентификация должна выполняться через прокси-сервер.
Сервер может отправить этот код ответа при неиспользовании соединения, даже без предварительного запроса со стороны клиента. Он означает, что сервер хотел бы закрыть это соединение. Этот ответ используется сравнительно часто, поскольку некоторые браузеры (такие как Chrome, Firefox 27+ или IE9) для ускорения используют механизмы предварительного подключения HTTP. Некоторые серверы просто закрывают соединение, не отправляя это сообщение.
Запрос конфликтует с текущим состоянием сервера.
Запрошенное содержимое было удалено с сервера, и отсутствует возможность переадресации. Ожидается, что клиенты удалят свои кеши и ссылки на этот ресурс. Спецификация HTTP предполагает, что этот код ответа будет использоваться для «ограниченных по времени или рекламных услуг». API не обязаны указывать ресурсы, которые были удалены, с помощью этого кода.
Запрос отклонён, потому что сервер требует указание поля заголовка Content-Length, но оно не определено.
Клиент указал в заголовках запроса условия, которым сервер не соответствует.
Размер объекта запроса превышает ограничения, определенные сервером. Сервер может закрыть соединение или вернуть поле заголовка Retry-After.
Запрошенный клиентом URI слишком длинный для того, чтобы сервер смог его обработать.
Запрос отклонён, потому что медиа формат запрашиваемых данных не поддерживается сервером.
Сервер не может корректно обработать запрос с учётом диапазона, указанного в поле заголовка Range.
Сервер не может выполнить ожидание, указанное в поле заголовка запроса Expect.
«Шуточный» ответ: сервер отклоняет попытку заварить кофе в чайнике.
Сервер не может дать ответ. Возможно сервер не настроен для комбинации схемы и полномочий, указанных в URI запроса.
422 Unprocessable Content (WebDAV)
Запрос сформирован правильно, но его невозможно выполнить из-за семантических ошибок.
Запрашиваемый ресурс заблокирован.
424 Failed Dependency (WebDAV)
Запрос не выполнен из-за проблем в предыдущем запросе.
425 Too Early Экспериментальная возможность
Клиент отправил порцию данных слишком рано, до того как сервер установил безопасное соединение.
Сервер отказывается выполнять запрос с использованием текущего протокола, но может быть готов сделать это после смены протокола на указанный в заголовке ответа Upgrade.
Сервер требует, чтобы запрос содержал условия. Этот ответ предназначен для предотвращения проблемы одновременного изменения ресурса несколькими пользователями.
Пользователь отправил слишком много запросов в определённый промежуток времени.
431 Request Header Fields Too Large
Сервер не будет обрабатывать запрос, потому что поля заголовка слишком велики. Запрос может быть отправлен повторно после уменьшения размера полей заголовка.
451 Unavailable For Legal Reasons
Пользовательский агент запросил ресурс, который не может быть предоставлен по закону, например веб-страницу, подвергнутую цензуре со стороны правительства.
На сервере произошла ошибка, в результате которой он не может успешно обработать запрос.
Метод запроса не поддерживается сервером и поэтому он не может быть обработан. Методы GET и HEAD должны всегда поддерживаться сервером и для них не должен возвращаться этот код.
Такой ответ может прислать сервер, который выступает в качестве шлюза, если в процессе обработки запроса он получил недопустимый ответ от целевого сервера.
Сервер не готов обработать запрос в данный момент. Распространёнными причинами являются техническое обслуживание или перегрузка сервера. Вместе с таким ответом следует отправлять удобную для пользователя страницу с объяснением проблемы, а также HTTP-заголовок Retry-After с расчётным временем решения проблемы. Кроме того, полезно отправлять заголовки с информацией о кешировании, поскольку эти временные ответы обычно не следует кэшировать.
Такой ответ может прислать сервер, который выступает в качестве шлюза, если в процессе обработки запроса он не может вовремя получить ответ от целевого сервера.
505 HTTP Version Not Supported
Используемая в запросе версия HTTP не поддерживается сервером.
На сервере произошла внутренняя ошибка конфигурации: выбранный в процессе согласования вариант ресурса не является подходящим.
507 Insufficient Storage (WebDAV)
Запрос не выполнен, потому что серверу не удалось сохранить данные.
Запрос не выполнен, потому что на сервере был обнаружен бесконечный цикл обработки данных.
Для выполнения запроса необходимо его расширить.
511 Network Authentication Required
Клиенту необходимо пройти аутентификацию для получения доступа к сети.
Управляйте своим Вебом: Освоение cURL и wget
HTTP — основа веба, и инструменты вроде curl и wget дают вам прямую власть общаться с серверами. Эти трюки помогут вам двигаться быстрее и с меньшими заботами, независимо от того, тестируете ли вы API, скачиваете файлы или зеркалируете сайты.
Использование curl
curl (Client URL) — это инструмент командной строки для отправки HTTP-запросов. Протоколы, которые он поддерживает, включают HTTP, HTTPS, FTP и другие, что делает его идеальным для отладки и тестирования.
Получить веб-страницу или ресурс:
curl https://example.com
Эта команда извлекает HTML-содержимое указанного URL и показывает его в терминале. Это отлично для проверки, возможно ли достичь ресурса.
Получить только заголовки HTTP-ответа с опцией -I (верхний регистр «i»):
curl -I https://example.com
Заголовки — это метаданные, такие как тип содержимого, информация о сервере и коды статуса, и помогают понять, как сервер отвечает на запрос.
HTTP/2 200 Content-Type: text/html; charset=UTF-8
Симулировать отправку форм, отправляя данные с помощью опции -d с POST-запросом:
curl -X POST -d "username=admin&password=1234" https://example.com/login
Обработать HTTP Basic Authentication с помощью флага -u:
curl -u admin:password https://example.com/secure
Это полезно для получения защищённых ресурсов, таких как админ-панели или API, требующие учётных данных. По умолчанию имя пользователя и пароль кодируются в Base64 и отправляются в заголовок Authorization.
Используйте флаг -L для следования перенаправлениям:
curl -L https://example.com
curl следует перенаправлению, производимому с кодом статуса 3xx, и извлекает конечный ресурс.
Отладка с помощью режима verbose:
Добавьте опцию -v для детальной отладки:
curl -v https://example.com
Режим verbose даёт детали о полном процессе общения, включая заголовки запроса, заголовки ответа и остальное.
Сохранить файл в вашу систему, комбинируя -O (вывод в файл) или -o (пользовательское имя файла):
curl -O https://example.com/file.zip
- -O: Просто сохраняет файл с оригинальным именем.
- -o custom_name.zip: Сохраняет файл с пользовательским именем.
Использование wget
Это неинтерактивный инструмент, предназначенный для скачивания файлов или целых директорий. Он хорош в сценариях, где необходимы последовательные или рекурсивные скачивания.
wget https://example.com/file.zip
- wget просто скачивает файл и помещает его в вашу рабочую директорию с оригинальным именем.
- Рекурсивные скачивания
Зеркалировать весь сайт или директорию:
wget --recursive --no-parent https://example.com/docs/
- --recursive: Скачивает файлы в указанной директории.
- --no-parent: Запрещает скачивание файлов из любой директории, кроме указанной.
Использование: Лучше всего для архивирования веб-страниц или сбора всех файлов в директории.
Используйте --spider с флагом -S для проверки существования URL без скачивания содержимого:
wget --spider -S https://example.com
Это полезно для верификации существования ресурса или тестирования URL в bulk. Флаг -S обеспечивает правильную обработку HTTP-заголовков, что необходимо для правильной работы команды.
wget --mirror https://example.com
Хотя wget не так гибок, как curl для тестирования API, вы всё равно можете отправлять пользовательские заголовки с помощью --header:
wget --header="Authorization: Bearer token" https://example.com/api
Ключевые различия между cURL и wget
- Одна из особенностей cURL — это передача данных и тестирование HTTP API.
- Wget предназначен в основном для скачивания файлов.
- cURL не позволяет рекурсивные скачивания.
- Wget имеет рекурсивные скачивания (т.е. скачивание целых директорий).
- Но снова, эти скачивания требуют опций или скриптинга для возобновления (например, -C -).
- Однако, флаг -c — одно из преимуществ wget, встроенная поддержка возобновления скачиваний.
- cURL поддерживает большое количество протоколов, таких как HTTP, HTTPS, FTP, SCP, SFTP, SMTP, LDAP…
- wget поддерживает HTTP, HTTPS, FTP.
- cURL очень кастомизируем для работы с HTTP-запросами, заголовками и передачей данных.
- wget сам по себе поддерживает только базовые конфигурации скачивания.
- Для использования cURL нужно хотя бы некоторое знакомство с концепциями HTTP и передачи данных.
- Когда дело доходит до простого скачивания файла, wget проще и легче в использовании.
- Лучше всего подходит для тестирования API с cURL, поскольку он может делать запросы с пользовательскими заголовками, куки и данными.
- wget не предназначен для тестирования API.
- Если вы знаете точно, какие заголовки или payloads вы хотите скачать, cURL отличен для таких одноразовых скачиваний.
- wget отличен для быстрого, прямолинейного скачивания файлов.
- cURL для тонкого контроля рабочих процессов передачи данных.
- Если вам нужно простое, автоматизированное bulk-скачивание, wget — лучший выбор.
Когда использовать каждый инструмент?
- Создатель или тестер, создающий или тестирующий API.
- Отладка HTTP-заголовков, куки или рабочих процессов аутентификации.
- Веб-задачи, такие как отправка форм или взаимодействия с API.
- Исследователь или sysadmin, архивирующий веб-данные.
- Например, скачивание целых директорий или сайтов рекурсивно.
- Продолжение прерванных скачиваний.
Что такое API и как их тестировать с помощью curl и wget?
Application Programming Interfaces (API) позволяют двум программным приложениям общаться друг с другом. Они предоставляют набор правил о том, как взаимодействовать с сервисом, будь то отправка данных, получение ответа или запуск действия. Restful API — распространённый пример, как те, кто использует HTTP-методы, такие как GET, POST, PUT и DELETE, управляют ресурсами.
Оригинальная статья | Перевод: THREAD