Модуль 3 • Урок 8

Защита приложений: Мышление хакера

Научитесь находить и исправлять уязвимости в коде до того, как их найдут злоумышленники. Мы разберем классические атаки из OWASP Top 10 и методы защиты.

1. Анализ защищенности приложений: Введение в AppSec

Application Security (AppSec) — это процесс внедрения мер безопасности на всех этапах жизненного цикла разработки программного обеспечения (SDLC - Software Development Lifecycle). Основная идея — **"Shift Left"**, то есть "сдвиг влево". Мы должны находить и исправлять уязвимости как можно раньше — на этапе проектирования и написания кода, а не после того, как приложение уже взломали.

OWASP (Open Web Application Security Project) — это ваш главный ресурс в мире AppSec. Их проект OWASP Top 10 — это список десяти самых критических рисков для веб-приложений. Мы разберем многие из них сегодня.

Мышление хакера: Никогда не доверяйте данным, приходящим от пользователя. Любое поле ввода, любой параметр в URL, любой cookie — это потенциальный вектор для атаки. Ваша задача — думать, как злоумышленник, и пытаться "сломать" приложение всеми возможными способами.

2. SQL-инъекции: Повторение и углубление

Мы уже подробно разбирали эту атаку в уроке по безопасности баз данных. Это классический пример уязвимости, связанной с **внедрением кода (Injection)**. Давайте вспомним главное.

  • Причина: Недоверие к пользовательскому вводу и "склеивание" SQL-запросов из строк.
  • Последствия: От утечки всей базы данных до полного захвата сервера.
  • Главная защита: Подготовленные выражения (Prepared Statements / Parameterized Queries). Этот механизм разделяет код запроса и данные, делая инъекцию невозможной.
# Уязвимый код на PHP $id = $_GET['id']; $query = "SELECT * FROM products WHERE id = " . $id; # Безопасный код на PHP с использованием PDO $stmt = $pdo->prepare('SELECT * FROM products WHERE id = :id'); $stmt->execute(['id' => $id]);

3. Cross-Site Scripting (XSS): Атака на пользователей

XSS — это уязвимость, которая позволяет атакующему внедрить вредоносный JavaScript-код на веб-страницу, которую просматривают другие пользователи. В отличие от SQLi, которая атакует сервер, XSS атакует браузеры ваших пользователей.

Типы XSS:

  • Stored XSS (Хранимая): Самая опасная. Атакующий сохраняет вредоносный скрипт в базе данных (например, в комментарии на форуме или в своем профиле). Каждый, кто откроет эту страницу, выполнит скрипт.
  • Reflected XSS (Отраженная): Скрипт внедряется через URL-параметр. Например, в строке поиска. Атакующий должен заставить жертву перейти по специально сформированной ссылке.
  • DOM-based XSS: Уязвимость находится в клиентском JavaScript-коде, который неправильно обрабатывает данные из URL и вставляет их в HTML-код страницы (DOM).

Что может сделать XSS? Украсть cookie-файлы сессии пользователя (и зайти под его именем), перехватить ввод с клавиатуры (кейлоггер), перенаправить на фишинговый сайт, изменить содержимое страницы.

Защита от XSS:

Экранирование вывода (Output Encoding): Это главная защита. Перед тем как вставить любые данные, полученные от пользователя, в HTML-страницу, вы должны преобразовать специальные символы в их безопасные HTML-эквиваленты. < становится <, > становится >, " становится ".

Добро пожаловать, !

Добро пожаловать, !

4. Path Traversal и IDOR: Атаки на контроль доступа

Path Traversal (Обход каталога)

Эта атака позволяет атакующему читать файлы за пределами корневой директории веб-сервера. Она возникает, когда имя файла передается в URL, и приложение не проверяет путь.

Предположим, URL для скачивания файла выглядит так: `https://example.com/download.php?file=report.pdf`. Атакующий может попытаться выйти на уровень выше, используя `../`.

# Попытка прочитать системный файл с паролями https://example.com/download.php?file=../../../../etc/passwd

Защита: Никогда не доверяйте именам файлов от пользователя. Проверяйте, что путь к файлу не содержит `../` и находится внутри разрешенной директории.

IDOR (Insecure Direct Object References)

Небезопасные прямые ссылки на объекты. Это уязвимость контроля доступа, когда приложение позволяет пользователю получить доступ к чужим данным, просто изменив ID в URL.

Например, вы заходите в свой профиль по адресу `https://example.com/profile?id=123`. Если вы измените URL на `https://example.com/profile?id=124` и увидите профиль другого пользователя — это IDOR.

Защита: На сервере, перед тем как отдать любые данные, всегда проверяйте, имеет ли текущий аутентифицированный пользователь право на доступ к запрашиваемому объекту.

5. CSRF: Атака от чужого имени

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

Как это работает:

  1. Вы залогинены в своем онлайн-банке.
  2. Вы открываете в другой вкладке вредоносный сайт (или даже письмо с картинкой).
  3. На этом сайте есть скрытая форма или картинка, чей `src` ведет на URL для перевода денег в вашем банке: `https://mybank.com/transfer?to=attacker&amount=1000`.
  4. Ваш браузер автоматически прикрепит к этому запросу ваши cookie-файлы для `mybank.com`, и банк выполнит перевод, думая, что это сделали вы.

Защита от CSRF: Anti-CSRF токены

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

6. Уязвимости сторонних библиотек

Современные приложения на 80-90% состоят из кода, который вы не писали — из сторонних библиотек, фреймворков и зависимостей. Это огромный вектор для атаки. Если в популярной библиотеке (например, Log4j, OpenSSL) находят уязвимость, миллионы приложений по всему миру становятся уязвимыми.

Эта категория в OWASP Top 10 называется "Vulnerable and Outdated Components" (Уязвимые и устаревшие компоненты).

Защита: SCA (Software Composition Analysis)

Вы должны постоянно сканировать свой проект на наличие уязвимых зависимостей. Для этого существуют автоматизированные инструменты (SCA-сканеры), такие как:

  • OWASP Dependency-Check (open-source)
  • Snyk
  • GitHub Dependabot (встроен в GitHub)

Эти инструменты сверяют версии библиотек в вашем проекте с глобальными базами данных уязвимостей (CVE) и предупреждают вас, если нужно обновиться.

7. Статический анализ кода (SAST)

SAST (Static Application Security Testing) — это "белый ящик" для анализа безопасности. Это автоматизированный процесс анализа исходного кода приложения без его запуска. SAST-сканер работает как очень придирчивый рецензент, который ищет в коде паттерны, указывающие на потенциальные уязвимости (SQL-инъекции, XSS, небезопасные функции).

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

Популярные SAST-инструменты: SonarQube, Checkmarx, CodeQL (от GitHub).

8. Web Application Firewall (WAF): Последний рубеж обороны

WAF — это специализированный файрвол, который работает на прикладном уровне (L7). Он располагается между пользователями и вашим веб-сервером и анализирует весь HTTP/HTTPS трафик на наличие признаков атак (SQLi, XSS, Path Traversal и др.).

WAF — это не "серебряная пуля". Он является важным, но последним эшелоном защиты. Вы не должны полагаться только на него. Главное — исправлять уязвимости в самом коде.

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

Популярные WAF: ModSecurity (open-source), Cloudflare WAF, AWS WAF.

9. Практическое задание: Анализ уязвимого кода

Ниже приведен фрагмент кода на PHP для простого блога. Ваша задача — провести его аудит и найти как можно больше уязвимостей из тех, что мы сегодня изучили.

query("SELECT * FROM users WHERE id = $userId"); $user = $result->fetch_assoc(); echo "

Профиль: " . $user['username'] . "

"; // search.php - Поиск по статьям $searchTerm = $_GET['q']; echo "

Результаты поиска для: $searchTerm

"; $result = $db->query("SELECT title FROM articles WHERE content LIKE '%$searchTerm%'"); // download.php - Скачивание аватара $file = $_GET['avatar']; readfile("/var/www/html/avatars/" . $file); ?>

Задание:

  1. Найдите в этом коде как минимум три разные уязвимости.
  2. Для каждой уязвимости укажите ее тип (например, Stored XSS, SQLi, ...).
  3. Кратко опишите, как атакующий мог бы ее проэксплуатировать.
  4. Предложите, как исправить каждую из этих уязвимостей.

Это задание проверит вашу способность "читать" код глазами специалиста по безопасности и применять теоретические знания на практике.