Другие атаки на приложения

«Безопасность приложения — это не только про SQL-инъекции и XSS. Это про десятки менее очевидных векторов, которые эксплуатируют доверие системы, её внутреннюю логику и даже физические ограничения сервера. Защита от них требует понимания не только кода, но и того, как этот код выполняется в реальном времени.»

Современные приложения — это сложные системы, где уязвимость может скрываться не в явной ошибке, а в тонком взаимодействии компонентов, обработке данных или управлении ресурсами. Помимо широко известных угроз, существуют атаки, нацеленные на саму логику работы приложения, его окружение и интерфейсы взаимодействия.

Межсайтовая подделка запроса (CSRF)

CSRF (Cross-Site Request Forgery) — это атака, использующая доверие сайта к браузеру пользователя. Если пользователь аутентифицирован, его браузер автоматически отправляет куки сессии с каждым запросом к этому сайту. Злоумышленник может заставить браузер отправить вредоносный запрос от имени пользователя, не взламывая его пароль.

Механизм часто использует скрытые формы, автоматически отправляемые скрипты или даже теги изображений. Например, на вредоносной странице может быть размещён невидимый элемент:

<img src="https://bank.example/transfer?to=attacker&amount=10000" />

При загрузке страницы браузер попытается получить «изображение», отправив GET-запрос с куками пользователя на банковский домен, что может привести к несанкционированной операции.

Основные методы защиты:

Использование уникальных CSRF-токенов (Anti-CSRF tokens), проверяемых сервером для каждого состояния изменяющего операцию.
Применение атрибута SameSite для кук сессии, который ограничивает их отправку только в контексте исходного сайта.
Проверка заголовка Referer или Origin для подтверждения источника запроса.
Для критичных операций — требование повторного ввода пароля или использования одноразовых кодов.

Атака на условиях гонки (Race Condition)

Эта уязвимость, также известная как Time of Check/Time of Use (TOCTOU), возникает, когда результат операции зависит от последовательности или времени выполнения параллельных процессов. Если два потока обращаются к общему ресурсу (например, балансу счёта) без синхронизации, итоговое состояние может стать некорректным.

Классический пример — двойная трата. Пользователь с балансом в 100 единиц почти одновременно инициирует два перевода по 100 единиц. Оба потока проверяют баланс (100 >= 100), оба проходят проверку и выполняют списание, в результате чего со счёта уходит 200 единиц.

Методы защиты:

Использование механизмов блокировки (мьютексы, семафоры) для сериализации доступа к критическим секциям.
Применение атомарных операций на уровне базы данных (например, UPDATE accounts SET balance = balance - 100 WHERE id = 1 AND balance >= 100).
Использование транзакций с подходящим уровнем изоляции (например, Serializable).
Паттерн оптимистичной блокировки с проверкой версии записи.

Некорректная обработка входных данных

Это не отдельная атака, а фундаментальная уязвимость, лежащая в основе многих других. Если приложение безоговорочно доверяет данным от пользователя, API или даже другой внутренней системы, это открывает путь для манипуляций.

Последствия варьируются от нарушения логики работы до полного компрометирования системы:

Тип манипуляции	Возможный результат
Переполнение буфера	Выполнение произвольного кода, крах приложения.
Инъекция (SQL, NoSQL, командная)	Чтение, изменение, удаление данных; выполнение команд на сервере.
XSS (межсайтовый скриптинг)	Кража сессий, перенаправление на фишинговые сайты.
Обход логики	Несанкционированный доступ к функционалу, эскалация привилегий.

Ключевые принципы защиты:

Валидация: Проверка данных на соответствие строгим правилам (формат, тип, диапазон, длина). Предпочтение белым спискам разрешённых значений.
Санітизация (очистка): Экранирование или удаление опасных символов в контексте их использования (HTML, SQL, системные команды).
Параметризация: Использование подготовленных выражений (prepared statements) для запросов к БД, отделяющих данные от команд.
Контекстно-зависимые проверки на всех уровнях приложения, включая backend, даже если они есть на frontend.

Утечка информации через обработку ошибок

Подробные сообщения об ошибках — золотая жила для злоумышленника. Они не просто информируют пользователя о сбое, но и зачастую раскрывают внутреннее устройство системы.

Из стандартной ошибки базы данных можно извлечь:

— Тип и версию СУБД.

— Структуру таблиц и имена полей.

— Фрагменты SQL-запросов.

— Пути в файловой системе сервера.

Эта информация используется для подготовки целенаправленных атак, таких как сложные SQL-инъекции или подбор эксплойтов под конкретную версию ПО.

Что делать:

В production-среде заменять детализированные технические ошибки на общие пользовательские сообщения («Произошла внутренняя ошибка»).
Все детали ошибок должны записываться в защищённые логи, недоступные извне.
Настроить глобальные обработчики исключений, чтобы ни одно необработанное исключение не «утекло» клиенту.
Регулярно проверять логи на предмет попыток вызвать ошибки (fuzzing, сканирование уязвимостей).

Атаки на интерфейсы прикладного программирования (API)

Современные приложения — это сеть взаимодействующих API (REST, GraphQL, gRPC). Атаки на них часто обходят традиционные веб-интерфейсы.

Основные векторы:

Инъекции через параметры: Внедрение кода в параметры запросов GraphQL или тела JSON.
Сломанная аутентификация и авторизация: Подбор или перебор токенов (JWT), эксплуатация слабых механизмов OAuth, доступ к чужим данным из-за некорректных проверок прав (IDOR — Insecure Direct Object References).
Чрезмерное раскрытие данных: API по умолчанию возвращает больше полей, чем нужно клиенту, что может привести к утечке чувствительной информации.
Отсутствие ограничения скорости запросов (Rate Limiting): Позволяет проводить атаки на подбор учётных данных (brute force) или истощать ресурсы сервера.

Меры защиты:

Строгая аутентификация и авторизация для каждого endpoint. Проверка не только «кто», но и «имеет ли право на этот конкретный ресурс».
Валидация всех входящих данных по схеме (JSON Schema, GraphQL introspection control).
Обязательное использование HTTPS с корректно настроенными сертификатами.
Внедрение лимитов на количество запросов с гибкой настройкой для разных endpoint и пользователей.
Регулярный аудит схемы API и прав доступа.

Повторная атака (Replay Attack)

Replay-атака — это повторная отправка легитимного, ранее перехваченного сообщения. Атакующему не нужно его расшифровывать или понимать содержимое. Достаточно отправить его снова, чтобы действие выполнилось повторно (например, перевод денег).

Особенно уязвимы системы, где запросы идут по открытым каналам и не имеют признака «одноразовости».

Способы противодействия:

Использование одноразовых номеров (nonce) — уникальных значений для каждого запроса, которые сервер проверяет на повторение.
Включение временных меток (timestamp) в подписываемую часть запроса и отклонение запросов с устаревшей меткой.
Применение цифровых подписей для всего пакета данных, включая nonce и timestamp.
Для высокоуровневых протоколов — использование последовательных номеров сеанса.

Обход пути (Directory/Path Traversal)

Атака позволяет выйти за пределы корневой директории веб-приложения, манипулируя параметрами, которые указывают на файлы (например, ?file=report.pdf). Используя последовательности вроде ../ (или их кодированные варианты вроде %2e%2e%2f), можно получить доступ к системным файлам.

Пример уязвимого запроса: https://site.example/load?name=../../../etc/passwd

Защита строится на:

Нормализации пути: приведение его к каноническому виду с последующей проверкой, что итоговый путь начинается с разрешённой корневой директории.
Использовании белых списков разрешённых имён файлов вместо попыток отфильтровать опасные последовательности.
Хранении файлов вне корня веб-сервера и отдаче их через специальный обработчик, который проверяет права доступа.
Минимализации привилегий пользователя, от которого работает веб-сервер.

Атаки на истощение ресурсов

Цель — не сломать логику, а исчерпать физические ресурсы сервера: память (RAM), процессорное время (CPU), дисковое пространство, количество дескрипторов файлов или сетевых соединений. Это приводит к отказу в обслуживании (DoS) для легитимных пользователей.

Примеры: отправка запроса на генерацию отчёта с параметрами, требующими обработки гигабайтов данных; загрузка множества огромных файлов для заполнения диска; создание миллионов мелких объектов в памяти через уязвимый endpoint.

Стратегии защиты:

Установка жёстких лимитов на потребление ресурсов для каждого запроса/пользователя/процесса (лимиты памяти, времени выполнения, размера тела запроса).
Квотирование и мониторинг использования ресурсов в реальном времени.
Использование механизмов rate limiting не только по количеству запросов, но и по сложности/«весу» операций.
Оптимизация алгоритмов, чтобы они не могли уйти в «бесконечное» потребление ресурсов при любых входных данных.
Выделение критически важных endpoint в отдельные пулы ресурсов с изоляцией.

Сводная таблица векторов атак и мер защиты

Вектор атаки	Суть угрозы	Ключевые меры защиты
CSRF	Выполнение действий от имени аутентифицированного пользователя без его ведома.	CSRF-токены, атрибут SameSite для кук, проверка Origin/Referer.
Race Condition	Нарушение логики из-за параллельного доступа к общему ресурсу.	Атомарные операции, блокировки, транзакции с уровнем изоляции Serializable.
Некорректный ввод	Нарушение логики или выполнение кода через манипуляцию данными.	Валидация по белому списку, параметризованные запросы, контекстное экранирование.
Ошибки	Утечка внутренней информации о системе.	Общие сообщения для пользователя, детальное логирование в защищённое хранилище.
API	Компрометация бизнес-логики и данных через интерфейсы взаимодействия.	Строгая авторизация, валидация схемы, rate limiting, HTTPS.
Replay	Повторное выполнение легитимной операции.	Nonce, временные метки, цифровые подписи.
Path Traversal	Чтение произвольных файлов на сервере.	Нормализация путей, белые списки имён, хранение файлов вне webroot.
Истощение ресурсов	Отказ в обслуживании из-за исчерпания CPU, RAM, диска.	Лимиты на ресурсы запросов, квотирование, мониторинг.

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