Полный гайд по cURL для пентестеров

Home Полный гайд по cURL для пентестеров
curl pentes

Полный гайд по cURL для пентестеров

(Этичный, без опасных payload’ов — только методология и безопасные команды.)

cURL — один из самых мощных инструментов пентестера. Он позволяет:

  • вручную отправлять HTTP/HTTPS-запросы,
  • анализировать ответы,
  • воспроизводить уязвимые сценарии,
  • тестировать конфигурации серверов,
  • проверять безопасность API,
  • работать с cookies, токенами, заголовками, редиректами, CORS, кэшем и т.д.

Ниже — ключевые аспекты, которые используют пентестеры.

🔎 1.1 Проверка заголовков безопасности

curl -I https://target.com

Что ищем:

  • Strict-Transport-Security — отсутствует? Возможен downgrade атаки.
  • X-Frame-Options — отсутствует? Возможен clickjacking.
  • Content-Security-Policy — отсутствует? Выше риск XSS.
  • X-XSS-Protection — не всегда критично, но полезно.

🔁 1.2 Анализ редиректов

curl -I -L http://target.com

Можно раскопать:

  • переход HTTP → HTTPS,
  • старые поддомены,
  • утечки внутренних URL,
  • плохие конфигурации CDN.

🍪 1.3 Работа с Cookies и сессиями

Сохранение cookies:

curl -c cookies.txt https://target.com

Отправка cookies:

curl -b cookies.txt https://target.com/profile

Используется для:

  • тестирования авторизации,
  • проверки сессионных механизмов,
  • анализа безопасности JWT/сессий.

🔑 1.4 Тестирование авторизации и ролей

Проверка, правильно ли работает RBAC:

curl -H "Authorization: Bearer INVALID_TOKEN" https://target.com/api/admin

Если ответ — 200 OK, проблема.

🛠 1.5 Чтение raw-трафика с debug-режимом

curl -v https://target.com

Вы увидите:

  • DNS lookup
  • SSL handshake
  • request headers
  • response headers
  • redirects
  • TLS negotiation

🔥 1.6 Проверка CORS

curl -I https://target.com -H "Origin: https://evil.com"

Если сервер отвечает:

Access-Control-Allow-Origin: *

— это ошибка.

🗂 1.7 Поиск открытых файлов и директорий

curl -I https://target.com/.git/ curl -I https://target.com/backup.zip

Если статус 200 — утечка данных.

🧩 1.8 Тестирование API параметров

curl "https://target.com/api/user?id=123"

Можно проверить:

  • некорректную обработку параметров
  • IDOR (несанкционированный доступ)
  • ошибки валидации

📡 2. Список полезных команд для API-тестирования

✔ GET-запрос

curl https://api.example.com/users

✔ POST с JSON

curl -X POST https://api.example.com/login \ -H "Content-Type: application/json" \ -d '{"user":"admin","pass":"123"}'

✔ PUT

curl -X PUT https://api.example.com/user/100 \ -H "Content-Type: application/json" \ -d '{"email":"new@mail.com"}'

✔ DELETE

curl -X DELETE https://api.example.com/user/5

✔ Добавление токена

curl https://api.example.com/me \ -H "Authorization: Bearer YOUR_TOKEN"

✔ Отправка custom-заголовка

curl https://api.example.com \ -H "X-Debug: 1"

✔ Отправка формы

curl -F "file=@image.png" https://api.example.com/upload

✔ Сохранение ответа в файл

curl -o result.json https://api.example.com/data

🧪 3. Практикум: «Как читать HTTP руками»

Чтобы реально научиться тестировать API и веб-приложения, важно понимать структуру HTTP.

📘 Пример сырого HTTP-запроса

GET /login HTTP/1.1 Host: example.com User-Agent: curl/7.88 Accept: */*

📗 Пример сырых HTTP-ответов

Ответ 200 OK:

HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1234 <html>...</html>

Ответ 302 Redirect:

HTTP/1.1 302 Found Location: https://example.com/auth

Ответ 401 Unauthorized:

HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer realm="example"

Ответ 500 Server Error:

HTTP/1.1 500 Internal Server Error

🧾 4. Примеры логов и их разбор

🔍 Пример 1 — неправильный токен доступа

curl -H "Authorization: Bearer WRONG" https://api.example.com/admin

Лог API:

401 Unauthorized Error: invalid_token

Вывод: проверка токенов работает.

🔍 Пример 2 — попытка доступа к чужому объекту (IDOR)

curl https://api.example.com/user/10 curl https://api.example.com/user/11

Если второй запрос возвращает чужие данные:

✔ найден критический баг
❗ этичный хакер сообщает его владельцу

🔍 Пример 3 — опасный CORS

curl -I https://target.com -H "Origin: https://evil.com"

Ответ:

Access-Control-Allow-Origin: *

Вывод: сайт уязвим — браузер позволит украсть данные через стороннюю страницу.

🔍 Пример 4 — раскрытие внутренних систем в редиректах

curl -I -L http://target.com

Ответ:

Location: http://internal.target.local

Вывод: произошла утечка внутренней инфраструктуры.

🛡️ Шпаргалка пентестера по HTTP-кодам

(этот список создан специально для пентеста, баг-баунти и анализа безопасности)

1xx — Информационные

Используются редко, но могут раскрывать лишние детали о сервере.

100 Continue

Сервер готов принять тело запроса.

101 Switching Protocols

Переход на WebSocket — важно при pentest WebSocket API.

102 Processing

Используется в WebDAV — старые системы часто уязвимы.

2xx — Успех

Коды, показывающие, что запрос прошёл нормально. Особенно полезны для выявления неправильного контроля доступа.

200 OK

Главный сигнал IDOR / Broken Access Control.
Если вы видите данные, которые вам не принадлежат — это баг.

201 Created

Успешное создание ресурса.
В пентесте — проверка регистрации, загрузки файлов, API.

202 Accepted

Запрос принят, но выполняется асинхронно. Может скрывать ошибки.

204 No Content

Ответ без тела.
Используется при массовом удалении данных, обновлениях API.

3xx — Редиректы

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

301 Moved Permanently

Пентестер ищет:

  • старые URL,
  • возможные уязвимости в редиректах,
  • утечки внутренних путей.

302 Found

Часто используется при логине.
Если можно обойти 302, возможно, обход аутентификации.

303 See Other

Может использоваться для принудительного выхода.

307 Temporary Redirect

Сохраняет метод запроса (POST остаётся POST).
Можно использовать при fuzzing POST-эндпоинтов.

4xx — Ошибки клиента

Золотая жила для анализа безопасности и поведения API.

400 Bad Request

Полезно для:

  • теста валидации,
  • поиска injection-поведения,
  • анализа обработки спецсимволов.

401 Unauthorized

Сервер требует авторизацию.
Если endpoint возвращает 200, хотя должен 401 — ошибка.

403 Forbidden

Если endpoint возвращает 403:

  • тестировать изменение токена,
  • проверять bypass методов (POST вместо GET),
  • проверять заголовки X-Original-URL, X-Rewrite-URL.

404 Not Found

Может скрывать полезные файлы:

  • /backup.zip
  • /.git/
  • /admin/

Если у вас разный ответ 404 для реального файла и выдуманного, значит, сервер “утекает” информацию.

405 Method Not Allowed

Проверяем:

  • позволяет ли сервер HEAD / PUT / DELETE?
  • используются ли нестандартные методы?

409 Conflict

Может вылезать при гонках (race conditions).

413 Payload Too Large

Проверка защиты от больших файлов (DoS).

429 Too Many Requests

Срабатывает при brute force.
Если нет — это сигнал для разработки багрепорта.

5xx — Ошибки сервера

Самые важные для пентестера: показывают, где приложение ломается.

500 Internal Server Error

Признак:

  • плохой обработки исключений,
  • SQL/NoSQL ошибок,
  • серверных зависимостей.

Если 500 появляется при изменении параметра — это потенциальная уязвимость.

501 Not Implemented

Редкость. Может указать на старые серверы.

502 Bad Gateway

Часто:

  • backend упал,
  • проблемы с API.

Можно использовать для анализа архитектуры.

503 Service Unavailable

Удобно для rate-limit тестов.

504 Gateway Timeout

Позволяет оценить:

  • тяжелые запросы,
  • медленные БД,
  • незащищённые внутренние исполнения скриптов.

🔥 Как пентестер использует статусы в практике

✔ Broken Access Control

Если endpoint должен быть закрыт, но отвечает 200, это критический баг.

✔ IDOR / Insecure Direct Object Reference

Если соседний объект даёт 200 — уязвимость.

✔ User Enumeration

Разные статусы для валидного/невалидного пользователя → сигнал.

✔ Ошибки 500

Любая 500 на API — это минимум “избыточная информация”, максимум — SQL-инъекция.

✔ Проверка ограничений

Нет 429 → слабый rate-limiting.

✔ Directory Enumeration

Разный 404/403/301 → путь существует, но скрыт.