# Слайды первого дня: AppSec, OWASP и безопасность ИИ > Текстовая версия учебной колоды по результатам первого дня программы > АО «Лаборатория Касперского» «Образовательная лаборатория Kaspersky Academy | > Безопасность приложений». Основной блок программы вёл > Дмитрий Павлухин, архитектор по информационной безопасности. > > Всего 43 слайда в 5 тематических блоках. У каждого слайда > приведены пояснение слушателю и заметка преподавателю — те же, что показаны > под слайдом на сайте. > > Файл собирается автоматически из `assets/day-01-reconstructed-slides.js` > командой `node _build/build-slides-markdown.mjs`. Править его руками не нужно: > изменения вносятся в колоду. > > Лицензия: CC BY 4.0. Источник: > --- ## 00 · с чего начать — Что такое приложение и почему его атакуют Основание: вычищенная стенограмма, §§ 1–3. ### 01. Чем рискует пользователь Ни одно приложение не защищено на сто процентов — вопрос всегда в том, какой ущерб возможен и насколько он вероятен. - **Данные.** Утечка персональных данных, переписки, документов и платёжных реквизитов. - **Деньги и доступы.** Кража учётной записи, средств и прав, выданных этой учётной записи. - **Масштаб.** Удалённая атака опаснее физического доступа: она не требует присутствия и повторяется массово. **Главная мысль.** Права администратора у пользователя умножают ущерб от любой успешной атаки. > **Слушателю.** Запомните формулировку: «не защищено на сто процентов» — это не пессимизм, а отправная точка. Дальше разговор идёт про величину ущерба, а не про его отсутствие. > > **Преподавателю.** Хорошее начало дня для группы без подготовки: спросите, что лично они потеряют, если их почтовый ящик окажется у постороннего. Ответы дают весь список активов без единого термина. Основание: вычищенная стенограмма, § 2.1. ### 02. Чем рискует разработчик Последствия уязвимости не заканчиваются на исправлении кода. - **Ответственность.** Юридические последствия при утечке персональных данных и судебные иски. - **Деньги.** Прямые потери, простой сервиса и стоимость расследования инцидента. - **Доверие.** Репутационный ущерб, который восстанавливается дольше, чем чинится дефект. **Главная мысль.** Это и есть ответ на вопрос «зачем разработчику AppSec, если есть отдел информационной безопасности». > **Слушателю.** Если вы пишете код, последствия дефекта касаются вас, а не только «безопасников». Это самый практичный аргумент за то, чтобы разбираться в теме. > > **Преподавателю.** Слайд снимает типичное «это не моя зона ответственности». Полезно назвать конкретный масштаб штрафов за утечку персональных данных в вашей юрисдикции. Основание: вычищенная стенограмма, § 2.2. ### 03. Что вообще называют приложением Прикладное ПО решает задачу конечного пользователя и работает поверх операционной системы. - **Примеры.** Браузеры, офисные программы, почтовые клиенты, мобильные приложения, медиаплееры. - **Системное ПО.** Операционная система, драйверы, компиляторы, средства управления файлами — слой ниже. - **Границы.** Приложение не работает с оборудованием напрямую: оно наследует доверие нижних слоёв. **Главная мысль.** Безопасность приложений отвечает за прикладной уровень — но ошибка на нём открывает данные пользователя. > **Слушателю.** Проверьте себя: назовите три программы, которыми пользовались сегодня, и определите, какая из них прикладная, а какая системная. > > **Преподавателю.** Без этого слайда дальше рассыпается всё: студент не представляет, где физически исполняется код. Пятнадцать минут здесь окупаются дважды при разборе OWASP. Основание: вычищенная стенограмма, § 2.3. ### 04. Классификация программного обеспечения Разные классы ПО дают разные поверхности атаки, и смешивать их не стоит. 01. **Системное.** Операционные системы, драйверы, системные утилиты. 02. **Средства разработки.** Язык, транслятор, компоновщик, среда сборки. 03. **Общего назначения.** Редакторы текста, презентации, электронные таблицы. 04. **Специального назначения.** Бронирование, учёт, биллинг, генераторы отчётов. **Главная мысль.** Чем ближе класс ПО к данным и деньгам, тем дороже обходится один и тот же дефект. > **Слушателю.** Классификация нужна не ради названий, а чтобы понимать, какие данные проходят через программу и кто ей управляет. > > **Преподавателю.** Быстрое упражнение: попросите отнести к классам те системы, которые есть в вашем вузе. Биллинг и учёт посещаемости обычно вызывают самое живое обсуждение. Основание: вычищенная стенограмма, § 2.4. ### 05. Веб-приложения: удобство и его цена Каждое свойство, за которое любят веб, одновременно описывает его поверхность атаки. - **Не нужна установка.** Работает в браузере — значит доступно любому, кто знает адрес. - **Обновление одно на всех.** Исправление доезжает мгновенно, но и дефект — тоже. - **Данные на сервере.** Одна ошибка доступа затрагивает не одного пользователя, а всех сразу. **Главная мысль.** Масштабируемость работает в обе стороны: и на пользу сервису, и на пользу атакующему. > **Слушателю.** Каждое удобство веба — одновременно свойство поверхности атаки. Держите эту двойственность в голове при разборе категорий. > > **Преподавателю.** Приём, который работает: выписать свойства в два столбца — «почему удобно» и «что это даёт атакующему». Совпадение почти построчное. Основание: вычищенная стенограмма, § 2.5. ### 06. Клиент, сервер и балансировщик Клиент запрашивает услугу, сервер её выполняет, балансировщик распределяет запросы между серверами. 01. **Клиент.** Браузер, мобильное приложение или другой сервис. Принадлежит пользователю. 02. **Балансировщик.** Распределяет трафик и часто завершает защищённое соединение. 03. **Серверы.** Выполняют бизнес-логику и принимают решения о доступе. 04. **Хранилища.** База данных и файлы — то, ради чего всё и атакуют. **Главная мысль.** Всё, что приходит от клиента, — это данные. Даже если оно выглядит как команда. > **Слушателю.** Главное отсюда: клиент принадлежит пользователю. Его код можно прочитать, изменить и подделать, поэтому проверки на нём защитой не являются. > > **Преподавателю.** Рисуйте на доске, а не показывайте. Одна стрелка от браузера к серверу и пунктир между ними объясняют больше, чем определение границы доверия. Основание: вычищенная стенограмма, § 2.6. ### 07. Атака на клиент и атака на сервер — разные истории Различаются и способ начала, и участие жертвы, и масштаб последствий. - **Клиентская.** Жертва сама открывает файл или ссылку. Страдает одно устройство и его доступы. - **Серверная.** Жертва не участвует: достаточно, чтобы сервис был доступен. Под угрозой все пользователи. - **Общее.** В обоих случаях цену определяют права учётной записи, под которой всё выполняется. **Главная мысль.** Один класс уязвимости на клиенте и на сервере имеет разную стоимость — поэтому риск не сводится к её названию. > **Слушателю.** Разница в масштабе — первая причина, по которой одинаковые по названию уязвимости оцениваются по-разному. > > **Преподавателю.** Здесь удобно ввести вопрос «под какой учётной записью это выполняется». Он пригодится потом в каждой категории OWASP. Основание: вычищенная стенограмма, § 2.7. ### 08. Conficker: почему обновления — не формальность Червь использовал уязвимость службы удалённого вызова процедур Windows, доступную по TCP-порту 445. 01. **Исправление вышло.** Бюллетень MS08-067 был опубликован до массового заражения. 02. **Его не установили.** Пострадали системы, где обновление не применили. 03. **Сервис был открыт.** Доступный по сети порт остаётся точкой входа, даже если им «никто не пользуется». 04. **Вывод.** Закрытая уязвимость остаётся рабочей ровно до установки патча. **Главная мысль.** Управление обновлениями — такая же часть безопасности приложений, как и качество кода. > **Слушателю.** История старая, но механика не изменилась: сервис доступен, патч не поставлен — вектор рабочий. > > **Преподавателю.** Единственный конкретный исторический пример дня. Он хорошо запоминается, поэтому на него удобно ссылаться позже при разборе A02 и цепочки поставки. Основание: вычищенная стенограмма, § 2.8. ### 09. OWASP: не только Top 10 Open Worldwide Application Security Project публикует бесплатные материалы для разработчиков и тестировщиков. - **Top 10 и Mobile Top 10.** Классификации наиболее значимых рисков для веба и для мобильных приложений. - **WSTG.** Web Security Testing Guide — что проверять и как документировать тестирование. - **ASVS и DevGuide.** Проверяемые требования к защитным свойствам и практическое руководство для разработчика. **Главная мысль.** Классификация даёт общий язык; проверяемые требования и методика тестирования лежат в соседних проектах. > **Слушателю.** Top 10 — это не весь OWASP. Когда дойдёт до практики, вам понадобятся WSTG для методики и ASVS для требований. > > **Преподавателю.** Проговорите, что Top 10 — начало анализа, а не чек-лист приёмки. Иначе студенты начинают «проверять по списку» вместо моделирования угроз. Основание: вычищенная стенограмма, § 3. --- ## 01 · основы — Основы AppSec и поверхность атаки Основание: вычищенная стенограмма, §§ 3–5. ### 10. Безопасность приложений — управление риском Цель AppSec — не обещать абсолютную защиту, а уменьшать риск на всём жизненном цикле приложения. - **Требования.** Определяем активы, критичные свойства и критерии приемлемого риска. - **Архитектура и код.** Находим границы доверия, задаём защитные свойства и проверяем их тестами. - **Поставка и эксплуатация.** Контролируем зависимости, конфигурацию, развёртывание и реагирование. **Главная мысль.** Технический контроль всегда связан с владельцем риска и проверяемым результатом. > **Слушателю.** Запомните формулировку «уменьшать риск», а не «сделать безопасно». Абсолютной защиты не бывает ни у кого — вопрос всегда в том, какой риск вы согласны оставить. > > **Преподавателю.** Хороший стартовый вопрос группе: «что мы вообще защищаем в вашей курсовой системе?» Ответы почти всегда про технологии, а не про ценность — это и есть точка входа в тему. Основание: вычищенная стенограмма, § 3.1. ### 11. Под угрозой — не только веб-сайт Клиентское, мобильное, серверное и облачное ПО обрабатывают данные, выполняют действия и получают обновления. - **Клиенты.** Браузеры, редакторы, мобильные приложения и другие программы пользователя. - **Сервисы.** API, фоновые процессы, базы данных, хранилища, интеграции и панели управления. - **Поставка.** Библиотеки, пакеты, образы, CI/CD, registry и средства разработки. **Главная мысль.** Составляйте карту компонентов и потоков данных до выбора средств защиты. > **Слушателю.** Проверьте себя: назовите три приложения, которыми пользовались сегодня и которые не являются сайтом. Все они — тоже предмет AppSec. > > **Преподавателю.** Слайд снимает распространённое сужение темы до веба. Полезно спросить про мобильные приложения и настольные программы: студенты редко относят их к «безопасности приложений». Основание: вычищенная стенограмма, §§ 3.1, 4.1. ### 12. Как возникает риск Риск становится управляемым, когда его раскладывают на причинно-следственную цепочку. 01. **Актив.** Данные, деньги, репутация, непрерывность процесса, интеллектуальная собственность. 02. **Угроза.** Нежелательное событие и возможный путь его реализации. 03. **Уязвимость.** Недостаток проектирования, кода, конфигурации или процесса. 04. **Риск.** Вероятность и последствия для конкретного актива и организации. **Главная мысль.** Мера защиты должна уменьшать вероятность, последствия или оба параметра. > **Слушателю.** Возьмите любую задачу из своего курса и разложите её по четырём клеткам. Если клетка «актив» пустая — задача учит нажимать кнопки, а не думать о безопасности. > > **Преподавателю.** Группа почти всегда начинает с уязвимости: это самая заметная клетка. Разворачивайте обсуждение назад, к активу — там видно, почему одна уязвимость в двух системах стоит по-разному. Основание: вычищенная стенограмма, § 3.1. ### 13. Что именно мы защищаем: CIA Последствия удобнее обсуждать через конфиденциальность, целостность и доступность. - **Конфиденциальность.** Кто может узнать данные? Пример: чтение чужого документа или секрета. - **Целостность.** Кто и как может изменить данные? Пример: цена, роль, заказ или бизнес-статус. - **Доступность.** Может ли законный пользователь получить услугу вовремя? **Главная мысль.** В сценарии угрозы фиксируйте актив, нарушаемое свойство и проверяемый контроль. > **Слушателю.** Для каждой найденной проблемы называйте нарушаемое свойство. Это одно слово, но оно сразу задаёт и приоритет, и способ проверки. > > **Преподавателю.** Удобное упражнение на две минуты: назвать три инцидента из новостей и определить, какое свойство было нарушено в каждом. Часто оказывается, что сразу два. Основание: вычищенная стенограмма, § 3.2. ### 14. Идентификация, аутентификация, авторизация Успешный вход не означает право выполнить любое действие. - **Идентификация.** Субъект сообщает, кем он представляется. - **Аутентификация.** Система проверяет доказательство владения учётными данными или фактором. - **Авторизация.** Сервер решает, разрешено ли действие над конкретным объектом в этом контексте. **Главная мысль.** Проверка «субъект → действие → объект → контекст» выполняется на сервере для каждого запроса. > **Слушателю.** Три слова, которые чаще всего путают. Разница в вопросах: «кто ты», «докажи», «а это тебе можно». Третий вопрос задаётся при каждом запросе, а не один раз при входе. > > **Преподавателю.** Не идите дальше, пока группа не развела эти три понятия. Без этого категория A01 останется набором слов: она вся про третий вопрос, а не про первые два. Основание: вычищенная стенограмма, § 3.3. ### 15. Поверхность атаки — это все точки взаимодействия Не ограничивайтесь маршрутом API: у приложения есть входы, зависимости, роли, файлы, журналы и внешние каналы. - **Входы.** Формы, API, загрузка файлов, параметры, сообщения и административные интерфейсы. - **Переходы.** Браузер → API, API → БД, CI → registry, сервис → внешний ресурс. - **Полномочия.** Роли, сервисные учётные записи, токены, разрешения файлов и сети. **Главная мысль.** Каждая новая интеграция меняет поверхность атаки. > **Слушателю.** Поверхность атаки — это не только то, что видно в интерфейсе. Файлы, журналы, зависимости и учётные записи входят в неё наравне с формами. > > **Преподавателю.** Попросите группу назвать входы своей системы. Список обычно обрывается на формах и API — недостающие пункты и есть содержание следующих слайдов. Основание: вычищенная стенограмма, §§ 4.1–4.2. ### 16. Граница доверия — место для явного контроля На переходе между областями с разным уровнем доверия данные и команды нельзя считать безопасными по умолчанию. Проверить вход. **Шаг Проверить вход.** Формат, семантику, происхождение и полномочия. Ограничить передачу. **Шаг Ограничить передачу.** Передавать только нужные данные и минимально необходимые права. Зафиксировать действие. **Шаг Зафиксировать действие.** Обеспечить наблюдаемость без записи секретов в журнал. Сдержать ошибку. **Шаг Сдержать ошибку.** Заранее предусмотреть ограничение ущерба и безопасную реакцию. **Главная мысль.** Доверие не передаётся автоматически через интерфейс или сетевой вызов. > **Слушателю.** Ищите границу доверия в каждой задаче: браузер → сервер, сервис → база, сборка → реестр. Проверка ставится на границе, а не «где-нибудь внутри». > > **Преподавателю.** Понятие абстрактное, поэтому лучше рисовать. Одна стрелка на доске, пересекающая пунктир, объясняет больше, чем определение. Основание: вычищенная стенограмма, § 4.1. ### 17. Как построить карту атакуемой поверхности Карта превращает абстрактный разговор об угрозах в перечень объектов, сценариев и контролей. 01. **Бизнес-цель.** Определить защищаемые ценности. 02. **Поток данных.** Нарисовать поток и границы доверия. 03. **Компоненты.** Перечислить интерфейсы, файлы, зависимости и операции. 04. **Сценарии.** Сформулировать злоупотребления и ожидаемые контроли. **Главная мысль.** Для каждого пункта нужен проверяемый результат: тест, журнал, правило или архитектурное решение. > **Слушателю.** Это тот самый артефакт, который стоит унести с занятия. Заполненная карта превращает разговор про угрозы в конкретный перечень объектов и проверок. > > **Преподавателю.** Групповое упражнение: 10–12 минут на заполнение, 8–10 на разбор. Больше времени не давайте — группа уходит в детали одного компонента и теряет картину целиком. Основание: вычищенная стенограмма, § 4.2. --- ## 02 · A01–A03 — OWASP Top 10:2025 — доступ, конфигурация, поставка Основание: вычищенная стенограмма, §§ 5–9. ### 18. OWASP — общий язык для разговора о рисках OWASP Top 10 помогает структурировать классы проблем, но не заменяет модель угроз и требования конкретной организации. - **Top 10.** Ориентир для первичного разговора о наиболее значимых классах рисков. - **ASVS и WSTG.** Источники проверяемых требований и подходов к тестированию. - **Модель угроз.** Связывает общие категории с вашим активом, архитектурой и сценариями злоупотребления. **Главная мысль.** Категория — это начало анализа, а не готовый диагноз. > **Слушателю.** OWASP даёт общий язык, а не список задач к исполнению. Год редакции — часть названия: категории меняются между выпусками. > > **Преподавателю.** Отдельно проговорите, что классификация не заменяет моделирование угроз конкретной системы. Иначе студенты начинают «проверять по списку» вместо того, чтобы думать. Основание: вычищенная стенограмма, § 5. ### 19. A01:2025 — нарушение контроля доступа Проблема возникает, когда пользователь получает объект или выполняет действие вне своих полномочий. - **Горизонтальное повышение прав.** Доступ к объекту другого пользователя при подмене идентификатора. - **Вертикальное повышение прав.** Обычный пользователь выполняет административное действие. - **Скрытый маршрут.** Функция остаётся доступной, хотя ссылка или кнопка скрыта в интерфейсе. **Главная мысль.** UI не является границей безопасности: решение принимает сервер. > **Слушателю.** Самая распространённая категория. Признак в учебной задаче — идентификатор в адресе, который можно поменять руками и получить чужой объект. > > **Преподавателю.** Демонстрация занимает тридцать секунд и производит впечатление. Сразу за ней задавайте вопрос про исправление, иначе останется только впечатление. Основание: вычищенная стенограмма, § 6. ### 20. A01: проверка доступа должна быть системной Защита строится вокруг явной политики и проверки конкретного ресурса. Deny by default. **Шаг Deny by default.** Доступ разрешается только явным правилом. Централизация. **Шаг Централизация.** Политика авторизации не дублируется в клиентских экранах. Проверка объекта. **Шаг Проверка объекта.** Сервер сопоставляет субъекта, действие, объект и контекст. Негативные тесты. **Шаг Негативные тесты.** Тестируются попытки доступа к чужим объектам и административным действиям. **Главная мысль.** Скрыть кнопку — не значит запретить действие. > **Слушателю.** Проверка «мой ли это объект» пишется один раз в общем слое, а не копируется в каждый обработчик. Скопированная проверка рано или поздно будет забыта. > > **Преподавателю.** Хороший переход к разговору о тестах: попросите сформулировать отрицательный тест словами, до всякого кода. Основание: вычищенная стенограмма, § 6. ### 21. A02:2025 — небезопасная конфигурация Излишние возможности и подробная диагностика часто становятся частью пути атаки. - **Избыточная экспозиция.** Устаревшие endpoint’ы, debug-режимы, стандартные учётные записи, открытые сервисы. - **Информативные ошибки.** Пути к файлам, версии, стек вызовов и внутренние URL помогают атакующему. - **Неверные настройки.** Ошибки TLS, CORS, прав файлов, сетевой экспозиции и заголовков. **Главная мысль.** «Никто не знает URL» — не контроль безопасности. > **Слушателю.** Конфигурация — это часть продукта. Забытый отладочный режим и подробное сообщение об ошибке работают на злоумышленника не хуже уязвимости в коде. > > **Преподавателю.** Наглядный приём — показать разницу между информативной ошибкой для разработчика и нейтральной для пользователя, и спросить, где должна быть каждая. Основание: вычищенная стенограмма, § 7. ### 22. A02: конфигурация — часть защищаемого продукта Снижение риска требует повторяемых проверок, а не ручной надежды на корректную среду. Минимизировать. **Шаг Минимизировать.** Отключать неиспользуемые функции, компоненты и учётные записи. Разделять среды. **Шаг Разделять среды.** Не переносить dev/test-настройки в production. Проверять автоматически. **Шаг Проверять автоматически.** Использовать IaC, ревью и проверки конфигурации. Безопасно сообщать об ошибке. **Шаг Безопасно сообщать об ошибке.** Пользователю — нейтральное сообщение, деталям — защищённый журнал. **Главная мысль.** Конфигурация должна проходить такой же контроль изменений, как код. > **Слушателю.** Скрытый адрес не является защитой. «О нём никто не знает» перестаёт работать в момент первого сканирования. > > **Преподавателю.** Здесь удобно ввести понятие инфраструктуры как кода: конфигурация, которую можно прочитать и проверить, отличается от той, которую кто-то однажды настроил руками. Основание: вычищенная стенограмма, § 7. ### 23. A03:2025 — сбои в цепочке поставки ПО Современное приложение состоит не только из собственного кода: риск живёт в зависимостях, сборке и артефактах. - **Компоненты.** Библиотеки, пакеты, плагины, образы и внешние сервисы. - **Конвейер.** CI/CD, registry, секреты, подписи, разрешения и lifecycle-скрипты. - **Происхождение.** Кто, как и из какого источника собрал и доставил артефакт. **Главная мысль.** Неизвестная зависимость — это неизвестная часть поверхности атаки. > **Слушателю.** Чужой код становится вашим кодом в момент подключения зависимости. Его уязвимость — тоже ваша. > > **Преподавателю.** Категорию, которую группа почти никогда не называет сама при составлении карты. Свяжите её с упражнением: это лучшая иллюстрация того, зачем карта нужна. Основание: вычищенная стенограмма, § 8. ### 24. A03: делайте поставку проверяемой Контроль состава и происхождения позволяет быстрее принимать решения об обновлении и исключениях. Инвентаризировать. **Шаг Инвентаризировать.** Вести SBOM и применять SCA для анализа состава. Фиксировать. **Шаг Фиксировать.** Использовать lockfile, проверку хешей и доверенные источники. Подтверждать происхождение. **Шаг Подтверждать происхождение.** Строить воспроизводимые сборки, подписывать артефакты, хранить provenance. Ограничивать CI/CD. **Шаг Ограничивать CI/CD.** Минимизировать полномочия и доступ к секретам. **Главная мысль.** Обновление — это управляемое изменение, а не автоматическое благо. > **Слушателю.** Зафиксированная версия, опись состава и подпись артефакта — три вещи, которые превращают «мы что-то собрали» в воспроизводимую поставку. > > **Преподавателю.** Полезно показать реальный lockfile и реальный отчёт анализа состава: абстрактное описание здесь работает заметно хуже. Основание: вычищенная стенограмма, § 8. ### 25. ЛР 1–3: отчёт — это цепочка доказательств Флаг или снимок экрана сами по себе не объясняют, что именно было подтверждено и как это исправить. Среда и объект. **Шаг Среда и объект.** Что проверялось и в какой разрешённой учебной среде. Наблюдение. **Шаг Наблюдение.** Какой ответ или результат подтверждает проблему. Первопричина. **Шаг Первопричина.** Какой недостаток проектирования, кода или конфигурации её создал. Исправление и проверка. **Шаг Исправление и проверка.** Какая мера устраняет причину и каким тестом это подтверждается. **Главная мысль.** Ценность практики — в объяснении причины и проверяемой профилактике. > **Слушателю.** Отчёт — это не протокол ваших действий, а цепочка «наблюдение → причина → последствие → исправление → проверка». Только она оценивается. > > **Преподавателю.** Раздайте форму отчёта вместе с заданием, а не после него. Иначе первый блок работ придёт в виде набора скриншотов. Основание: вычищенная стенограмма, § 9. --- ## 03 · A04–A06 — OWASP Top 10:2025 — криптография, инъекции, проектирование Основание: вычищенная стенограмма, §§ 10–13. ### 26. A04–A06: от криптографии к инвариантам Второй блок объединяет ошибки защиты данных, небезопасную интерпретацию ввода и недостатки требований. - **A04 · криптографические сбои.** Защита данных, ключей, токенов, TLS и проверка подписи. - **A05 · инъекции.** Недоверенный ввод меняет смысл инструкции или выполняется в доверенном контексте. - **A06 · небезопасное проектирование.** Критичные защитные свойства не определены до реализации. **Главная мысль.** Уязвимости проявляются в коде, но часто возникают раньше — в решениях и ограничениях системы. > **Слушателю.** Вторая тройка категорий сложнее первой: ошибки здесь не видны по внешнему виду работающей системы. > > **Преподавателю.** Смена темпа: после практики группа устала. Три коротких блока с примерами «до и после» работают лучше, чем один длинный разбор. Основание: вычищенная стенограмма, §§ 10–12. ### 27. A04:2025 — криптографические сбои Криптография работает только как часть архитектуры: данные, ключи, протоколы, сроки и проверка должны быть согласованы. - **Данные.** Классификация: что защищается при хранении и передаче. - **Ключи и токены.** Жизненный цикл, хранение, срок действия и отзыв. - **Протоколы.** TLS, проверка сертификатов, сессии и безопасное восстановление доступа. **Главная мысль.** Замена библиотеки не исправляет небезопасную модель использования. > **Слушателю.** Криптография ломается не алгоритмом, а его применением: не тот режим, не проверенная подпись, не тот срок действия. > > **Преподавателю.** Стоит явно сказать: самостоятельно реализовывать криптографические примитивы не нужно. Задача инженера — правильно настроить и правильно проверить. Основание: вычищенная стенограмма, § 10. ### 28. JWT: проверяющий обязан быть строгим JWT содержит заголовок, полезную нагрузку и подпись или криптографический тег в зависимости от выбранного профиля. Алгоритмы. **Шаг Алгоритмы.** Использовать allow-list допустимых алгоритмов. Подпись и ключ. **Шаг Подпись и ключ.** Проверять криптографическую защиту с корректным ключом. Claims. **Шаг Claims.** Валидировать iss, aud, exp, nbf и другие релевантные утверждения. Негативные тесты. **Шаг Негативные тесты.** Проверять изменение заголовка, claims, подписи и ключа. **Главная мысль.** Проблема возникает, когда уязвимый verifier принимает то, что не должен принимать. > **Слушателю.** Содержимое токена читается кем угодно — это не секрет. Ценность даёт только подпись и её строгая проверка на сервере. > > **Преподавателю.** Показательный момент: декодировать токен на глазах у группы. После этого утверждение «в токене лежит роль, значит всё в порядке» больше не звучит. Основание: вычищенная стенограмма, § 10. ### 29. A05:2025 — инъекции меняют смысл инструкции Корень проблемы не в «опасных символах», а в смешении недоверенных данных и управляющей конструкции. - **SQL injection.** Ввод меняет структуру SQL-команды. - **XSS.** Внедрённый сценарий выполняется в доверенном контексте браузера. - **Command injection.** Ввод попадает в интерпретатор команд или системный процесс. **Главная мысль.** Отделяйте данные от кода и выбирайте безопасные API для конкретного контекста. > **Слушателю.** Инъекция — это когда данные начинают читаться как команда. Один принцип объясняет и SQL, и XSS, и выполнение команд. > > **Преподавателю.** Держите один пример через все виды инъекций. Разные примеры для каждого вида создают ощущение, что это три несвязанные темы. Основание: вычищенная стенограмма, § 11. ### 30. SQL injection: разделяйте код запроса и данные Защита строится на параметризации и ограничении полномочий, а не на поиске отдельных символов. Параметризация. **Шаг Параметризация.** Использовать подготовленные выражения или безопасный query builder. Минимальные права БД. **Шаг Минимальные права БД.** Учётная запись приложения не должна иметь лишних привилегий. Серверные ограничения. **Шаг Серверные ограничения.** Проверять бизнес-правила и схему данных на стороне сервера. Регрессия. **Шаг Регрессия.** Добавлять негативные тесты и правило ревью против конкатенации запросов. **Главная мысль.** Ввод должен быть значением, а не частью синтаксиса команды. > **Слушателю.** Параметризованный запрос работает не потому, что «экранирует кавычки», а потому что текст запроса и данные передаются раздельно. > > **Преподавателю.** Различение «фильтрация ввода» и «разделение кода и данных» — ключевой момент блока. Первое лечит симптом, второе — причину. Основание: вычищенная стенограмма, § 11.1. ### 31. XSS: контекст вывода определяет защиту Выполнение внедрённого сценария возможно, когда приложение обрабатывает содержимое как доверенный код или HTML. - **Вывод.** Применять контекстно-зависимое экранирование и безопасные шаблоны. - **DOM.** Избегать небезопасных вставок HTML; использовать безопасные DOM API. - **Дополнительный рубеж.** CSP усиливает защиту, но не заменяет корректную обработку данных. **Главная мысль.** XSS не сводится к cookie: главное последствие — код действует от имени жертвы в доверенном контексте. > **Слушателю.** Защита от XSS зависит от того, куда попадает значение: в текст, в атрибут, в адрес или в сценарий. Универсального экранирования нет. > > **Преподавателю.** Понятия источника и приёмника вводятся именно здесь. Дальше они пригодятся при разговоре про статический анализ. Основание: вычищенная стенограмма, § 11.2. ### 32. CSRF, redirect и команды: три разных контекста Похожая внешняя симптоматика не означает одинаковую первопричину или исправление. - **CSRF.** Анти-CSRF-токен, SameSite, проверка Origin/Referer как дополнительный сигнал. - **Open redirect.** Серверная allow-list направлений или внутренние относительные маршруты. - **Command injection.** Не использовать shell; применять безопасные API с аргументами и allow-list значений. **Главная мысль.** Сначала определите интерпретатор и границу доверия, затем выбирайте контроль. > **Слушателю.** CSRF, открытый редирект и выполнение команд похожи по звучанию, но защищаются по-разному. Не смешивайте их в одну меру. > > **Преподавателю.** Быстрый способ проверить понимание: дать три сценария вперемешку и попросить назвать, какой рубеж защиты нужен в каждом. Основание: вычищенная стенограмма, § 11.3. ### 33. A06:2025 — небезопасное проектирование Если защитное свойство не сформулировано до реализации, его нельзя надёжно «добавить» одним фильтром или WAF. - **Злоупотребления.** Сценарии обхода должны быть видны в требованиях и модели угроз. - **Инварианты.** Роли, лимиты, антифрод, сегментация и условия безопасного отказа. - **Состояние.** Критичные правила учитывают объект, действие, контекст и переход состояния. **Главная мысль.** UI-валидация не заменяет доменную логику, ограничения базы данных и серверные проверки. > **Слушателю.** Небезопасное проектирование нельзя найти сканером: дефект в самой модели, а не в строке кода. > > **Преподавателю.** Лучший заход — через бизнес-сценарий злоупотребления, а не через технику. «Как получить товар бесплатно, ничего не ломая» работает безотказно. Основание: вычищенная стенограмма, § 12. ### 34. Бизнес-инварианты закрепляются на сервере Пример с корзиной или платежом показывает, почему клиент не должен определять критичный результат. Количество. **Шаг Количество.** Значение должно соответствовать допустимому диапазону. Сумма. **Шаг Сумма.** Рассчитывается на сервере из доверенных данных и не становится отрицательной. Деньги. **Шаг Деньги.** Используется подходящий точный тип, а не двоичная плавающая точка. Операции. **Шаг Операции.** Скидки, возвраты и права проверяются атомарно с учётом состояния. **Главная мысль.** Инвариант должен быть выражен в требованиях, реализации и негативных тестах. > **Слушателю.** Правило, записанное только в интерфейсе, правилом не является. Запрос можно отправить в обход интерфейса. > > **Преподавателю.** Свяжите с ограничениями базы данных: инвариант, продублированный на уровне схемы, переживёт любую переделку кода. Основание: вычищенная стенограмма, § 12. ### 35. ЛР 4–6: фиксируем причину, а не «трюк» Отчёт связывает наблюдение с недостатком и проверяемым исправлением, а не превращает практику в набор payload’ов. Наблюдение. **Шаг Наблюдение.** Зафиксировать проверяемый результат в учебной среде. Причина. **Шаг Причина.** Объяснить уязвимый verifier, смешение данных и кода или нарушенный инвариант. Последствия. **Шаг Последствия.** Описать реалистичный ущерб для пользователя, актива и процесса. Профилактика. **Шаг Профилактика.** Сформулировать серверную меру и регрессионную проверку. **Главная мысль.** Качественное исправление проверяется тестом, правилом CI/CD, журналом или ревью. > **Слушателю.** Цель второго блока — не найти больше, а объяснить точнее. Одна разобранная до причины задача ценнее пяти пройденных. > > **Преподавателю.** Разбор в группе — обязательная часть, а не остаток времени. Именно на нём результат превращается в понимание. Основание: вычищенная стенограмма, § 13. --- ## 04 · ИИ — Безопасность ИИ и образовательная практика Основание: вычищенная стенограмма, §§ 14–15. ### 36. ИИ + безопасность + обучение Безопасность системы с моделью не сводится к одному prompt: важны данные, политики, инструменты, память, интеграции и люди. - **Модель.** Генерирует ответ, но не становится самостоятельной границей безопасности. - **Система.** Оркестрация, RAG, инструменты, память, интерфейсы и учётные записи. - **Процесс.** Проверка источников, контроль изменений, наблюдаемость и решение человека. **Главная мысль.** Оценивать нужно архитектуру целиком, а не только качество ответа модели. > **Слушателю.** Базовые классы уязвимостей сохраняются, но модельные и агентные системы добавляют специфические риски. Поэтому проверяйте и классические контроли AppSec, и актуальные таксономии безопасности ИИ. > > **Преподавателю.** Блок хорошо ставить в конец дня: он собирает пройденное и снимает возражение «ИИ — отдельная тема, к нам не относится». Основание: вычищенная стенограмма, § 14. ### 37. OWASP Top 10 for LLM Applications 2025 Фиксируйте редакцию таксономии и не смешивайте её с отдельным списком Agentic Applications 2026. - **LLM01:2025–LLM03:2025.** Prompt Injection; Sensitive Information Disclosure; Supply Chain. - **LLM04:2025–LLM07:2025.** Data and Model Poisoning; Improper Output Handling; Excessive Agency; System Prompt Leakage. - **LLM08:2025–LLM10:2025.** Vector and Embedding Weaknesses; Misinformation; Unbounded Consumption. **Главная мысль.** Для проверяемых требований используйте AISVS 1.0; список рисков не является проверочным стандартом. > **Слушателю.** Главный сдвиг: недоверенным становится не только то, что напечатал пользователь, но и текст внутри документа или ответа стороннего сервиса. > > **Преподавателю.** Предложите сопоставить три риска систем с моделями с A01–A06, а затем назвать остаточные риски. Так видны и переносимость базы, и границы сопоставления. Основание: вычищенная стенограмма, § 14.1. ### 38. Цепочка поставки ИИ — часть модели доверия Модель, набор данных, адаптеры, контейнер, registry и среда развёртывания имеют собственное происхождение и риски. Инвентаризировать. **Шаг Инвентаризировать.** Знать состав модели, данных, библиотек, образов и подключённых источников. Проверять происхождение. **Шаг Проверять происхождение.** Использовать доверенные источники, хеши, подписи и воспроизводимые процессы. Ограничивать обновления. **Шаг Ограничивать обновления.** Не подключать новые модели, данные и инструменты без оценки изменений. Наблюдать. **Шаг Наблюдать.** Фиксировать, что именно было использовано для конкретного результата. **Главная мысль.** Новая модель или датасет — такое же изменение безопасности, как новая библиотека. > **Слушателю.** Модель, набор данных и векторная база — тоже элементы цепочки поставки. К ним применимы те же вопросы о происхождении. > > **Преподавателю.** Прямая отсылка к A03. Повторное появление одной и той же схемы в новом контексте хорошо закрепляет материал. Основание: вычищенная стенограмма, §§ 14.1–14.2. ### 39. Agentic application: модель действует через инструменты Риск возрастает, когда недостоверный ввод влияет на выбор инструмента, его параметры или права исполнения. - **Цель и инструкции.** Определяют задачу и допустимый контекст. - **Оркестрация.** Выбирает последовательность шагов и обрабатывает результаты. - **Инструменты.** Выполняют запросы, меняют данные, вызывают сервисы или используют учётные записи. **Главная мысль.** Автономность определяется не названием «агент», а доступными действиями и контролями. > **Слушателю.** Как только модель получает возможность действовать, а не только отвечать, вопрос смещается с текста ответа на права инструмента. > > **Преподавателю.** Уточните различие между «ассистент отвечает» и «агент делает». Часть группы использует эти слова как синонимы. Основание: вычищенная стенограмма, § 14.2. ### 40. Контроль инструментов: наименьшие привилегии Модель не должна получать неограниченное право действовать от имени человека или системы. Изолировать. **Шаг Изолировать.** Разделять среды и использовать отдельные учётные записи. Разрешать явно. **Шаг Разрешать явно.** Задавать allow-list операций, параметров и источников данных. Подтверждать человеком. **Шаг Подтверждать человеком.** Требовать явного решения для необратимых и финансово значимых действий. Трассировать. **Шаг Трассировать.** Журналировать действия, вводить лимиты и независимо проверять результат. **Главная мысль.** Надёжный агент ограничен так же строго, как любой другой привилегированный сервис. > **Слушателю.** Права выдаются инструменту, а не модели. Инструмент вида «выполни любую команду» ограничить невозможно в принципе. > > **Преподавателю.** Тот же принцип наименьших привилегий из блока A01. Проговорите это вслух — узнавание принципа важнее нового термина. Основание: вычищенная стенограмма, § 14.2. ### 41. Достоверность ответа требует отдельного контроля Правдоподобный текст не является доказательством: модель может ошибаться, опираться на устаревшие или противоречивые данные. - **Источник.** Показывать первоисточник, редакцию и дату проверки. - **Проверка.** Сопоставлять значимые утверждения с независимым источником или экспертом. - **Ограничение.** Не передавать модели право принимать необратимые решения без контроля. **Главная мысль.** RAG и fine-tuning помогают работать с контекстом, но не отменяют валидацию результата. > **Слушателю.** Уверенный тон не является признаком правильности. Если ответ влияет на решение, нужна внешняя проверка. > > **Преподавателю.** Переход к методической части: критерием оценки студенческой работы становится не текст, а способность объяснить причину устно. Основание: вычищенная стенограмма, §§ 14.1, 14.3. ### 42. ИИ в образовательной практике Генеративный ИИ полезен для пояснений, вариантов упражнений и обратной связи, если учащийся сохраняет ответственность за вывод. Пояснить. **Шаг Пояснить.** Использовать ИИ для разбора понятия и поиска альтернативных объяснений. Проверить. **Шаг Проверить.** Сверять факты, версии, лицензии и безопасность кода с источниками. Обосновать. **Шаг Обосновать.** Уметь объяснить решение и показать воспроизводимое доказательство. Оценить. **Шаг Оценить.** Фиксировать критерии качества, ограничения и происхождение материала. **Главная мысль.** Сгенерированный текст — черновик; учебный результат — проверенное и объяснённое знание. > **Слушателю.** Пользоваться моделью при подготовке работы допустимо. Недопустимо сдавать результат, который вы не можете объяснить. > > **Преподавателю.** Сформулируйте правило курса заранее и письменно. Обсуждение постфактум, на конкретной работе, всегда проходит хуже. Основание: вычищенная стенограмма, § 14.3. ### 43. Итог первого дня AppSec строится вокруг активов, границ доверия, архитектурных решений и доказуемых защитных свойств. - **Понимать.** Связывать категорию риска с активом, сценарием и последствиями. - **Проверять.** Искать первопричину и подтверждать исправление тестом или контролем. - **Продолжать.** Подготовить вопросы по A01–A06, карту поверхности атаки и точки SSDLC. **Главная мысль.** Практика ценна тогда, когда она превращается в воспроизводимый процесс безопасной разработки. > **Слушателю.** Соберите три вопроса, оставшиеся непонятными, — они пригодятся во второй день сильнее, чем конспект. > > **Преподавателю.** Собирайте на выходе не впечатления, а вопросы. Они задают план следующего занятия точнее любой анкеты. Основание: вычищенная стенограмма, § 15.