XSS — межсайтовый скриптинг
- Что это: выполнение attacker‑скрипта в контексте страницы жертвы (stored / reflected / DOM‑based).
- Уязвимый пример (PHP, отражённый XSS):
<?php
echo $_GET['q']; // уязвимо — напрямую выводится пользовательский ввод
?> - Практические меры разработки:
- Экранировать/энкодить вывод в соответствии с контекстом (HTML, атрибут, JavaScript, URL). В PHP: `htmlspecialchars($s, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')`.
- Использовать безопасные шаблонизаторы/фреймворки, которые автоэкранируют.
- Для вставки в DOM использовать безопасные API (`textContent`, `setAttribute` вместо `innerHTML`).
- Внедрить Content Security Policy (CSP) с запретом inline‑скриптов и подключением nonce/hashes.
- Устанавливать флаги cookie: `HttpOnly`, `Secure`, `SameSite`.
- Тестирование:
- Автоматические сканеры (Burp, OWASP ZAP), ручное тестирование с payload‑ами (`alert(1)`, контекстно‑специфичные полезные нагрузки).
- Unit/интеграционные тесты для функций энкодинга.
- Инструменты для анализа DOM (DOM‑инструменты браузера, Snyk/retire для библиотек).
- Внедрить CI‑проверки на присутствие небезопасных вставок.
CSRF — межсайтовая подделка запроса
- Что это: браузер автоматически отправляет авторизационные куки при запросе, и атакующий заставляет жертву выполнить нежелательное действие.
- Уязвимый пример (HTML форма атакующего):
document.forms[0].submit() - Практические меры разработки:
- Анти‑CSRF токены: генерировать per‑session или per‑form токен, встраивать в форму и проверять на сервере.
- Альтернативы/дополнения: SameSite cookie (Lax/Strict), проверка заголовков `Origin`/`Referer`, требование пользовательского заголовка (AJAX с X‑Requested‑With / custom header), двойная отправка cookie.
- Не полагаться только на методы GET для изменения состояния; использовать POST/PUT+проверки.
- Тестирование:
- Пробные PoC‑формы, проверка обхода токенов.
- Автоматические сканеры CSRF, ручная проверка поведения при отсутствии/неверном токене.
- Unit/интеграционные тесты для валидации токена и обработки SameSite.
Буферные переполнения (buffer overflow)
- Что это: запись за пределы выделенного буфера в памяти, приводящая к corruption, выполнению кода или краху (типично в C/C++).
- Уязвимый пример (C):
void vuln(char *input) {
char buf[16];
strcpy(buf, input); // нет проверки длины — риск переполнения
}
- Практические меры разработки:
- Предпочитать безопасные языки с управляемой памятью (Rust, Go, Java, C#) для новых компонентов.
- В C/C++ использовать безопасные API: `snprintf`, `strncpy`/`strlcpy` с явной длиной и проверкой итоговой длины, проверять границы перед копированием.
- Использовать современные компиляторные опции и защиты: stack canaries (`-fstack-protector`), ASLR, DEP/NX, `-D_FORTIFY_SOURCE=2`.
- Включить анализ статической безопасности (SAST), code review, избегать опасных функций (`gets`, `strcpy`, `sprintf` без длины).
- Тестирование:
- Статический анализ (Coverity, clang‑tidy, cppcheck).
- Динамическое тестирование: AddressSanitizer (`-fsanitize=address`), Valgrind.
- Фаззинг (AFL, libFuzzer) для покрытия неожиданных входов и выявления переполнений.
- Модульные тесты с граничными и некорректными входами; интеграция проверок в CI.
Общие практики для всех типов:
- Тщательный review критичных изменений, threat modeling при дизайне.
- Интеграция SAST/DAST и тестов безопасности в CI/CD.
- Обновление зависимостей и использование проверенных библиотек.
- Логирование инцидентов и мониторинг (CSP reporting, WAF, RASP).
Если нужно — могу привести минимальные правки к коду для каждого примера.