Навіщо це знати
Майже кожна веб-вразливість (SQLi, XSS, SSRF, IDOR…) експлуатується через HTTP- запити. Без розуміння протоколу ти не читатимеш Burp і не будуватимеш пейлоади.
Анатомія запиту
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=abc123
username=admin&password=secret
- Метод + шлях + версія → перший рядок.
- Заголовки → метадані (Host, Cookie, Content-Type, Authorization…).
- Порожній рядок → потім тіло (для POST/PUT).
Відповідь
HTTP/1.1 200 OK
Set-Cookie: session=xyz; HttpOnly
Content-Type: text/html
<html>...</html>
Методи
| Метод | Призначення | Що тестувати |
|---|---|---|
| GET | отримати ресурс | параметри в URL (SQLi, IDOR) |
| POST | створити/надіслати | тіло, форми |
| PUT/DELETE | змінити/видалити | чи є контроль доступу? |
| OPTIONS | які методи дозволені | CORS, приховані методи |
Ключові заголовки (для атак і захисту)
- Cookie / Set-Cookie — сесії; прапори
HttpOnly,Secure,SameSite. - Authorization —
Bearer <JWT>, Basic auth. - Host — вразливий до Host Header Injection.
- X-Forwarded-For — підробка IP; довіряти йому небезпечно.
- Referer / Origin — перевірки CSRF/CORS.
- Безпекові:
Content-Security-Policy,X-Frame-Options,Strict-Transport-Security.
Коди статусів (що вони кажуть тестеру)
- 2xx — успіх.
200OK,201Created. - 3xx — редірект.
301/302— куди веде? (open redirect?). - 4xx — помилка клієнта.
401(не автентифікований) vs403(немає прав) — різниця важлива для IDOR.404— не знайдено (fuzzing). - 5xx — помилка сервера.
500часто = вразливість (стектрейс, SQL-помилка).
Практичний прийом
Зміни один параметр і дивись, як міняється код і довжина відповіді — так знаходять SQLi (помилка), IDOR (200 замість 403), fuzzing (404 vs 200).
Інструмент: Burp Suite (Repeater/Intruder). Практика: веб-завдання в Labs.