Опишите основные классы уязвимостей в веб-программировании (XSS, CSRF, SQLi, RCE и т.д.): как они возникают в коде, какие практики предотвращения должны быть встроены в процесс разработки и тестирования?

19 Ноя в 10:17
2 +1
0
Ответы
1
Кратко о наиболее важных классах уязвимостей и практиках их предотвращения.
XSS (Cross‑Site Scripting)
- Как возникает в коде: приложение выводит пользовательские данные в HTML/JS/CSS без контекстного экранирования (reflected/stored/DOM‑XSS — вставка в DOM через небезопасный innerHTML, eval и т.п.).
- Практики предотвращения: контекстное экранирование на выходе (HTML/attribute/JS/CSS/URL), использовать шаблонизаторы с автo‑эскейпом, избегать eval()/innerHTML, Content Security Policy (CSP) как защитный слой, HttpOnly/secure для сесс.куки. Тестирование: SAST/DAST, автоматические сканеры XSS, ручное тестирование payload‑ами, unit‑тесты для выходного экранирования.
CSRF (Cross‑Site Request Forgery)
- Как возникает в коде: приложение принимает побочные запросы аутентифицированного пользователя (обычно state‑changing) без подтверждения происхождения.
- Практики предотвращения: одноразовые CSRF‑токены или двойной Submit Cookie, проверка Origin/Referer для кросс‑доменных запросов, SameSite для cookie, применить idempotency/anti‑replay где применимо. Тестирование: автоматизированные DAST/CSRF тесты, проверки наличия валидных токенов в формах/API.
SQLi (SQL Injection)
- Как возникает в коде: динамическая конкатенация пользовательских данных в SQL‑запросы; недостаточная валидация/экранирование.
- Практики предотвращения: параметризованные запросы/prepared statements или ORM с параметризацией, избегать динамического SQL; whitelist валидация для полей типа «sort», «column», лимит прав БД (least privilege), логирование подозрительных запросов. Тестирование: SAST для поиска конкатенации SQL, DAST/SQLi‑сканеры, ручное тестирование payload‑ами.
RCE / Command injection
- Как возникает в коде: выполнение пользовательских данных как кода/команды (eval, exec, system, небезопасная десериализация, шаблоны, небезопасный запуск shell).
- Практики предотвращения: никогда не выполнять данные пользователя, использовать API без shell (напр., библиотеки вместо system), строгая валидация/whitelist параметров, избегать unsafe deserialization; применять sandboxing и минимальные привилегии, обновления/патчи. Тестирование: SAST на вызовы eval/exec, динамические тесты на инъекции команд, fuzzing.
Небезопасная десериализация
- Как возникает: десериализация данных от ненадёжных источников приводит к созданию объектов, которые выполняют логики/пользуются gadget‑цепочками.
- Практики предотвращения: не десериализовать данные от клиента; использовать форматы без выполнения (JSON) и явные парсеры; подписывать/шифровать сериализованные объекты; ограничения классов (allowlist) и обновления библиотек. Тестирование: фазы SAST, динамические тесты десериализации, анализ цепочек gadget‑эксплойтов.
SSRF (Server‑Side Request Forgery)
- Как возникает: приложение делает HTTP/URL/FTP/other запросы на основе контролируемых пользователем URL без проверки, что приводит к доступу к внутренним сетям.
- Практики предотвращения: whitelist доменов/IP, запрет локальных адресов (127.0.0.1, link‑local), DNS‑резолвинг в контролируемой среде, ограничение исходящего трафика на сетевом уровне. Тестирование: DAST/ручное тестирование внутренних/внешних эндпойнтов.
Файловые уязвимости (upload, LFI/RFI)
- Как возникает: отсутствие проверки типа/имени/путей при загрузке и/или включение/выполнение загруженных файлов; небезопасные include/require с пользовательским input.
- Практики предотвращения: проверка типа контента на стороне сервера, переименование файлов, хранение вне веб‑корня, запрет исполнения, path‑normalization и whitelist для путей, избегать включения по URL. Тестирование: DAST на загрузку файлов с различными payload, анализ доступности загруженных файлов.
Нарушения контроля доступа (IDOR, Broken Auth/ACL)
- Как возникает: неверная проверка прав на действия/ресурсы (например, использовать чужой ID в URL без проверки прав).
- Практики предотвращения: централизованный механизм авторизации, проверка прав на уровне бизнес‑логики и БД, тесты на роли/границы доступа, принцип наименьших прав, multi‑factor auth, надёжное управление сессиями. Тестирование: unit/integration тесты прав доступа, ручные сценарии эскалации привилегий, IAM аудит.
Небезопасное использование зависимостей и конфигураций
- Как возникает: уязвимые библиотеке/компоненты, открытые debug/metrics, конфигурации по умолчанию (weak crypto, открытые порты).
- Практики предотвращения: сканирование зависимостей (SCA), регулярные обновления/патчи, секреты вне кода (vault), безопасные настройки по умолчанию, мониторинг и быстрый патч‑менеджмент. Тестирование: SCA/сканеры уязвимостей, конфигурационный аудит.
Общие практики разработки и тестирования (обязательные)
- Валидация входа + экранирование выхода (validate input, encode output).
- Принцип «наименьших привилегий» для пользователей и сервисов.
- Использование готовых безопасных библиотек/фреймворков и автопроверка (prepared statements, шаблонизаторы).
- Threat modeling и security requirements на ранних этапах разработки.
- SAST/DAST/IAST в CI/CD; автоматические тесты безопасности как этап сборки.
- Периодический ручной pentest и fuzzing критичных компонентов.
- Логирование, мониторинг инцидентов, быстрое реагирование и план обновлений.
- Security code reviews и чеклисты (включая проверку на OWASP‑типовые уязвимости).
Короткое заключение: предотвращение уязвимостей — сочетание безопасного кодирования (вход/выход/контекст), архитектурных мер (разделение привилегий, сетевые фильтры), использования проверенных библиотек и регулярного автоматизированного + ручного тестирования на всех этапах разработки.
19 Ноя в 10:25
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Прямой эфир