Основы веб-безопасности

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

Для кого курс

• Начинающие backend-разработчики.
• Тестировщики, которым нужно проверять веб-приложения глубже UI.
• Студенты, интересующиеся CTF и безопасной разработкой.
• Администраторы учебных стендов и внутренних сервисов.

Формат

• Мини-лекция с демонстрацией.
• Практика на учебном стенде.
• Разбор типичных ошибок.
• Короткий отчет по итогам каждой недели.

Неделя 1. HTTP и поверхность атаки

Темы

• Методы HTTP: GET, POST, PUT, DELETE.
• Query-параметры, формы и тело запроса.
• Cookies, сессии и базовая модель авторизации.
• Заголовки запроса и ответа.
• Коды ответа и их смысл для диагностики.
• Browser DevTools и просмотр сетевых запросов.
• Разница между frontend-валидацией и серверной проверкой.

Практика

• Найти скрытые параметры в ссылках.
• Повторить запрос через curl.
• Поменять параметр в URL и сравнить ответы.
• Определить, где сервер раскрывает лишнюю диагностику.

Домашнее задание

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

Неделя 2. Файлы, шаблоны и ввод пользователя

Темы

• Path traversal и небезопасная работа с путями.
• Почему нельзя напрямую открывать путь из query-параметра.
• Allowlist вместо blacklist.
• Ошибки шаблонизаторов и утечки стека вызовов.
• Отладочные страницы и диагностические endpoint-ы.
• Разделение публичных и внутренних файлов.
• Минимальные права для процесса приложения.

Практика

• Найти функцию предпросмотра, читающую файл.
• Проверить разные варианты относительных путей.
• Сравнить безопасную и небезопасную реализацию.
• Описать, какие файлы можно читать и почему это риск.

Домашнее задание

Подготовить короткий security report: название уязвимости, шаги воспроизведения, влияние на систему и рекомендации по исправлению.

Неделя 3. Перед публикацией в продакшен

Темы

• Debug-режимы и почему они опасны на внешнем контуре.
• Секреты в коде, файлах и переменных окружения.
• Конфигурация staging и production.
• Системные файлы, которые часто помогают атакующему.
• Логи и аккуратная обработка ошибок.
• Чеклист релиза для Flask-приложения.
• Принцип минимального раскрытия информации.

Практика

• Найти признаки debug-режима.
• Определить, какие настройки нельзя переносить в production.
• Сформировать список hardening-задач.
• Разобрать пример плохого deployment checklist.

Домашнее задание

Сделать финальный отчет по учебному стенду: перечислить найденные проблемы, оценить критичность и предложить порядок исправления.

Финальный проект

Студенты получают маленькое веб-приложение и должны:

• Найти минимум две проблемы безопасности.
• Подтвердить каждую проблему безопасным способом.
• Не ломать данные и не выполнять разрушительные действия.
• Подготовить отчет для разработчика.
• Добавить раздел “как проверить исправление”.

Контрольные вопросы

• Почему нельзя доверять query-параметру с именем файла?
• Чем allowlist лучше blacklist для выбора шаблона?
• Почему stack trace может быть полезен атакующему?
• Что должно отличаться между staging и production?
• Как объяснить риск без излишней драматизации?

Лабораторные работы

Лабораторная 1. Карта поверхности приложения

Студент исследует учебный сайт, фиксирует все страницы, параметры, формы и отличия в ответах сервера. Цель — научиться смотреть на приложение как на набор входных точек.

Проверяется:

• полнота карты endpoint-ов;
• аккуратность заметок;
• умение отличать пользовательский функционал от технических деталей;
• корректное повторение запросов через curl;
• фиксация кодов ответа.

Лабораторная 2. Небезопасный предпросмотр

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

Проверяется:

• безопасное подтверждение path traversal;
• отсутствие разрушительных действий;
• сравнение нормального и аномального поведения;
• описание влияния уязвимости;
• предложение исправления через allowlist.

Лабораторная 3. Релизный чеклист

Студент получает конфигурацию staging-приложения и должен определить, какие пункты нельзя переносить в production.

Проверяется:

• поиск debug-настроек;
• анализ переменных окружения;
• выявление лишних диагностических endpoint-ов;
• рекомендации по логированию;
• оформление краткого отчета.

Критерии оценки

• Все шаги воспроизведения понятны и повторяемы.
• В отчете нет разрушительных payload-ов без необходимости.
• Риск описан через влияние на данные или управление приложением.
• Исправления реалистичны для команды разработки.
• Указан способ проверить, что проблема исправлена.

Типичные ошибки

• Писать “сайт небезопасен” без конкретного сценария.
• Путать информационную утечку и RCE.
• Не указывать версию или окружение.
• Делать выводы только по одному ответу сервера.
• Предлагать blacklist вместо строгого списка допустимых файлов.

Дополнительные темы

• Безопасная обработка загрузок.
• Разделение публичных assets и внутренних файлов.
• Настройка Flask error handlers.
• Секреты и ротация ключей.
• Минимальные права процесса приложения.

Результат

Студент научится видеть опасные места в привычных endpoint-ах, оформлять короткий security report и объяснять риск разработчикам понятным языком.