День 02 · полный учебный архив
Второй день связывает OWASP A07–A10, инженерную безопасность non-web‑приложений, SSDLC и практикум. Здесь собраны нормализованная полная стенограмма, 133 слайда, методический конспект и задания, переработанные после технического ревью.
Карта материала
Страница читает второй день как связный курс. Фотослайды дают первичный визуальный ряд, а подробные Markdown‑материалы — удобный для поиска, проверки и повторного применения текст.
Редакционное решение
В исходной лекции рядом существуют текущая классификация 2025 года и лабораторный маршрут, сформированный по OWASP Top 10:2021. Это не повод сокращать материал: это повод точно обозначить границу версий.
| Тема | Историческая лабораторная карта | OWASP Top 10:2025 | Как читать этот архив |
|---|---|---|---|
| Аутентификация | A07:2021 — Identification and Authentication Failures | A07:2025 — Authentication Failures | Тема и номер сохранились; современное название используется в конспекте. |
| Целостность ПО и данных | A08:2021 — Software and Data Integrity Failures | A08:2025 — Software or Data Integrity Failures | Смысл темы сохранён; особое внимание — цепочке поставки и небезопасной десериализации. |
| Журналирование и мониторинг | A09:2021 — Security Logging and Monitoring Failures | A09:2025 — Security Logging & Alerting Failures | Расширено понятие: записи без обнаружения и реакции не образуют контроль. |
| SSRF / исключительные ситуации | A10:2021 — Server-Side Request Forgery (SSRF) | A10:2025 — некорректная обработка исключительных ситуаций | SSRF сохранён как историческая ЛР и тематическое дополнение; fail-open, таймауты и ошибки выделены как самостоятельная современная тема. |
OWASP Top 10:2025 — A07–A10
Лекционная последовательность идёт от идентичности пользователя к целостности данных, наблюдаемости и корректному отказу. Для каждой категории важны не только «атака» и «фикс», но и критерий, по которому команда докажет исправление.
Схема 16
Credential stuffing, password spraying, слабое восстановление доступа, предсказуемые или зафиксированные сессии — разные сценарии, но общая задача одна: не принимать неубедительное доказательство идентичности.
Безопасность сборки, зависимостей, обновлений и сериализованных данных зависит от проверяемой цепочки доверия. Данные структурированного формата не становятся безопасными только потому, что «это YAML» или «это JSON».
Логирование нужно проектировать как измеримый контроль: какие события, какие поля, как защищена целостность записи, кто реагирует и по какому порогу. Много логов без корреляции и владельца реакции не равно мониторингу.
Fail-open, скрытая ошибка, бесконечное ожидание и неконтролируемый переход по URL могут превратить вспомогательную функцию в уязвимость. SSRF показывает, почему серверу нельзя доверять URL, выбранному клиентом.
Историческая ЛР 10
Вместо нестабильного challenge в конкретной версии Juice Shop практикум использует воспроизводимый стенд: локальный gateway передаёт запрос приватному приложению, а уязвимый fetch и синтетический внутренний сервис остаются в закрытой сети. В нём нет доступа к корпоративной сети, внешним URL или реальным metadata endpoints.
Схема 17
Non-web AppSec
Во второй части дня обсуждались нативные C/C++‑программы, мобильные и desktop‑приложения. Во всех трёх случаях важны входные точки, границы доверия, привилегии процесса, обновления и диагностические интерфейсы.
Buffer overflow, integer overflow/underflow, use-after-free и ошибки владения могут менять управление или данные процесса. Защита начинается с API и модели владения, затем усиливается компилятором, линковщиком, анализом и тестами.
У мобильного приложения атака часто начинается с exported component, intent, deeplink, небезопасного WebView или резервной копии. У desktop‑приложения — с updater, конфигурации, локального IPC, плагинов, файловых ассоциаций и прав процесса.
Схема 18
SSDLC
В лекции рассматривались водопадная, итеративная, agile‑подходы, V‑модель, спираль и прототипирование. SSDLC не отменяет выбранную модель: он добавляет в неё безопасность как критерий готовности и обратную связь.
Схема 19
ГОСТ Р 56939‑2024, ISO/IEC 27034, NIST SSDF, OWASP ASVS и SAMM задают язык требований и зрелости. В этой лекции они используются как опоры для формулы «угроза → требование → контроль → доказательство», но сама страница не заявляет соответствие организации какому-либо стандарту.
Моделирование угроз удобно вести с помощью STRIDE; CVSS относится к оценке тяжести уже найденной уязвимости и не заменяет моделирование угроз.
Конструктор ЛР
Практическая часть второго дня учит преподавателя конструировать лабораторную работу так, чтобы она оценивала понимание первопричины, а не факт срабатывания. Ниже — каркас, по которому собрана каждая из 12 работ практикума.
Схема 20
Слушателю
Когда сами собираете или решаете задание, начинайте не с payload, а с формулировки: какой актив, какая граница доверия, какой контроль отсутствует. Проверяйте себя вопросом «если внедрить моё исправление, наблюдение перестанет воспроизводиться?».
Заметка преподавателя
Дайте каждой группе собрать одно задание по каркасу и обменяться с соседней на проверку. Слабое место — цель «через инструмент» вместо цели «через наблюдаемое действие»; разберите это на общем примере до начала.
План внедрения
Безопасность становится свойством курса, когда каждый этап проектной работы студентов получает проверяемый security-критерий. Ниже — минимальный набор изменений, который переносится в существующую программу без её слома.
Слушателю
Даже в учебном проекте предъявляйте один проверяемый security-артефакт: модель угроз, результат сканера или regression-тест. Это и есть навык, который переносится в работу.
Заметка преподавателя
Начните с одного gate и одного артефакта на проект, а не со всей цепочки сразу. Готовые критерии, рубрика и чек-листы — в методике дня 2.
ИИ и образование
Финальная дискуссия дня касалась LLM, агентных систем и образования: как использовать инструмент для исследования, черновика и проверки гипотез, не подменяя понимание заимствованным ответом.
Для обучающегося
Фиксируйте, что сгенерировал инструмент, что вы проверили самостоятельно и по какому первоисточнику. Не передавайте в внешний сервис секреты, персональные данные, исходный код без разрешения или внутренние материалы. Результат сдаётся с рассуждением и проверяемым артефактом.
Для преподавателя
Оценивать стоит не только финальный текст: задайте вариативный контекст, попросите объяснить границы решения, показать следы проверки и защитить выбор. ИИ‑инструмент полезен для подготовки кейса, но критерии должны проверять самостоятельное инженерное мышление.
Практикум из 12 лабораторных
Подготовительная ЛР_0 строит карту активов, ЛР_1–ЛР_9 покрывают A01–A09:2025, ЛР_10 сохраняет историческую SSRF A10:2021, а ЛР_11 закрывает безопасность памяти. A10:2025 рассматривается в лекционном блоке об обработке исключительных ситуаций, но отдельной лабораторной в наборе не заявлена. Идеи работ подгрупп прошли редакторское и техническое ревью; исходные документы не публикуются.
| ЛР | Задание | Что доказывает студент | Карта |
|---|---|---|---|
| ЛР_0 | Инвентаризация активов | Активы, точки входа, границы доверия и топ-5 критических активов. | подготовительная |
| ЛР_1 | Контроль доступа (BOLA/IDOR) | Сервер проверяет владение объектом и роль, а не клиентский идентификатор. | A01:2025 · CWE‑639/862 |
| ЛР_2 | Устаревший интерфейс | Скрытый endpoint — часть поверхности; файл проверяется по содержимому. | A02:2025 · CWE‑16/434 |
| ЛР_3 | Уязвимая зависимость | SBOM, SCA и контроль состава против известной уязвимости компонента. | A03:2025 · CWE‑1104 |
| ЛР_4 | Утечка данных + неподписанный JWT | Контроль доступа к файлам и проверка подписи и алгоритма токена. | A04:2025 · CWE‑548/347 |
| ЛР_5 | Инъекции: SQLi и XSS | Разделение кода и данных: параметризация и контекстное кодирование. | A05:2025 · CWE‑89/79 |
| ЛР_6 | Инвариант корзины | Отрицательное количество нарушает бизнес-правило; фиксируется в API, БД и регрессии. | A06:2025 · CWE‑20/840 |
| ЛР_7 | Дефолтные учётные данные | Защита жизненного цикла учётки без массового подбора. | A07:2025 · CWE‑521 |
| ЛР_8 | Небезопасная десериализация | Структурированный вход недоверен; лимиты и безопасный парсер в изолированном стенде. | A08:2025 · CWE‑502/400 |
| ЛР_9 | Метрики и логирование | Событие как контроль с alerting и владельцем; закрытые метрики и секреты. | A09:2025 · CWE‑778/532 |
| ЛР_10 | SSRF: server-side fetch | Граница браузер/сервер, egress-изоляция, allowlist и отрицательные тесты. | A10:2021 · CWE‑918 |
| ЛР_11 | Переполнение буфера | Отсутствие проверки границ ведёт к выполнению команды; hardening лишь компенсирует. | память · CWE‑787/120 |
Архив второго дня
Полная стенограмма не является исходным ASR‑файлом: она приведена к литературной и технической норме, содержит время, роли говорящих и редакторские пометки. Рабочие TXT‑файлы, документы подгрупп и персональные данные в скачивание не включены.
Все содержательные реплики, вопросы, переходы и открытая дискуссия трёх фрагментов дня.
Скачать Markdown ↓Решения, оговорки по версиям OWASP, выводы и материал для преподавателя.
Скачать протокол ↓Интерактивная текстовая дека с делением на тематические блоки, поиском и доступной навигацией. Исходные изображения слайдов не размещаются и не входят в ZIP‑пакеты.
Открыть слайды →Структурированная версия лекции с контрольными вопросами, связями с SSDLC и источниками.
Скачать конспект ↓Отредактированные стенограмма и протокол, конспект, Markdown-версия веб‑колоды, практикум и безопасный SSRF‑стенд с манифестом и контрольными суммами.
Скачать пакет ↓Что послужило исходником, какие правки внесены и какие материалы сознательно не публикуются.
Открыть реестр ↓Двенадцать работ ЛР_0–ЛР_11: подготовка, A01–A09:2025, историческая SSRF A10:2021 и нативная память, с рубрикой оценивания.
Скачать задания ↓Полная нормализованная стенограмма и редактированный протокол дня 2 одним архивом.
Скачать ZIP ↓MFA, десериализация, STRIDE, RELRO, WebView и ещё десятки понятий — понятным языком.
Открыть глоссарий →Тайминг, уровни сложности, рубрика на 10 баллов, типичные ошибки и чек-лист.
Открыть методику →SHA-256 и манифест публичных пакетов дня 2 для проверки целостности при переиспользовании.
SHA-256 ↓ Манифест ↓Проверяемые опоры
Текст лекции не подменяет стандарт или техническую документацию. При разработке и аудите сверяйте требования с актуальной версией первоисточника и применимостью к системе.
Актуальная таксономия веб‑рисков, включая A07, A08, A09 и A10.
Проверяемые требования для проектирования и верификации приложений.
Практики подготовки, защиты, производства и реагирования в жизненном цикле ПО.
Модель зрелости практик управления, проектирования, реализации, верификации и эксплуатации.
Практики прикладной и сетевой защиты server-side requests.
Транскрипты, фото слайдов, результаты ревью и редакторские решения.
