SQL‑инъекция, буферный переполнение и XSS — три классические уязвимости с разными механизмами и мерами защиты. Ниже — компактный разбор: механизм возникновения, демонстративный (не эксплуатационный) пример уязимой реализации и конкретные методы защиты.
1) SQL‑инъекция
- Механизм: приложение формирует SQL‑запрос, подставляя пользовательский ввод напрямую в строку запроса; злоумышленник подбирает ввод так, чтобы изменить семантику запроса (извлечь/удалить данные, обойти аутентификацию).
- Вариант уязвимого кода (псевдокод, иллюстрация проблемы):
- уязвимо: `query = "SELECT * FROM users WHERE login = '" + userInput + "';"`
- здесь логика собирает строку запроса конкатенацией.
- Почему это опасно (концептуально): ввод может вставить дополнительные операторы/условия в SQL, изменить WHERE/ORDER/UNION и т.д.
- Демонстративный пример воздействия (описательно, без шагов эксплуатации): если ввод содержит синтаксические элементы SQL, приложение может вернуть данные других пользователей или выполнить мошеннические изменения.
- Конкретные методы защиты:
- параметризованные запросы / подготовленные выражения (prepared statements). Пример концепта: использовать плейсхолдеры и передавать параметры отдельно;
- ORM и API доступа к БД, которые автоматически параметризуют запросы;
- валидация и allowlist для полей, где возможен набор ограниченных значений (например, id — только числа);
- минимизация прав учетной записи БД (принцип наименьших привилегий);
- логирование и лимитирование (rate limiting), мониторинг аномалий запросов;
- избегать вывода детальных ошибок БД пользователю.
- Безопасный пример (псевдокод): вместо конкатенации использовать подготовленный запрос с плейсхолдером.
- Тестирование/обнаружение: статический анализ, DAST (сканеры), unit‑тесты для граничных и вредоносных вводов.
2) Buffer overflow (переполнение буфера) в C‑модуле
- Механизм: функция копирует/записывает больше данных, чем выделено в буфере, что перезаписывает соседнюю память (локальные переменные, контрольные структуры, адрес возврата), приводя к краху или произвольному выполнению кода.
- Уязвимый фрагмент (иллюстрация):
- уязвимо: `char buf[64]; strcpy(buf, input);`
- Почему опасно (концептуально): при записи >64 байт соседние данные будут перезаписаны; если перезаписывается адрес возврата, выполнение может быть перенаправлено.
- Демонстративный пример воздействия (описательно): злоумышленник подаст слишком длинную строку, что вызовет переполнение; результат — аварийное завершение или нарушение контроля выполнения.
- Конкретные методы защиты:
- в коде — использовать безопасные API с явной длиной: `snprintf`, `strlcpy` (где есть), `memcpy` только с проверкой размера; проверять длину входных данных: условие безопасности пример: $\text{len}(input)\le N-1$ для буфера размера $N$;
- избегать небезопасных функций: `gets`, `strcpy`, `sprintf` без ограничений;
- проводить валидацию и лимитирование размеров входа на ранних уровнях (парсер, протокол);
- компиляторные и ОС‑защиты: stack canaries, ASLR (Address Space Layout Randomization), DEP/NX (запрет исполнения на стеке), PIE (position independent executables);
- современные инструменты: ASan/UBSan для обнаружения во время тестов; статический анализатор (Coverity, clang‑analyzer);
- архитектурные меры: разделение привилегий, запуск небезопасных модулей в изолированных процессах/контейнерах.
- Практическое правило копирования: перед копией проверять размер и обеспечивать нуль‑терминацию: проверять $\text{len}(input)<N$ или использовать функции, ограничивающие длину и явно ставящие `\0`.
3) XSS (Cross‑Site Scripting)
- Механизм: приложение вставляет неконтролируемый пользовательский ввод в HTML/JS контент без корректной экранизации; браузер выполнит вредоносный JS в контексте сайта.
- Типы: отражённый (reflected), хранимый (stored), DOM‑based.
- Уязвимый фрагмент (иллюстрация):
- уязвимо: в шаблоне вставляется `{{userComment}}` без экранирования; или innerHTML присваивает необработанный ввод.
- Демонстративный пример воздействия (описательно): вредоносный скрипт, помещённый в комментарий или URL, выполнится в браузере жертвы и сможет украсть сессионные данные (cookie), совершать действия от имени пользователя и т.д.
- Конкретные методы защиты:
- экранирование/санитизация при выводе в разных контекстах: HTML‑текст, атрибуты, URL, JS‑контекст — каждое требует соответствующего escaping;
- использовать фреймворки/шаблонизаторы с автоматическим экранированием (React, Vue, Razor и т.д.) и избегать ручного формирования HTML;
- Content Security Policy (CSP): ограничивает источники скриптов/стилей; пример заголовка (концептуально): `Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...';` — CSP существенно уменьшает риск исполнения сторонних скриптов;
- пометки XSS‑safe (например, strict contextual escaping) и использование `HttpOnly` и `Secure` для cookies, чтобы JS не мог читать cookie;
- защита от DOM‑XSS: не использовать `innerHTML` с необработанными данными, пользоваться textContent/innerText или безопасными API;
- валидация ввода (но валидация не заменяет экранирование при выводе).
- Тестирование/обнаружение: автоматические сканеры XSS, ревью шаблонов, CSP мониторинг (report‑uri), unit и E2E тесты с вредоносными строками.
Общие рекомендации для разработки и эксплуатации
- Принцип «ввод — недоверенный»: всегда валидируй и ограничивай вход; всегда экранируй/параметризуй при выводе/использовании.
- Defense‑in‑depth: комбинировать прикладные (валидация, escaping, prepared statements), инфраструктурные (CSP, HTTPOnly, WAF) и системные меры (ASLR, DEP, ограниченные привилегии).
- Инструменты контроля качества: статический анализ, динамическое тестирование (DAST), fuzzing, SIEM и логирование аномалий.
- Обновления: держать библиотеки/СУБД/компоненты в актуальном состоянии.
Короткие безопасные примеры (псевдокод):
- SQL (параметризованно): `db.execute("SELECT * FROM users WHERE login = ?", [userInput])`
- C (безопасная копия): проверить $\text{len}(input)<N$ и затем `memcpy(dest, input, len+1)` или `snprintf(dest, N, "%s", input)`
- XSS (вывод): использовать экранирование для HTML: заменить `&`, ``, `"` и `'` перед вставкой в HTML; либо использовать framework‑safe bindings.
Если нужно, могу: 1) показать конкретные безопасные реализации для выбранного языка/фреймворка (например, PHP/PDO, Python/sqlalchemy, C с безопасными функциями, CSP‑пример) или 2) кратко перечислить инструменты для автоматического поиска этих уязвимостей.