# Стенограмма дня 1: подробная редактированная версия

> **Назначение:** материал для самостоятельного изучения и подготовки занятий.
>
> **Дата:** 11 августа 2026 года.
>
> **Программа:** АО «Лаборатория Касперского» — «Образовательная лаборатория Kaspersky Academy | Безопасность приложений».
>
> Временные метки локальны для соответствующих фрагментов и в новом фрагменте могут начинаться заново.
>
> Метка `[неразборчиво]` сохранена там, где содержание нельзя восстановить уверенно.

## Фрагмент 1

### 00:00:00–00:02:43 — Начало обсуждения: злоумышленник и компьютерная атака

**Ведущий.** Дискуссия начинается уже в ходе обсуждения. Давайте начнём с базового понятия: кто такой злоумышленник?

**Участник.** Как минимум это человек, который хочет причинить вред. Он может испортить инфраструктуру, захватить данные, нарушить прохождение или проксирование трафика.

**Ведущий.** Да. Если поднимаете руку и включаетесь в обсуждение, пожалуйста, сначала представьтесь.

**Участник.** [Представляется.]

**Ведущий.** Хорошо. Тогда следующий вопрос: что такое компьютерная атака?

**Ведущий.** Все знают ответ? Кто готов ответить?

**Участник.** [Короткий ответ не распознан.]

**Ведущий.** При обсуждении были названы свойства, на которые может быть направлено воздействие: **целостность** [термин восстановлен по контексту], **доступность** и **конфиденциальность** информации.

**Ведущий.** Спасибо. Теперь важно отличить атаку от угрозы. Но прежде в определении компьютерной атаки нельзя пропустить ключевое слово — «компьютерная». Атак бывает много; здесь речь именно о воздействии, которое реализуется с помощью компьютерных, цифровых средств и в информационной среде, а не, например, о физическом проникновении в помещение.

**Участник.** То есть нужно разделить физическую среду и информационное пространство: проникновение к данным, дистанционное взаимодействие и тому подобное.

**Ведущий.** Да, именно это и нужно учитывать. Перейдём к угрозе.

**Ведущий.** Атака — это процесс, развёрнутый во времени. Угроза потенциальна: неизвестно, будет ли она реализована. Когда мы оцениваем вероятность реализации и возможный ущерб, мы уже говорим о риске.

### 00:02:44–00:04:06 — Угроза, риск и последствия воздействия

**Ведущий.** Давайте сформулируем это в привычной логике. Риск связан с вероятностью причинения ущерба вследствие воздействия на информацию или информационные ресурсы. В первичной дискуссии формулировка несколько раз уточнялась: существенны и вероятность, и последствия воздействия.

**Ведущий.** Важно не смешивать понятия. Угроза описывает потенциальную возможность нежелательного события. Атака — действие или последовательность действий. Риск нужен для оценки: насколько вероятна реализация и насколько существенным будет ущерб.

**Ведущий.** Далее разберём сразу три взаимосвязанных понятия. Они постоянно встречаются в приложениях: при входе, работе с логином и паролем, получении обычного или привилегированного доступа.

### 00:04:07–00:06:43 — Идентификация, аутентификация и авторизация

**Ведущий.** Чем отличаются идентификация, аутентификация и авторизация?

**Участник.** Это три связанных понятия. Если совсем кратко:

1. идентификация отвечает на вопрос: «Кто ты?»;
2. аутентификация: «Это действительно ты? Докажи»;
3. авторизация: «Что тебе разрешено делать в системе?»

**Ведущий.** Верно. Развернём:

* **Идентификация** — назначение или предъявление уникального идентификатора субъекта взаимодействия.
* **Аутентификация** — проверка того, что субъект действительно связан с предъявленным идентификатором.
* **Авторизация** — назначение и проверка прав доступа владельца идентификатора к функциям и ресурсам.

**Ведущий.** Уточним один практический вопрос. Кто присваивает идентификатор и к какому процессу он относится: к пользователю, который входит в систему, или к администратору, создающему сущность в системе?

**Участник.** Это может быть не только человек. Например, сервисная учётная запись.

**Ведущий.** Да. Идентификатор может относиться к пользователю, сервису или иной учётной сущности. Когда администратор заводит пользователя в системе, он создаёт эту сущность и присваивает ей идентификатор. Дальше уже субъект использует идентификатор во взаимодействии с системой.

**Участник.** То есть создать такую сущность можно только при наличии соответствующих прав?

**Ведущий.** Да, если у субъекта есть такие права.

### 00:06:44–00:10:31 — Цели безопасности и допущения о системе

**Ведущий.** Перейдём к целям безопасности и допущениям. Эти элементы связаны между собой.

**Ведущий.** Главная цель информационной безопасности состоит в том, чтобы система удовлетворяла предъявляемым к ней требованиям безопасности. Но требования у разных систем могут существенно различаться, а в отдельных случаях вступать в противоречие. Для одних ресурсов критична доступность, для других — закрытость информации. Поэтому нельзя дать единственный набор целей, одинаково подходящий для любой системы: он определяется тем, что именно мы защищаем и какие свойства для этого ресурса важны.

**Участник.** «Допущение» — это нормативный термин? Я не встречал его в нормативных документах по безопасности.

**Ведущий.** [Начало ответа распознано не полностью.] Здесь под допущением понимается не обязательно формально закреплённый термин, а рабочая гипотеза о системе: нечто предполагаемое, но пока не подтверждённое в полном объёме.

**Ведущий.** Допущение может относиться к входным данным о системе, к типовым настройкам или к предполагаемой архитектуре. Например, при первичном изучении мы можем исходить из того, что в рабочей среде есть один веб-сервер и одно приложение. Это не установленный факт, а рабочая гипотеза, которую нужно проверять.

**Ведущий.** Такие сведения особенно важны при исследовании экосистемы или при построении модели угроз. Мы можем не знать архитектуру точно, но фиксируем предположение и затем либо подтверждаем, либо опровергаем его. Именно потому оно и называется допущением.

**Ведущий.** Коллега на вебинаре рассказывала характерную ситуацию. Заказчик поручает построить модель угроз. Специалисты приходят, спрашивают: «Какая у вас архитектура?» В ответ слышат: «Идите и узнавайте». После этого команда должна самостоятельно собирать сведения и восстанавливать картину системы.

**Ведущий.** На практике бывает, что система уже работает, а полная документация появляется только тогда, когда к ней приходит специалист по безопасности и начинает подробно описывать её состав. Разработчик, который изначально всё знал, мог уже уйти из организации; у команды остаётся работающий продукт, но не остаётся цельного описания архитектуры.

**Ведущий.** Базовые определения мы разобрали достаточно подробно. Не будем на них задерживаться и перейдём к теоретической части: почему безопасность приложений сейчас критична.

### 00:10:32–00:13:27 — Почему безопасность приложений важна

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

**Ведущий.** Для человека последствия очевидны: неприятно, если с банковского счёта переведут деньги неизвестному получателю; если посторонний получит сведения о здоровье; если станет доступной переписка, которую пользователь разумно считает приватной.

**Ведущий.** Современная жизнь устроена так, что большое количество персональных и иных чувствительных данных хранится в системах организаций. О них знаем не только мы как пользователи, но и компании, которые предоставляют сервисы.

**Ведущий.** Как только система подключена к сети, она становится участником сетевого взаимодействия. Для публичного сервиса это означает наличие доступной из сети точки взаимодействия; для любой связанной системы — возможность внешнего или смежного воздействия. Поэтому данные нуждаются в защите.

**Ведущий.** За этой защитой стоят компании, организации и разработчики приложений. Защита только на уровне сети не всегда достаточна — к этому вернёмся ниже. Защита на уровне приложения тоже является частью общей защиты, и это одна из ключевых причин, по которым мы занимаемся безопасностью приложений.

**Ведущий.** Стопроцентно безопасных приложений не бывает. Возможность ошибки присутствует даже в очень хорошо защищённых системах, потому что системы делают люди. Вопрос обычно связан с объёмом усилий, стоимостью защиты и стоимостью реализации атаки.

### 00:13:28–00:16:03 — Ошибки разработки, экономика атаки и удалённое воздействие

**Ведущий.** Ошибок при разработке может быть очень много. Современное распространение систем искусственного интеллекта и агентов для разработки и тестирования также показывает, сколько проблем может возникать в приложениях и в открытом программном обеспечении. По оценке ведущего, число таких проблем будет расти.

**Ведущий.** Для атакующего разные варианты действий имеют разную стоимость. Он выбирает не только технически возможный, но и экономически целесообразный путь.

**Ведущий.** Пример: можно пытаться перебором восстановить защищённый пароль, но это способно занять очень много времени. Иногда проще и выгоднее искать иной путь в систему: получить учётные данные, воспользоваться ошибкой в логике или начать с менее защищённого компонента.

**Участник.** Удалённые атаки, как правило, опаснее, потому что у них более широкий потенциальный охват?

**Ведущий.** Да. Физический доступ в определённой степени можно контролировать. Удалённое воздействие часто затрагивает большее число потенциальных целей. При этом удалённая атака нередко сложнее: у атакующего нет исходного доступа к системе.

**Ведущий.** Поэтому распространённая последовательность выглядит так: сначала атакующий пытается получить минимальный доступ — например, войти как обычный пользователь или добыть чьи-то учётные данные. Затем он развивается внутри системы и продвигается по её структуре. Последствия такой компрометации мы уже обсудили.

### 00:16:04–00:19:41 — Последствия для организации: данные, деньги и репутация

**Ведущий.** Для компаний, разрабатывающих программное обеспечение, важны последствия обработки персональных и платёжных данных. Работа с персональными данными регулируется; нарушение может привести к финансовым потерям. Платёжные данные также регулируются, причём требования могут различаться по юрисдикциям, но последствия всё равно часто выражаются в деньгах.

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

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

**Участник.** Если пользователь сам сделал чат или ссылку публичными, то индексирование в поиске может быть ожидаемым. Почему в таком случае претензия предъявляется сервису?

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

**Участник.** То есть проблема может быть в том, что сервис допускает совместный доступ по ссылке, но не объясняет пользователю, что эта ссылка способна попасть в индекс?

**Ведущий.** Вероятно, речь именно об этом: о пользовательских ожиданиях и настройках доступа. [Часть последующей реплики о связи доступа с адресом электронной почты неразборчива.]

**Ведущий.** Полезно проверить себя: сервисы, связанные с контролем утечек или с менеджерами паролей, могут показать, как много раз персональные данные, адреса электронной почты, пароли или иные сведения уже оказывались в утечках. Это влияет и на пользователей, и на финансовые результаты компаний.

### 00:19:42–00:21:28 — Безопасность приложений как процесс

**Ведущий.** От рисков переходим к тому, как с ними работать. Компании вкладываются в безопасность, чтобы снижать потери, сохранять доверие и в конечном счёте не терять деньги.

**Ведущий.** Безопасность приложений — комплексный процесс. В него входит много этапов; подробнее его состав будет разбираться во второй день обучения. В общем виде речь идёт о безопасной разработке, обновлении, тестировании и поддержании безопасности приложения.

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

**Ведущий.** Этот процесс начинается с базового обучения разработчиков и продолжается до расследования инцидентов, возникающих в уже работающих приложениях. Детальная декомпозиция процесса будет позже.

### 00:21:29–00:25:02 — Что такое приложение: упрощённая классификация ПО

**Ведущий.** Теперь попробуем самым простым образом классифицировать приложения. Начнём с общей схемы: есть аппаратное обеспечение, системное программное обеспечение и прикладное программное обеспечение.

**Ведущий.** Аппаратное обеспечение — это «железо»: физические компоненты, на которых всё работает.

**Ведущий.** Системное программное обеспечение обеспечивает взаимодействие с аппаратной частью: с памятью, процессором, накопителями и другими ресурсами. В этой части упоминаются операционные системы, графический интерфейс, драйверы, системные утилиты и программные средства, необходимые для работы с ресурсами системы.

**Ведущий.** В рамках этой упрощённой схемы к системным и инфраструктурным средствам отнесены также инструменты, необходимые для разработки и получения работающей программы: компиляторы и другие средства, связанные с языками программирования.

**Ведущий.** Прикладное программное обеспечение — то, чем мы пользуемся в повседневных задачах. Сюда относятся веб-сайты, мобильные приложения, текстовые редакторы, браузеры, почтовые клиенты, медиаплееры и другие программы, которые помогают решать прикладную задачу пользователя.

**Ведущий.** Прикладное ПО можно условно разделить на ПО общего назначения и специального назначения. К общему относятся, например, офисные приложения. К специальному — системы бронирования, интернет-магазины, системы учёта посещаемости, бухгалтерские и отчётные системы; перечень таких решений практически не ограничен.

**Ведущий.** Следующий слайд повторяет эту классификацию. Далее разделим прикладные приложения по технологии реализации и способу использования.

### 00:25:03–00:28:00 — Веб-, настольные и мобильные приложения

**Ведущий.** Начнём с веб-приложений. Как вы знаете, они работают в браузере. Для пользователя обычно нужен браузер; в этом смысле веб-приложение может быть доступно с разных операционных систем.

**Ведущий.** Для публичного веб-приложения обычно необходимо подключение к интернету. Если это внутреннее корпоративное приложение, внешний интернет-доступ может быть не нужен и даже нежелателен, особенно при обработке конфиденциальных корпоративных данных или коммерческой тайны.

**Ведущий.** Веб-приложения относительно удобно масштабировать инфраструктурно: в зависимости от нагрузки можно добавлять или убирать серверы.

**Ведущий.** Настольные приложения, напротив, в большей степени зависят от платформы. Приложение, разработанное для Windows, как правило, не запускается на другой операционной системе без дополнительных средств совместимости. Аналогично мобильные приложения под Android или iOS имеют свою специфику и не являются обычными настольными программами.

**Ведущий.** Специфику различных типов приложений мы будем обсуждать далее. А сейчас поверхностно разберём архитектуру веб-приложения.

### 00:28:01–00:30:34 — Базовая архитектура веб-приложения

**Ведущий.** На высоком уровне веб-приложение использует клиент-серверную архитектуру. Есть клиент: компьютер, мобильное устройство или другой потребитель сервиса. Он обращается по сети к публичной точке доступа приложения, в типичном случае — по HTTP.

**Ведущий.** Публичная точка доступа и её инфраструктура направляют запросы дальше. В упрощённой схеме эта роль показана как балансировка нагрузки: по правилам инфраструктуры выбирается сервер, который обработает запрос.

**Ведущий.** Иллюстративный пример: доменному имени соответствует IP-адрес. Когда пользователь запрашивает домен, инфраструктура определяет, куда направить запрос. В зависимости от имени, пути URL или иных правил разные части приложения могут обслуживаться разными серверами.

**Ведущий.** Например, в иллюстрации со службой «Яндекс» один путь мог бы обрабатываться одним сервером, а другой — другим. Это не описание конкретной инфраструктуры сервиса, а упрощённый пример маршрутизации запроса в веб-приложении.

**Ведущий.** В таком виде устроены многие продуктовые веб-приложения. Всем понятна эта схема? Спрашиваю, чтобы дальше можно было обсуждать безопасность веб-приложений на общей основе.

### 00:30:35–00:33:30 — Атаки на клиентскую часть

**Ведущий.** Перейдём к атакам на клиентскую часть. Существенная особенность таких атак в том, что пользователь нередко сам запускает цепочку действий: переходит по ссылке, открывает ресурс, скачивает файл или запускает предложенный код.

**Ведущий.** Вернёмся к схеме. Атаковать можно и клиентов, и серверы. Серверы обычно находятся в зоне внимания организации: у них есть публичные адреса, поэтому для них стараются вводить защитные меры, обрабатывать и валидировать входящие данные, проверять типы и формат значений в запросах, ограничивать нежелательное воздействие.

**Ведущий.** Клиентские устройства часто защищены хуже. На домашнем компьютере или устройстве может не быть даже базовой защиты. Переход на вредоносный ресурс может привести к выполнению вредоносного кода на устройстве пользователя.

**Ведущий.** Код может выполняться и в браузере. Например, внедрённый на сайт JavaScript способен выполнять операции с данными, доступными браузеру. Если же пользователь скачал и запустил стороннее программное обеспечение, набор возможных действий атакующего становится шире: он может пытаться получить данные пользователя или добиться иного влияния на устройство.

**Ведущий.** Сервер при таких атаках может использоваться как внешне доверенная точка, как средство маскировки или как ранее скомпрометированный элемент цепочки. Фрагмент формулировке, в котором описывался этот механизм, частично неразборчив; достоверно сохраняется общий вывод: пользователь может не подозревать об атаке и получить вредоносное программное обеспечение через ресурс, которому доверяет.

**Ведущий.** Аналогичные риски есть не только у браузера. Уязвимость в клиентской программе может быть использована через внешнее приложение, почтовое сообщение, обновление или иной канал доставки. Последствие — доступ к данным на устройстве.

### 00:33:31–00:36:19 — Почему сетевой экран не заменяет защиту клиента

**Ведущий.** Почему сетевой экран сам по себе не спасает клиента? На схеме он может стоять перед балансировщиком нагрузки и ограничивать часть сетевых взаимодействий: отсекать нежелательные данные, вводить ограничения по IP-адресам или странам, разделять взаимодействие между серверами.

**Ведущий.** В более развитой архитектуре, основанной на принципах нулевого доверия, серверы сегментируются: между ними разрешаются только необходимые соединения. Если будет скомпрометирован один сервер, это снижает вероятность компрометации всей инфраструктуры.

**Ведущий.** Однако атака на клиент может происходить непосредственно на конечном устройстве пользователя — через браузер, электронную почту, скачанный файл или иной внешний ресурс. Сетевой экран, защищающий серверный периметр, не устраняет сам факт выполнения опасного действия на клиенте.

**Ведущий.** Мы уже обсудили последствия получения данных пользователя. Теперь кратко посмотрим на серверную сторону.

**Участник.** Речь больше о системах Linux и Windows, персональных компьютерах и ноутбуках? Это относится к клиентской истории?

**Ведущий.** Да, такие устройства могут выступать клиентами. Но уязвимости и ошибки обработки данных возможны и на серверной стороне.

### 00:36:20–00:38:39 — Уязвимости серверных служб и масштаб последствий

**Ведущий.** В качестве старого примера рассматривается уязвимость службы, доступной через порт `445`; название протокола не распознано надёжно `[возможно: SMB]`.

**Ведущий.** Смысл примера такой: ошибка в коде обработчика службы и в обработке внешних данных может позволить удалённому внешнему пользователю воздействовать на систему вплоть до выполнения кода. После обнаружения такой уязвимости поставщик выпускает исправление, которое нужно применить.

**Ведущий.** Это один из показательных случаев: ошибка разработки, ошибка кодирования или ошибка обработки внешних данных делают систему уязвимой и могут дать возможность эксплуатации.

**Ведущий.** Компрометация сервера часто интереснее атакующему, чем компрометация одного клиентского устройства. На сервере могут находиться данные многих пользователей, сведения десятков и сотен клиентов, корпоративная информация или коммерческая тайна. Поэтому последствия эксплуатации серверной уязвимости могут быть существенно масштабнее.

### 00:38:40–00:41:16 — OWASP и OWASP Top 10 (2025)

**Ведущий.** Далее поговорим о материалах OWASP. Это профессиональное сообщество специалистов по безопасности, которое разрабатывает проекты и практические материалы по безопасной разработке, типовым угрозам и способам защиты от них. В устной речи эти материалы иногда называются «стандартами», но далее речь идёт именно о ресурсах и проектах OWASP.

**Ведущий.** Проектов много. Ведущий отмечает, что в актуальной повестке OWASP заметное место занимает исследование безопасности систем искусственного интеллекта. Мы сделаем обзор ключевых проектов.

**Ведущий.** `OWASP Top 10` — перечень наиболее значимых рисков и категорий уязвимостей веб-приложений. Он периодически обновляется; в учебной программе используется версия **OWASP Top 10 (2025)**, а лабораторные работы следуют порядку от `A01` до `A10`.

**Ведущий.** Перечень составляется и уточняется на основе данных и вклада профессионального сообщества. В рамках двух дней мы будем подробно разбирать эти категории и выполнять лабораторные работы, чтобы технически понять, как проявляются уязвимости и угрозы.

### 00:41:17–00:43:53 — Мобильные риски и хранение учётных данных

**Ведущий.** Для мобильных приложений существует отдельный перечень рисков OWASP, релевантный Android и iOS. Список можно посмотреть на слайдах; сейчас разберём несколько примеров.

**Ведущий.** Один из примеров — некорректное обращение с учётными данными. У мобильного приложения обычно есть процесс входа: по номеру телефона, логину, адресу электронной почты или другому идентификатору. Проблема возникает, когда чувствительные данные приложения хранятся небезопасно, например просто в файлах на файловой системе устройства.

**Ведущий.** В таких файлах могут оказаться токены, ключи или адреса электронной почты. Если пользователь установит нежелательное приложение, если телефон попадёт в чужие руки или произойдёт другое нежелательное событие, эти данные могут быть извлечены.

**Ведущий.** Далее упоминается безопасность цепочки поставок: внешние библиотеки и open-source-компоненты, которые используются мобильным приложением. Также рассматриваются проблемы авторизации и аутентификации, проверки входных данных [слово распознано с искажением], а также передачи данных без шифрования.

### 00:43:54–00:45:49 — Материалы по тестированию и безопасной разработке

**Ведущий.** Следующий проект OWASP назван с сильным искажением. По описанию это подробное руководство для специалистов по тестированию безопасности и тестированию на проникновение: большой перечень того, что нужно проверять в разных подсистемах приложения, чтобы убедиться в корректности реализации защитных мер.

**Ведущий.** В начале такого руководства описывается, как тестирование безопасности встраивается в цикл разработки и как его применять. Затем приводятся конкретные проверки и направления анализа. Участникам предлагается ознакомиться с материалом самостоятельно.

**Ведущий.** Далее рассматриваются материалы для разработчиков: руководство по безопасной разработке и набор кратких практических рекомендаций. Названия и аббревиатуры искажены, поэтому здесь не фиксируются как достоверные.

**Ведущий.** Пример применения: разработчику нужно правильно реализовать авторизацию в приложении. Он обращается к соответствующему руководству или краткой рекомендации и получает перечень мер, которые нужно предусмотреть для этой функции, включая многофакторную аутентификацию там, где она уместна.

### 00:45:50–00:49:19 — Вопрос о стандартах безопасной разработки для языков программирования

**Участник.** У некоторых языков, в частности у C, существуют наборы требований и стандартов безопасной разработки: что нельзя принимать, куда нельзя сохранять данные, что нельзя передавать. Почему, когда мы говорим о лучших практиках, часто оказывается, что люди даже не читали эти документы? Участник приводит собственный опыт: пакет попадает в сообщество, проходит функциональные тесты, но это само по себе ничего не говорит о безопасности.

**Участник.** В какую сторону развиваются материалы OWASP: это скорее набор «checklist'ов»? И как соотносятся такие рекомендации с существующими языковыми и отраслевыми стандартами?

**Ведущий.** OWASP объединяет состоявшихся экспертов из разных стран и организаций. Специалисты собираются на конференциях, обсуждают проекты и развивают их. Такие материалы не создаются случайным человеком «с улицы»: формулировки проходят обсуждение и согласование в профессиональном сообществе.

**Ведущий.** При этом рекомендации OWASP в значительной степени платформонезависимы. У конкретного языка и стека могут быть свои требования и инструменты. Организация должна собрать применимый для себя набор правил, учитывая используемые языки, инфраструктуру и способ разработки.

**Участник.** У C есть именно стандарты безопасной разработки, а не только лучшие практики. Но команда часто просто подключает библиотеку и не задаётся вопросом, как она реализована. Это относится и к цепочке поставок, и к требованиям к готовой инфраструктуре.

**Ведущий.** Да. В организации есть часть уже подготовленной инфраструктуры и часть, которую ещё нужно выстроить. Для одних языков и технологий существует один набор требований, для других — другой. Единого универсального ответа «пришли в любую организацию и получили готовую инструкцию на всё» нет.

### 00:49:20–00:52:06 — Организационные требования и проверка конфигураций

**Ведущий.** Каждая организация формирует совокупность решений и требований к реализации возможностей. Она может сказать: используем определённые технологии, поэтому ознакомьтесь с соответствующими требованиями, настройте процессы проверки и соблюдайте их. Это не один документ, а набор взаимосвязанных решений.

**Участник.** Внутри организации со временем накапливается много YAML-файлов и конфигураций. Когда разворачиваешь сервис и читаешь YAML, написанный не тобой, можно увидеть, что ради скорости в нём проигнорированы очевидные меры. Есть ли инструменты верификации таких конфигураций с точки зрения безопасности? Есть ли для декларативных языков аналог рекомендаций или проверок?

**Ведущий.** Решения есть. Можно закрепить в манифестах и конфигурациях обязательный набор требований и использовать простые статические анализаторы, чтобы проверять наличие или отсутствие нужных условий. Если требуемых настроек нет, это должно быть видно на проверке.

**Ведущий.** Эти подходы можно использовать совместно с системами и процессами, которые уже есть у организации. [Концовка фразы о конкретных системах неразборчива.]

### 00:52:07–00:53:06 — Завершение первой презентации

**Ведущий.** Подведём итог. Мы обсудили, что приложения имеют поверхность атаки; рассмотрели клиентскую и серверную стороны, риски для данных и необходимость защиты. Мы также познакомились с ресурсами OWASP, перечнями рисков и практическими материалами для разработки и проверки приложений.

**Ведущий.** На этом первая презентация завершена. Передаю микрофон: дальше будет первая групповая лабораторная работа.

### 00:53:07–00:56:00 — Организация первой групповой работы

**Ведущий групповой активности.** Приступаем к первой групповой работе — работе с картой атакуемой поверхности. Эта подготовительная активность обозначена как **ЛР_0 «Инвентаризация активов и критические активы (поиск в Juice-Shop)»**. Откройте папку, которую мы отправляли по электронной почте, и скачайте шаблон: вся работа будет проводиться в нём.

**Ведущий групповой активности.** Сначала нужно разделиться на команды. Участники со стикерами должны найти людей со стикерами того же цвета — это и будет одна команда. Те, у кого стикера нет, могут присоединиться к другой группе.

**Ведущий групповой активности.** Расчётный размер команды — примерно пять-шесть человек. Пожалуйста, сядьте вместе и выполняйте активность совместно.

**Ведущий групповой активности.** Получилось понять, кто в какой команде? Нужна ли помощь?

**Ведущий групповой активности.** Поднимите руку, если не удалось определиться. Можно сесть сюда — будем работать вместе.

**Ведущий групповой активности.** [Короткие организационные реплики о распределении участницы по группе; смысл не влияет на содержание задания.]

### 00:56:01–00:57:44 — Задание: карта атакуемой поверхности

**Ведущий групповой активности.** Пока команды собираются, коротко объясню суть задания. На столе должна лежать карточка экрана приложения; в папке находится шаблон, который нужно заполнить.

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

**Ведущий групповой активности.** После обсуждения у каждой команды будет собственный результат. На представлении необходимо кратко рассказать, какие элементы и сценарий атаки выделены в приложении и как можно снизить связанные с ними риски.

**Ведущий групповой активности.** На представление результата отводится всего полторы минуты на команду. Если есть вопросы по шаблону, задавайте их ведущим; один из экспертов поможет сориентироваться в самой активности.

**Ведущий групповой активности.** На выполнение задания отводится `[возможно: 10–15 минут]`; числовая формулировка искажена, но оба числа различимы.

### 00:57:45–00:57:50 — Конец фрагмента

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


## Фрагмент 2

### `00:00:09–00:03:57` — завершение командного разбора поверхности атаки

**`00:00:09` — Ведущий.** Продолжается разбор результатов групповой работы. Начало фразы неразборчиво; далее обсуждаются риски, связанные с формой обратной связи / подачи обращения и приложенными к ней файлами.

**`00:01:12–00:02:24` — Ведущий.** В качестве активов, затронутых сценарием, названы текст обращения, документы с возможными персональными данными, приложенные файлы и идентификаторы пользователя. В обсуждаемом сценарии присутствует устаревший путь загрузки файла. Риск связан с обработкой специально сформированного файла; точный формат, способ обработки и последствия в этом отрезке не восстанавливаются.

**`00:02:24–00:03:24` — Ведущий.** Отмечено, что в программе будет лабораторная работа по загрузке специально подготовленного файла. В ней предполагается наблюдать реакцию приложения на чрезмерно большой объём данных и состояние отказа в обслуживании. Название конкретного формата и часть механики неразборчивы; смысл практики — показать последствия ресурсоёмкой обработки входного файла.

**`00:03:57` — Ведущий.** Подводится итог командной работы: желающих дополнительно представить результат нет. Объявляется обед; до следующей активности участникам предлагается отдохнуть и пообедать. Время возвращения распознано противоречиво, поэтому не уточняется.

> **[Разрыв фрагмента: 00:03:57–00:41:14. Содержание не реконструируется.]**

### `00:41:14–00:43:44` — ввод в три категории OWASP Top 10:2025

**`00:41:14` — Ведущий.** После перерыва ведущий предлагает задавать вопросы по непонятным терминам и подходам как в конце блока, так и по ходу работы, если участник «совсем застрял». Объявляется разбор трёх первых категорий рисков.

**`00:42:02` — Ведущий.** Нормализованная последовательность категорий:

1. **A01 — Нарушение контроля доступа**;
2. **A02 — Нарушение безопасности конфигураций**;
3. **A03 — Уязвимости в цепочке поставок ПО**.

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

**`00:43:02` — Ведущий.** Теоретическая часть предшествует практике. Участникам, начинающим изучение безопасности приложений, предлагается начать хотя бы с первой лабораторной и добиться понимания сценария; более опытные участники могут идти по всем трём лабораторным работам параллельно.

---

## A01 — Нарушение контроля доступа

### `00:43:44–00:51:31` — авторизация, IDOR и административные API

**`00:43:44` — Ведущий.** A01 связывается прежде всего с ошибками авторизации. Повторяется различие понятий:

- **идентификация** отвечает на вопрос «кто обращается к системе?»;
- **аутентификация** — «действительно ли это тот, за кого он себя выдаёт?»;
- **авторизация** — «разрешено ли этому субъекту выполнить конкретное действие или обратиться к конкретному объекту?».

**`00:44:44` — Ведущий.** Суть категории — отсутствие проверки, имеет ли пользователь право доступа к конкретному объекту. Примеры далее рассматриваются на OWASP Juice Shop: это намеренно уязвимое учебное приложение, поэтому его сценарии не следует механически переносить на реальные системы, но они близки к типовым ошибкам веб-приложений.

**`00:45:44–00:47:37` — Ведущий.** Разбирается запрос API, возвращающий содержимое пользовательской корзины. Пользователь аутентифицируется токеном в заголовке `Authorization`, однако одной аутентификации недостаточно: сервер обязан отдельно проверить, что запрошенная корзина принадлежит именно этому пользователю. Если в маршруте или параметре фигурирует предсказуемый числовой идентификатор, атакующий может попытаться изменить его и получить чужую корзину.

**`00:45:44` — Ведущий.** На слайде показывается типовой запрос к backend API, который возвращает «контент корзины пользователя». Из речи следует, что в запросе одновременно присутствуют: аутентификационный заголовок с токеном и отдельный идентификатор корзины. Ведущий специально проговаривает, что из структуры ответа можно увидеть, чья это корзина и какие позиции в ней находятся. Это не означает, что любой человек должен видеть такие сведения: сервер должен связать объект корзины с субъектом, подтверждённым токеном.

**`00:46:43` — Ведущий.** Логика проверки демонстрируется через простой пример: если в запросе встречается идентификатор вида `42`, естественная попытка исследователя — поставить рядом стоящее значение, например `43`. В учебном сценарии именно такой перебор соседнего идентификатора показывает, что предсказуемость объекта и отсутствие проверки владения вместе образуют проблему. Ведущий не называет саму смену числа доказательством автоматически: она лишь задаёт проверяемую гипотезу о контроле доступа.

**`00:47:37–00:49:35` — Ведущий.** Такой класс ошибки нормализуется как **IDOR (Insecure Direct Object Reference, небезопасная прямая ссылка на объект)**. У аутентифицированного пользователя появляется доступ к объектам других пользователей, хотя неаутентифицированный пользователь доступа не получил бы. Идентификаторами могут быть `userId`, `profileId`, `orderId` и другие параметры маршрута или запроса. Доступ на чтение приводит к утечке, а доступ на изменение — к существенно более тяжёлым последствиям: изменению учётных данных, состава чужой корзины, заказа, бронирования или статуса заявки.

**`00:47:37` — Ведущий.** Отдельно проводится граница между двумя ситуациями. В первой система не пускает неаутентифицированного пользователя — это нормальная проверка того, что пользователь вошёл в систему. Во второй вошедший пользователь получает чужой объект только потому, что подставил другой идентификатор. Вторая ситуация остаётся нарушением авторизации, даже если приложение в целом «требует логин».

**`00:48:36` — Ведущий.** Перечисляются возможные формы прямой ссылки: запросы к профилю, пользователю, заказу, объекту базы данных, маршрут с `id` и подобные параметры. Ведущий описывает типичное поведение атакующего: он не предполагает, что интерфейс браузера исчерпывает все варианты, а рассматривает наблюдаемые запросы API и пытается изменять контролируемые значения. В хорошо построенной системе каждый такой запрос должен пройти одинаковую проверку «имеет ли этот пользователь право на данный ресурс».

**`00:49:35` — Ведущий.** Примеры последствий разворачиваются от чтения к записи. Чтение чужой корзины уже может раскрыть данные и интересы пользователя; запись в чужой объект позволяет изменить e-mail, состав корзины, заказ или состояние бронирования. Именно поэтому нельзя ограничиваться тезисом «идентификатор всё равно трудно угадать»: случайность идентификатора может снизить вероятность угадывания, но не заменяет авторизационную проверку.

**`00:49:35–00:51:31` — Ведущий.** Приводится второй пример: пользовательский интерфейс скрывает административную страницу от обычного пользователя, но отдельный API-метод административной функции может проверять лишь факт аутентификации, а не административную роль. В таком случае пользователь способен, например, подставить другой идентификатор и вызвать действие в отношении чужой учётной записи. Защита на уровне интерфейса не заменяет авторизацию на сервере и в каждом API-методе.

**`00:50:34` — Ведущий.** На примере административного интерфейса ведущий подчёркивает различие между «страница не открывается» и «операция действительно недоступна». У интерфейса может быть обработчик, который проверяет, является ли пользователь администратором, но соседний метод API — например, отключение пользователя — способен забыть эту проверку. Тогда обычный пользователь не увидит меню администратора, но сможет вызвать непроверенный endpoint напрямую.

**`00:51:31` — Ведущий.** Вывод формулируется предельно практично: у каждого действия, меняющего состояние, должна быть серверная проверка роли и/или владения. Проверять только аутентификацию недостаточно: «да, пользователь вошёл» ещё не отвечает на вопрос «может ли именно он отключить именно эту учётную запись».

### `00:51:31–00:57:58` — профилактика, тесты и наблюдаемость

**`00:51:31` — Ведущий.** Базовый принцип формулируется как **«запрещено по умолчанию»**: всё, что не разрешено явно, запрещено. Права ролей на ресурсы должны быть описаны в матрице контроля доступа.

**`00:52:15` — Ведущий.** Матрица контроля доступа описывается не как формальность, а как способ не потерять проверку при росте приложения. В ней должны быть видны роли, ресурсы и допустимые действия: кому разрешено чтение, кому изменение, кто работает только со своими объектами, а кто — с объектами организации. Эта же матрица затем должна быть реализована в механизме авторизации, а не существовать отдельной таблицей «для отчёта».

**`00:52:15–00:53:07` — Ведущий.** Авторизацию следует централизовать: проверка не должна быть реализована в одном обработчике и забыта в другом. Возможны общий компонент, сервис или иной слой приложения, который для каждого запроса применяет правила матрицы доступа и проверяет владение объектом. Доверять данным, пришедшим с клиента, нельзя: возможность выполнить действие через браузер не означает, что тот же запрос нельзя вручную сформировать вне предусмотренного интерфейса.

**`00:53:07` — Ведущий.** Для иллюстрации недоверенного клиента берётся добавление товара в корзину. Через экран пользователь может выбрать только свои данные и разрешённые значения, но запрос можно послать не только из браузерной формы: его можно повторить отдельным клиентом, консольной утилитой или инструментом перехвата. Следовательно, сервер не вправе считать параметр «правильным» только потому, что нормальный интерфейс не даёт ввести иной вариант.

**`00:53:07–00:54:30` — Ведущий.** Для проверки нужны прежде всего тесты. Следует готовить позитивные и негативные сценарии: кому доступ разрешён и кому он должен быть запрещён. Интеграционные тесты проверяют поведение приложения целиком. В production-эксплуатации нужны журналы событий: многочисленные отказы авторизации, попытки перебора и обращения к неподходящим объектам должны становиться наблюдаемыми событиями и при необходимости вызывать оповещения.

**`00:54:04` — Ведущий.** В вопросе о тестировании участники различают unit- и интеграционные проверки. Ведущий отвечает, что для авторизации особенно важны негативные сценарии: заранее зафиксировать, от каких пользователей доступ ожидается, а от каких — нет. Уровень теста зависит от реализации, но сам проверяемый инвариант один: запрещённое действие не должно пройти независимо от способа обращения к системе.

**`00:54:30` — Ведущий.** Помимо тестов в разработке затрагивается работа уже развёрнутой системы. Если для одного пользователя или адреса возникает много отказов авторизации, это не просто техническая строка в журнале, а признак, который должен быть доступен для анализа. Упоминаются системы, формирующие события и alert-уведомления на основании логов; важно видеть перебор и аномальные обращения, а не только записывать их.

**`00:55:23–00:57:58` — Диалог ведущего с участниками.** Обсуждается, считать ли такие проверки функциональными или проверками безопасности. Ответ: это связанные области; один и тот же сценарий может быть оформлен и как функциональный тест, и как тест безопасности. Для преподавательской методики предлагается сначала дать студентам модель ролей и ресурсов в виде таблицы «кто что может / не может», затем требовать, чтобы эта модель была отражена в коде и проверках. В финале фрагмента упоминается, что для разработки важно не доверять значениям клиента и проверять их сервером; часть фразы повреждена.

**`00:55:23` — Участник.** Звучит вопрос, как соотносить число рисков и число проверок: должна ли на каждый риск приходиться одна проверка или проверки должны быть общими. Ведущий отвечает, что паттерны защиты часто общие, но в конкретном приложении они раскладываются на множество точек контроля. Например, для ролевого приложения важно проверить не абстрактный «контроль доступа», а все роли и все существенные виды операций.

**`00:56:10–00:57:03` — Ведущий.** Разговор переводится в плоскость преподавания: задача — не только показать студенту ошибку, но научить его строить механизм правильно. Сначала можно описать ожидаемую модель в таблице, затем попросить реализовать её программно, а потом — показать тестами, что клиентские параметры не обходят серверное ограничение. Слово, которым в этой части назван один из этапов процесса, неразборчиво; смысл последовательности сохраняется.

### `00:58:10–01:01:53` — вопрос о недоверенном клиенте и перехвате сессии

**`00:58:10` — Участник.** Поднимается вопрос о проверке отсутствия вредоносного посредника между клиентом и сервером и о доверии к клиентской платформе.

**`00:58:10` — Участник.** Вопрос ставится шире, чем IDOR: как удостовериться, что между клиентом и сервером нет злоумышленного промежуточного звена и что с клиентской стороны данные не меняются до отправки. Формулировка текст местами нарушена, но очевидно, что участник хочет связать авторизацию с моделью недоверенного клиента и захватом сессии.

**`00:59:07–01:00:31` — Ведущий.** В ответ разделяются две плоскости. В разбираемом серверном сценарии неважно, каким именно инструментом клиент обратился к серверу: сервер должен безопасно и одинаково обрабатывать любой запрос. Клиент по умолчанию рассматривается как недоверенный, поэтому сервер не может опираться на ограничения пользовательского интерфейса.

**`00:59:07` — Ведущий.** Ведущий подтверждает, что в реальных веб-приложениях нельзя заранее знать, отправил ли данные «настоящий» интерфейс пользователя и не был ли запрос модифицирован. Но в рамках текущего примера не нужно сначала доказывать происхождение клиента: правильная серверная авторизация должна сработать и против добросовестного браузера, и против самописного клиента, и против запроса, изменённого посредником.

**`01:00:31–01:01:17` — Ведущий.** При рассмотрении клиентской части отдельными темами станут захват сессии и вредоносное поведение клиента. Цель атакующего — выполнить действия от имени пользователя; сервер снижает риск корректной проверкой сессии и авторизации. Полная фраза о конкретных мерах в этой части неразборчива.

**`01:01:17` — Диалог.** Участники соглашаются, что захват сессии — это именно ситуация «кто-то совершает действия как будто от моего имени». Ведущий не завершает технический разбор этой темы в данном блоке и возвращает разговор к следующей категории, чтобы не смешивать серверную авторизацию и защиту клиентской среды.

**`01:01:53` — Ведущий.** Завершение A01: соответствующая лабораторная работа будет разобрана в практике.

---

## A02 — Нарушение безопасности конфигураций

### `01:01:53–01:08:26` — избыточная поверхность атаки и небезопасные настройки

**`01:01:53–01:03:51` — Ведущий.** A02 — небезопасные или ошибочные настройки системы. У приложения с долгой историей могут остаться старые, неиспользуемые или недокументированные API-маршруты. Они продолжают быть частью поверхности атаки и могут быть реализованы небезопасно. Общий принцип: всё неиспользуемое следует удалять; сокращение поверхности атаки повышает безопасность.

**`01:02:52` — Ведущий.** Под «конфигурацией» здесь понимаются не только параметры веб-сервера. Это также набор опубликованных endpoint-ов, включённые интерфейсы, устаревшие версии API и не удалённые после релизов обработчики. В приложении с длинным жизненным циклом таких фрагментов кода может накопиться много; они иногда не документированы и не попадают в стандартный пользовательский путь, но всё равно доступны по сети.

**`01:03:51` — Ведущий.** Правило «всё, что не используется, убрать» объясняется через поверхность атаки. Оставленный маршрут не становится безопасным из-за того, что о нём не написали в документации. Если он продолжает отвечать, его можно найти и проверить отдельно; значит, он остаётся ответственностью разработчиков и эксплуатации.

**`01:03:51–01:06:18` — Ведущий и участник.** Обсуждается пример инфраструктурной конфигурации: данные, которые должны быть защищены, нельзя оставлять в форме, допускающей простое декодирование. Упоминаются кластеры, контейнерная инфраструктура и хранилище секретов; часть терминов в этой части искажена. Участник уточняет, учитывается ли локальный доступ к серверу. Ответ: это определяется моделью угроз. Если предполагается физический или локальный доступ к хосту, нужны соответствующие меры, например шифрование разделов и защита секретов; нельзя автоматически считать сервер недоступным атакующему.

**`01:04:51` — Участник.** Уточняется, о каком именно сервере и локальном пользователе идёт речь: если сервер размещён в изолированном контуре, всегда ли нужен учёт локального доступа? Ведущий не формулирует универсального ответа, а возвращает вопрос к модели угроз: возможность физического доступа, кражи носителя или доступа администратора к хосту меняет необходимые меры.

**`01:05:32–01:06:18` — Ведущий.** В ответ отмечается, что локальный субъект не обязательно должен быть штатным администратором. Если сценарий допускает доступ к хосту, решение может включать защиту разделов и секретов. Если такой сценарий исключён обоснованно, это тоже должно быть осознанным предположением, а не молчаливой верой в то, что «сервер сам по себе защищён».

**`01:06:18–01:08:26` — Ведущий.** Другой пример — подробные сообщения об ошибках. Вместо нейтрального `404` приложение или сервер могут раскрыть стектрейс, пути в файловой системе, внутренние компоненты и другие данные, полезные атакующему. Ещё один устаревший, но показательный сценарий — разрешение незашифрованного соединения наряду с защищённым: это создаёт возможность перехвата или модификации трафика.

**`01:07:05` — Ведущий.** На примере отсутствующей страницы поясняется разница между общим сообщением об ошибке и диагностикой, выданной пользователю. Если сервер возвращает стектрейс, имена компонентов, пути или подробности маршрута, он помогает исследовать собственную внутреннюю структуру. Диагностика нужна разработчику, но не обязательно должна быть содержимым внешнего HTTP-ответа.

**`01:08:02` — Ведущий.** В пример с транспортной защитой закладывается простой смысл: если ресурс принимает и защищённое, и незашифрованное соединение, нарушается ожидаемая конфиденциальность канала. Формулировка текст обрывается, но ведущий связывает это с возможностью просмотра трафика между пользователем и сервером.

### `01:08:26–01:16:48` — безопасная конфигурация как воспроизводимый процесс

**`01:08:26–01:12:15` — Ведущий и участники.** Обсуждаются большие наборы рекомендаций по безопасной настройке. Участник замечает, что различные источники и экспертные сообщества предлагают чек-листы разного объёма и детализации. Ведущий соглашается: невозможно применить каждый пункт без контекста; нужно определить применимость к конкретной системе. Упоминаются отраслевые и регуляторные профили/наборы настроек, которые могут помогать с оценкой соответствия, но сами по себе не заменяют анализ практических угроз.

**`01:08:26` — Ведущий.** Участникам обещан отдельный показ наборов безопасных настроек перед лабораторной работой. Ведущий заранее предупреждает, что такие материалы могут занимать сотни и тысячи страниц. Это не инструкция «прочитать всё и включить всё», а отправная точка для систематической проверки конфигураций.

**`01:09:30` — Участник.** Вопрос формулируется как практический: насколько подобные документы применимы в жизни, если часть требований очевидно не подходит конкретной системе. В обсуждении слышно недовольство ситуацией, когда один источник даёт многостраничный benchmark, другой — короткий список, а третья группа экспертов предлагает свой вариант.

**`01:10:30–01:11:40` — Участник и ведущий.** Участник перечисляет примеры известных чек-листов и наборов рекомендаций, но конкретные названия в этой части искажены. Ведущий отвечает, что однозначного «единственного правильного» списка нет; есть разные контексты, разные цели и, при необходимости, регуляторные источники. В диалоге упоминается пример готового профиля системы, который автоматически выставляет настройки под заданный уровень/режим защищённости.

**`01:11:40–01:12:15` — Ведущий.** Автоматический профиль удобен для проверки соответствия выбранному набору требований, но не отвечает на все вопросы прикладной безопасности. Сравнение формулируется резко, но смысл такой: «выполнить профиль, чтобы регулятор был доволен» и «понять, как атакующий использует конкретную ошибку» — связанные, но не тождественные задачи.

**`01:12:27–01:14:14` — Диалог.** Уточняется различие между уязвимостью кода, архитектурной ошибкой и ошибкой конфигурации. Ошибка конфигурации может возникнуть и при корректно спроектированной архитектуре: предусмотренная мера безопасности не включена, неправильно настроена или не проконтролирована по процессу. Это отдельная операционная причина риска.

**`01:12:27` — Участник.** Спрашивает, к какому этапу или виду работ следует относить чек-лист: к разработке, к коду, к архитектуре или к эксплуатации. Вопрос важен методически: студенту нужно не только знать перечень настроек, но и понимать, в каком процессе они появляются.

**`01:13:02–01:13:34` — Ведущий и участник.** Ведущий уточняет, что «уязвимость конфигурации» — не ошибка исходного кода и не обязательно ошибка архитектора. Архитектура могла предусматривать безопасный вариант, однако при развёртывании кто-то отключил флаг, не включил защиту или не выполнил регламент. Участник дополнительно связывает это с ответственностью и контролем исполнения.

**`01:14:14–01:16:48` — Ведущий.** Для профилактики названы следующие практики:

- проектировать и проверять только актуальные API-маршруты;
- валидировать загрузки и содержимое входных данных на сервере;
- описывать конфигурацию как код, чтобы она была повторяемой и проверяемой;
- стремиться к неизменяемой инфраструктуре: изменение выполняется через изменение описания и развёртывание, а не через неконтролируемую ручную правку сервера;
- применять автоматизированные проверки конфигурации, статический анализ и проверки ответов на ошибки;
- анализировать журналы событий и отклонения конфигурации.

Ведущий связывает этот блок с **ЛР_2 — «Устаревший интерфейс (оставленная поверхность атаки)» (A02)**.

**`01:14:14` — Ведущий.** При переходе к прикладным мерам отдельно упоминаются проверки загрузок: если на сервер что-то загружается, приложение обязано валидировать то, что фактически получает, а не полагаться на ожидания пользовательского интерфейса. текст в этой части размыта, поэтому не дописываются неподтверждённые механизмы проверки.

**`01:15:14` — Ведущий.** Конфигурация как код называется способом снизить человеческий фактор: нужное состояние описывается так, чтобы его можно было повторно применить на нескольких системах. В речи упоминаются инструменты, но их названия повреждены, поэтому намеренно не фиксируются.

**`01:15:48–01:16:48` — Ведущий.** Развивается идея неизменяемой инфраструктуры: вместо ручной правки «в уже работающем сервере» изменения вносятся в описание, после чего окружение разворачивается снова. Ведущий не утверждает, что это единственный возможный путь, но подчёркивает, что так проще контролировать, какой именно конфигурационный код стал причиной состояния системы. В завершение называются автоматизированные проверки безопасности конфигурации, анализаторы и контроль обезличенных ответов об ошибках.

---

## A03 — Уязвимости в цепочке поставок ПО

### `01:17:25–01:23:49` — зависимые компоненты и типовые атаки

**`01:17:25–01:19:27` — Ведущий и участник.** Современное приложение в значительной части состоит из компонентов с открытым входным кодом. Это естественный способ ускорить разработку: вместо повторного создания готовой функции подключаются библиотеки. Участник уточняет, какая доля кода обычно является сторонней; фиксированного процента не устанавливается, потому что он зависит от продукта.

**`01:17:25` — Ведущий.** Третий элемент связывается с тем, что практически любое современное приложение «собирается» из чужого и собственного кода. Ведущий называет разные оценки доли Open Source, но не закрепляет одну цифру как норму: некоторые продукты берут очень много готовых компонентов, другие поддерживают больше собственного кода.

**`01:18:25` — Ведущий.** Логика разработчика передаётся без осуждения: нет смысла заново писать уже существующую библиотеку, если она решает типовую задачу — например, авторизацию или другую распространённую функцию. Поэтому проблема не в самом использовании зависимости, а в том, как она выбирается, доставляется, обновляется и контролируется.

**`01:18:57` — Участник.** Вносит уточнение о продукте, где заявляется большое количество собственного кода, но некоторые базовые вещи всё равно не переписываются. Ведущий соглашается: доля внешних компонентов зависит от границ того, что считать продуктом, и от технологического стека.

**`01:19:27–01:20:27` — Ведущий.** Разбирается **typosquatting** пакетов: злоумышленник публикует пакет с именем, почти неотличимым от популярного или внутреннего, рассчитывая на опечатку разработчика. Аналогия — фишинговый домен, похожий на известный адрес.

**`01:19:27` — Ведущий.** Ведущий начинает «на пальцах» объяснять цепочку поставки: библиотеки получают из GitHub или реестров соответствующих языковых экосистем. Для typosquatting достаточно слегка изменить имя пакета и рассчитывать, что разработчик найдёт похожий результат, не заметив одного символа или похожего написания. В текст присутствует сравнение с доменом банка, отличающимся дефисом или одной буквой.

**`01:20:27–01:21:27` — Ведущий.** Разбирается **dependency confusion** `[термин восстановлен по смыслу]`: внутреннее имя компонента публикуется во внешнем реестре, а разрешение зависимостей может привести к тому, что пакетный менеджер выберет внешнюю версию вместо внутренней. Риск связан не с названием как таковым, а с правилами поиска и приоритетами репозиториев.

**`01:20:27` — Ведущий.** Для второго сценария берётся условная внутренняя библиотека с именем, используемым только внутри организации. Если аналогичное имя появляется во внешнем реестре, а пакетный менеджер сначала смотрит наружу или неверно настроен, внутренняя сборка способна получить не тот компонент. Ведущий подчёркивает, что это уже не «опечатка пользователя», а ошибка разрешения зависимостей и границ доверия между внутренними и публичными компонентами.

**`01:21:27–01:23:49` — Ведущий.** Ещё один типовой сценарий — компрометация учётной записи сопровождающего пакета. Злоумышленник публикует новую версию с бэкдором. Особо опасны штатные lifecycle-скрипты экосистемы пакетов: при установке библиотеки они могут выполняться автоматически. Если вредоносный скрипт получает доступ к переменным окружения CI, он способен отправить токен или иной секрет наружу. Конкретные имена файлов распознаны неустойчиво, поэтому не приводятся.

**`01:21:27` — Ведущий.** Третий сценарий формулируется как компрометация сопровождающего: злоумышленник получает доступ к аккаунту разработчика и выпускает новую версию доверенной библиотеки. В таком случае потребитель устанавливает компонент с привычным названием и ожидаемой функцией, но получает вредоносный код вместе с обновлением.

**`01:22:26–01:23:26` — Ведущий.** В качестве технической иллюстрации назван штатный post-install-подобный механизм JavaScript-экосистемы `[точное имя скрипта в этой части неустойчиво]`. Пакет может легитимно запускать скрипт после установки, но после компрометации тот же механизм читает переменную окружения CI с токеном и отправляет её наружу. Это подчёркивает важное различие: опасной бывает не обязательно «нестандартная команда», а разрешённая платформа возможность, использованная в неправильной версии компонента.

### `01:23:49–01:35:29` — воспроизводимость, проверка происхождения и место ИИ

**`01:23:49–01:26:32` — Ведущий и участник.** В качестве ключевой меры предлагаются воспроизводимые сборки и фиксация точных версий зависимостей. Участник замечает, что обычно хочется брать «самую свежую» версию, чтобы получить исправления. Ведущий объясняет разницу между осознанным, проверенным обновлением и автоматическим плавающим указанием на последнюю версию: если репозиторий или сопровождающий скомпрометированы, новая версия может оказаться вредоносной. Обновление не отменяется, но должно проходить проверку по цепочке поставки.

**`01:23:49` — Ведущий.** Воспроизводимость объясняется через повторяемый результат сборки: при одинаковом описании зависимостей сборка должна получать одни и те же версии, а не незаметно подтягивать то, что сегодня называется «последним». В речи есть оборванный фрагмент о фиксации, но смысл устойчив: у команды должна быть возможность установить, какой именно компонент был использован в конкретном артефакте.

**`01:24:40` — Участник.** Возражает с позиции практической безопасности: если новая версия исправляет найденную ошибку, почему не брать последнюю версию автоматически? В ответ ведущий не говорит «никогда не обновляться». Он отделяет обновление от плавающей зависимости: сначала выбирается версия, проверяется, затем её факт фиксируется; следующая версия становится отдельным изменением, которое тоже требует оценки.

**`01:25:42–01:26:32` — Ведущий.** Разворачивает угрозную модель: если владелец репозитория или сам репозиторий скомпрометирован, новая «latest»-версия может оказаться выпущенной до того, как легитимный сопровождающий обнаружит проблему. Именно поэтому вопрос не сводится к «новое против старого», а включает происхождение пакета, изменения и доверие к источнику.

**`01:26:40–01:31:37` — Диалог об анализе библиотек и языковых моделях.** Участники обсуждают, достаточно ли скачать исходный код библиотеки, посмотреть его или использовать языковую модель для первичной проверки. Ведущий подчёркивает ограничения такого подхода: крупный компонент сложно проверить вручную, а вывод языковой модели вероятностный и зависит от контекста. Участник отдельно ставит вопрос о пригодности модели для экспертизы безопасности, когда изменяется техническая и организационная обстановка. Консенсус диалога: модель может помогать, но не даёт стопроцентной гарантии и не заменяет независимую экспертизу.

**`01:26:40–01:27:40` — Участники.** Звучит практическая идея: скачать библиотеку в виде папки с файлами, пройтись по исходному коду, посмотреть список правил или использовать поиск. Собеседники сразу отмечают ограничение: даже если такой просмотр даёт полезный сигнал, он не доказывает отсутствие вредоносного поведения; крупную библиотеку трудно исчерпывающе проверить вручную.

**`01:28:05–01:28:56` — Участник.** Приводит сценарий условного поведения по контексту — например, разный код для разных IP-адресов. Отсюда следует, что единичная проверка может не увидеть условие срабатывания. В разговоре появляется идея клонировать репозиторий и попросить языковую модель помочь с проверкой, но сразу ставится вопрос: как верифицировать сам вывод модели.

**`01:29:30–01:30:41` — Участник.** Формулирует более общий вопрос: можно ли применять непроверенную или неполностью проверенную языковую модель для экспертизы безопасности кода с учётом условий эксплуатации. Данные, инфраструктура, политика и контекст приложения меняются; обучение модели может не соответствовать текущему состоянию. Восстановленная мысль звучит так: модель может выдать правдоподобное рассуждение, но это не отменяет необходимости эксперта, который понимает окружающую систему.

**`01:30:41–01:31:37` — Ведущий.** Отвечает, что модель не даёт стопроцентной детерминированной гарантии: повторные обращения могут приводить к разным формулировкам и выводам. В качестве практической модели работы упоминается несколько уровней проверки: один агент/инструмент выполняет работу, другой проверяет, третий аудирует. Даже такое «многократное» использование остаётся механизмом повышения вероятности, а не заменой ответственности человека.

**`01:31:37–01:34:22` — Ведущий.** Перечисляются дополнительные меры:

- использовать внутренние, контролируемые реестры компонентов;
- генерировать перечень зависимостей / **SBOM** для поиска уязвимостей и композиционного анализа (**SCA**);
- разделять сервисные учётные записи и ограничивать их правами;
- применять короткоживущие токены;
- подписывать артефакты и проверять подписи внешнего ПО;
- проводить автоматизированный поиск уязвимостей, анализ зависимостей и происхождения компонентов;
- отслеживать появление новых сведений об уязвимостях.

**`01:32:25` — Ведущий.** Разговор возвращается от моделей к инженерным мерам. Прямо названа хорошая практика использовать собственные реестры: не забирать библиотеку непосредственно из непроверенного внешнего репозитория в процессе сборки, а сначала пропускать её через контролируемый путь. В этом же месте появляется определение перечня библиотек как основы для поиска уязвимостей и композиционного анализа.

**`01:33:24` — Ведущий.** Секреты рассматриваются как самостоятельная часть цепочки: сервисные учётные записи не должны получать больше прав, чем нужно для операции; токены должны быть короткоживущими; артефакты и внешнее ПО желательно проверять по подписи. Ведущий говорит и о возможности подписывать компонент уже во внутреннем репозитории после внутренней проверки.

**`01:34:22` — Ведущий.** Перечень мер завершается не одной технологией, а циклом: анализ кода и безопасности компонентов, проверка происхождения и подписей, наблюдение за новостями об уязвимостях. Формулировка текст о конкретном типе анализа повреждена, поэтому в стенограмме оставлен только явно различимый смысл.

**`01:34:22–01:35:20` — Диалог.** Участник рассказывает о собственном формате SBOM и возможной конвертации в распространённые форматы. В текст названия форматов распознаны неуверенно, поэтому они не нормализуются без источника. Обсуждается также проверка обращений и адресов как один из способов контроля цепочки поставки.

**`01:34:22–01:35:20` — Участник.** Отвечает на вопрос о генерации SBOM: в его организации используется внутренний формат, а при необходимости сведения приводятся к общему формату. Важен не только файл перечня, но и проверки, позволяющие убедиться, какие обращения происходили и с какими адресами/источниками они сопоставляются. Конец реплики неразборчив, поэтому алгоритм этих проверок не додумывается.

### `01:35:29–01:58:11` — ЛР_1–ЛР_3 и разбор обратной связи

**`01:35:29–01:36:27` — Ведущий.** Объявляется первый практический блок. Требуется открыть лабораторный журнал и выполнить:

1. **ЛР_1 — «Пакет контроля доступа» (A01)**;
2. **ЛР_2 — «Устаревший интерфейс (оставленная поверхность атаки)» (A02)**;
3. **ЛР_3 — «Уязвимая библиотека (резервный файл + сообщение об уязвимости)» (A03)**.

Участникам предлагается начать с ЛР_1; при наличии времени перейти к следующим. Указанная в этой части длительность и фактические часы противоречат друг другу, поэтому точная продолжительность не восстанавливается.

**`01:35:29` — Ведущий.** Перед началом практики проговаривает цель ЛР_3: найти уязвимую библиотеку, попытаться определить класс проблемы и связать наблюдение с разобранной категорией. Формулировка текст «ре… библиотека» не позволяет достоверно назвать конкретную уязвимость, поэтому она не подменяется догадкой.

**`01:36:27` — Ведущий.** Просит найти «лабник» и обращается к тем, у кого его нет. Инструкция построена дифференцированно: начинающий участник может сделать первую работу, а более уверенный — успеть пройти все три. Ведущий несколько раз уточняет, какую лабораторную открывать, и обещает вывести слайд с перечнем.

**`01:37:19–01:40:36` — Ведущий и участники.** Уточняется, какие именно лабораторные работы нужно выполнять и необходимо ли загружать отчёт. Ведущий поясняет, что в данный момент важнее пройти задания и зафиксировать результат. Отдельно звучит просьба смотреть на лабораторные не только как обучающиеся, но и как преподаватели: подумать, как адаптировать задания для студентов с меньшим входным опытом. Упоминается подготовленный шаблон работы с лабораторными; номер файла в этой части распознан противоречиво.

**`01:37:19–01:37:39` — Участники и ведущий.** Несколько коротких уточнений: «делаем какую?», просьба снова показать слайд, шутка о сроке выполнения. Эти реплики сохраняют ход занятия: перед самостоятельной работой участникам важнее всего понять не общую теорию, а конкретное задание и ожидаемый объём результата.

**`01:37:44–01:38:42` — Ведущий.** Отдельно адресует преподавателей. Просьба не сводится к тому, чтобы самим «пройти challenge»: нужно посмотреть на лабоработы глазами студента, которому пока не хватает навыка, и продумать адаптацию под свою дисциплину. В речи есть добродушная шутка о различии между преподавателями и обучающимися, после которой мысль уточняется.

**`01:38:42–01:40:22` — Ведущий и участник.** Ведущий напоминает про шаблон работы с лабораторными: он должен помочь использовать последующие задания в преподавании. Участник спрашивает, требуется ли только «потыкать» задания или будет обязательная выгрузка отчёта. Ответ распознан не полностью, но из контекста следует, что сейчас достаточно отработать сценарии; формальная отчётность в этом коротком упражнении не была основной целью.

> **[Разрыв фрагмента: 01:40:36–01:45:52. Содержание не реконструируется.]**

**`01:45:52–01:53:04` — Практическая работа.** В сохранившемся фрагменте присутствуют отдельные неразборчивые короткие реплики и фоновое общение; содержательной восстановимой речи нет. Факт периода самостоятельного выполнения лабораторных работ сохранён.

**`01:53:04–01:55:55` — Ведущий и участник.** Практика завершается, ведущий приглашает вопросы и идеи. Вопрос касается ЛР_1: изменение идентификатора корзины привело к пустой корзине, а не к очевидному доступу к чужим данным. Ведущий поясняет, что нужно анализировать диапазон идентификаторов и фактические запросы API; одна случайная замена значения не доказывает отсутствие проблемы. Часть названия метода и номера идентификаторов в этой части неразборчивы.

**`01:53:04–01:54:07` — Ведущий.** Фиксирует, что отведённое время закончилось, и предлагает вместо идеального завершения всех трёх работ обсудить вопросы, идеи и препятствия. Участник прямо говорит, что времени не хватило даже на полноценное изучение задания; это важная обратная связь о темпе практики.

**`01:54:21–01:55:55` — Диалог по ЛР_1.** Участник описывает наблюдение: после изменения идентификатора корзины он увидел другую или пустую корзину и не уверен, является ли это доказательством. Ведущий предлагает просмотреть сам запрос, диапазон значений и другие доступные объекты. Смысл ответа: наблюдение за одним ответом нельзя подменять выводом «уязвимость есть/нет» без связи между текущим субъектом, объектом и результатом запроса.

**`01:56:06–01:57:49` — Участник и ведущий.** По ЛР_3 высказывается методическое замечание: студент не обязан заранее знать уязвимости всех версий библиотек; в задании было бы полезно явно обозначить, где и как искать сведения об известных уязвимостях. Ведущий соглашается, что формулировка нуждается в апробации и уточнении. Предполагаемая логика задания: найти резервный `package.json`, увидеть перечень зависимостей и самостоятельно исследовать известные проблемы конкретной версии. Это не отменяет потребность в достаточной подсказке для начинающих.

**`01:56:06` — Участник.** Формулирует замечание именно как методическое: если студент ещё не практикующий разработчик, он не знает наизусть уязвимости конкретных библиотек и версий. Поэтому в условиях полезно либо указать источник поиска, либо дать явный пример процесса: где посмотреть зависимость, как сопоставить версию с известной проблемой и что считать доказательством.

**`01:56:57–01:57:49` — Ведущий.** Пересказывает задумку задания: обучающийся должен найти в FTP-каталоге резервный файл `package.json`, увидеть список зависимостей, выбрать библиотеку и исследовать её версию. Ведущий признаёт, что необходимая «ступенька» для поиска могла быть описана недостаточно ясно, и благодарит за идею доработать методику.

### `01:58:11–02:02:08` — дефект, уязвимость, эксплуатируемость и CVSS

**`01:58:11–01:59:48` — Диалог.** Обсуждается, является ли найденная проблема уязвимостью, если её эксплуатация не продемонстрирована. Участник обращает внимание на связь между недостатком, вероятностью реализации угрозы и эксплуатируемостью. Ведущий просит различать нормативное определение уязвимости и более широкий класс дефектов безопасности.

**`01:59:48–02:00:26` — Участник.** В дискуссии упоминается ГОСТ Р 56939-2024, однако искажённая реплика не позволяет надёжно передать точную нормативную формулировку. Содержательный вопрос — как отличать недостаток, уязвимость и эксплуатируемость, а также как выстраивать процесс предотвращения и устранения недостатков, включая уязвимости. Приводится условный пример неработающего обработчика события: это дефект, хотя не обязательно самостоятельная эксплуатируемая уязвимость.

**`02:00:26–02:02:08` — Диалог.** Затрагиваются метрики **CVSS** и **EPSS**. формулировка передаёт с искажениями их названия и часть аргументации, но смысл вопроса — как учитывать вероятность эксплуатации и допустимый уровень риска при выпуске продукта. Прозвучало, что организация должна иметь явные критерии приемки, а не выпускать продукт с неоговорённым набором известных проблем.

### `02:02:08–02:15:32` — перерыв и неформальное обсуждение ИИ-инструментов

**`02:02:08–02:06:13` — Пауза.** Остаются короткие бытовые и неразборчивые реплики. Содержательная последовательность речи отсутствует.

> **[Разрыв фрагмента: 02:06:13–02:10:29. Содержание не реконструируется.]**

**`02:10:29–02:15:09` — Участники.** Неформально обсуждаются кодовые ассистенты и языковые модели: помощь с написанием кода, подготовкой отчётов и проверки текстов; также — непредсказуемость ответов, ограничения моделей на темы, связанные с уязвимостями, и различия между интерфейсами/API. Имена сервисов в этой части распознаны неустойчиво, поэтому не закрепляются. Это обсуждение не оформляется как официальная рекомендация лектора.

**`02:15:32` — Ведущий.** Возврат к программе: начинается разбор следующих категорий — криптографических уязвимостей, инъекций и небезопасного дизайна.

---

## A04 — Криптографические уязвимости

### `02:16:02–02:26:37` — JWT, защита токенов и отказ от самодельной криптографии

**`02:16:02–02:18:50` — Ведущий.** A04 охватывает небезопасные реализации криптографических механизмов и защиту чувствительных данных. В качестве примера рассматриваются токены, используемые для аутентификации и авторизации. Речь идёт о **JWT (JSON Web Token)** `[термин восстановлен по смыслу]`: токен может содержать сведения о пользователе и его правах, но его содержимое и подпись должны корректно проверяться сервером.

**`02:16:02–02:17:31` — Ведущий.** Ввод в блок начинается с общего определения: криптографические уязвимости возникают не только из-за «плохого алгоритма», а из-за небезопасной реализации хранения, передачи, шифрования и проверки чувствительных данных. Вопросы из аудитории на этом отрезке короткие и местами неразборчивые; ведущий возвращает их к привычному для веб-приложений механизму — токену авторизации.

**`02:17:52–02:18:44` — Ведущий.** Токен показывается как объект, который может содержать информацию, нужную приложению для работы с пользователем: данные о субъекте и его признаках. Из этого не следует, что клиенту можно доверять каждое поле. Ведущий подчёркивает: ценность JWT в том, что сервер может проверить, кем и по каким правилам он сформирован, а не просто прочитать переданные клиентом значения.

**`02:18:50–02:20:23` — Ведущий.** Ошибка возникает, если сервер принимает неподписанный токен или не фиксирует разрешённый алгоритм подписи. В лабораторной работе предлагается обнаружить токен и проверить, безопасно ли приложение обрабатывает алгоритм и подпись. Нормализованное название практики: **ЛР_4 — «Утечка конфиденциальных документов через публичный файловый раздел + неподписанный JWT» (A04)**.

**`02:18:50–02:19:56` — Ведущий.** Разбирается учебная идея: сервер не должен принимать токен, у которого выключена или отсутствует проверка подписи. В текст фраза о подстановке алгоритма распознана с ошибками, но действие в лаборатории понятно: найти JWT, исследовать его обработку и проверить, можно ли заменить механизм на такой, который приложение ошибочно считает допустимым.

**`02:20:15–02:20:51` — Ведущий и участник.** Вопрос выводит разговор на допустимые алгоритмы и требования регуляторов. Названия списков и конкретных алгоритмов в этой части неразборчивы, поэтому не фиксируются. Надёжно слышен вывод: сервер должен иметь явные правила, какие алгоритмы он принимает, а не принимать то, что указал клиент.

**`02:20:23–02:23:43` — Ведущий.** Для токена важны безопасный алгоритм, проверка подписи и проверка обязательных ограничений. текст нечётко распознаёт названия полей, но из контекста следует проверка срока действия, а также иных обязательных параметров токена. Упоминается риск кражи токена после внедрения JavaScript на клиенте; он связывается с последующим блоком о XSS. Дополнительно затрагивается утечка корпоративных данных при неосторожной загрузке документов во внешние хранилища; детали сценария повреждены текст.

**`02:20:51–02:22:29` — Ведущий.** Помимо подписи обсуждаются поля ограничения срока действия и контекста токена. Часть имён полей формулировка передаёт с искажениями, поэтому стенограмма сохраняет смысл без выдумывания точного набора: токен не должен действовать бесконечно и не должен использоваться вне тех условий, для которых выдан. Ведущий связывает это с ситуацией кражи клиентского токена: если вредоносный JavaScript выполнился в браузере, токен может оказаться у атакующего, а серверу всё равно нужно уметь ограничивать последствия.

**`02:22:29–02:23:20` — Ведущий.** На примере корпоративных документов звучит отдельное напоминание: утечка может появиться не только из-за криптографии «в коде», но и из-за того, куда сотрудники загружают данные и как устроено хранилище. Этот фрагмент сильно искажён; нельзя достоверно восстановить тип внешнего сервиса или конфигурацию.

**`02:23:43` — Ведущий.** ЛР_4 характеризуется как более сложная: участник в роли обычного пользователя пытается изменить свои привилегии, если приложение неправильно принимает токен.

**`02:24:31–02:26:37` — Диалог.** Участник делится тезисом из обсуждения с экспертами по сертификации: самодельная криптография почти всегда опасна; то же относится к самостоятельной реализации сложных парсеров. Ведущий поддерживает мысль: криптография требует глубоких компетенций и проверенных реализаций, поэтому без необходимости не следует проектировать собственные алгоритмы и протоколы.

**`02:24:56–02:26:02` — Участник и ведущий.** Реплика звучит как практическое правило: встретив самодельную криптографию, стоит отнестись к ней настороженно; аналогичная осторожность нужна к самодельным парсерам. Ведущий не запрещает использование криптографии вообще, но подчёркивает нехватку ресурса и экспертизы у типовой команды для создания и верификации собственных примитивов. Следовательно, учебный вывод — применять проверенные решения и правильно их настраивать, а не «изобретать шифрование» ради самостоятельности.

---

## A05 — Инъекции

### `02:26:51–02:32:51` — SQL-инъекция и параметризация

**`02:26:51–02:28:45` — Ведущий.** Инъекция — ситуация, в которой управляемые пользователем данные попадают в контекст, где приложение ожидало команду, выражение или иной управляющий синтаксис. Рассматривается вход в систему: сервер концептуально формирует запрос к таблице пользователей по адресу электронной почты и паролю.

**`02:26:51–02:27:46` — Ведущий.** Переход к A05 начинается с общего определения: инъекций много, но учебный пример берёт SQL, потому что его легче увидеть на логике входа. Ведущий словесно раскладывает ожидаемый запрос: из таблицы пользователей выбирается запись, где совпали e-mail и пароль. Это не готовый код приложения, а схема того, как разработчик может ошибочно конструировать выражение.

**`02:27:46–02:28:45` — Ведущий.** Если сервер просто склеивает части SQL с тем, что пришло в POST-запросе, клиент может изменить не только «значение поля», но и саму логику условия. Ведущий постепенно проговаривает это через разницу между ожидаемым совпадением e-mail и пароля и запросом, в который подставлена дополнительная синтаксическая конструкция.

**`02:29:11–02:30:03` — Ведущий и участник.** Объясняется логика классической SQL-инъекции: если приложение склеивает строки запроса с пользовательскими значениями, атакующий может закрыть строковый литерал, добавить логическое условие, всегда дающее истину, и закомментировать остаток выражения. Конкретный учебный фрагмент не восстанавливается дословно из-за искажённой формулировки; ключевая причина — пользовательский ввод интерпретируется как часть SQL-синтаксиса.

**`02:29:51–02:30:03` — Ведущий.** На доске/слайде подробно проговаривается, что закрывающая кавычка завершает ожидаемое значение, затем появляется альтернативное условие, а остаток первичной конструкции перестаёт влиять на результат. Ведущий привязывает итог к возможному возврату первой подходящей записи. Точное значение учебного примера в этом отрезке не восстанавливается уверенно.

**`02:31:03–02:32:51` — Ведущий.** Основная профилактика — параметризованные запросы / подготовленные выражения (**prepared statements**): данные передаются отдельно от структуры SQL и не могут изменить синтаксис запроса. Библиотеки ORM тоже могут предоставлять такие механизмы, но их безопасное использование зависит от конкретного API. Ведущий связывает пример с частью **ЛР_5 — «Пакет инъекций (SQL-инъекция + DOM-XSS)» (A05)**: задача — продемонстрировать, почему нельзя опираться на неизвестные учётные данные как на единственный барьер.

**`02:31:03` — Ведущий.** Параметризация объясняется не магическим словом, а разделением ролей: конструкция запроса описывается как конструкция, а пользовательское значение передаётся как значение. Тогда кавычки и другие символы остаются содержимым параметра, а не становятся фрагментом SQL-кода. В текст несколько раз повторяется мысль «ставить значение как значение, а не куском текста».

**`02:32:00–02:32:51` — Ведущий.** Упоминаются ORM-библиотеки: они могут помогать формировать безопасные обращения к базе данных, но сами по себе не гарантируют безопасность без правильного способа вызова. В учебной лабораторной предлагается увидеть обход аутентификации в специально уязвимом приложении, а затем связать его с отсутствием параметризации.

### `02:33:20–02:44:35` — XSS: DOM, отражённый и хранимый варианты

**`02:33:20–02:34:03` — Ведущий.** **XSS (Cross-Site Scripting)** — выполнение JavaScript в браузере жертвы, когда данные, на которые влияет пользователь, интерпретируются браузером как часть страницы. Последствия выходят далеко за пределы демонстрационного всплывающего окна: возможны действия от имени пользователя, подмена интерфейса и доступ к плохо защищённым данным клиента.

**`02:33:20–02:33:40` — Ведущий.** Ведущий оговаривает, что XSS — широкая тема и многие слушатели уже видели её в демонстрациях со всплывающим окном. Он просит не останавливаться на таком эффекте: показ `alert` — это лишь видимый признак того, что произвольный JavaScript выполнился в контексте страницы.

**`02:33:40–02:34:03` — Ведущий.** Формулируется причина: браузер получил данные из источника, на который может влиять пользователь, и интерпретировал их как часть DOM/страницы. Если злоумышленник получил возможность поместить небольшой фрагмент JavaScript, дальнейшие действия определяются правами страницы и тем, какие данные доступны клиентскому коду.

**`02:35:04–02:38:51` — Ведущий.** Разграничиваются варианты XSS:

- **DOM XSS** — опасное преобразование данных происходит в клиентском JavaScript и DOM;
- **отражённый XSS** — сервер возвращает введённый параметр в HTML-ответе;
- **хранимый XSS** — вредоносные данные сохраняются на сервере или в базе и возвращаются многим пользователям при открытии страницы.

Для DOM XSS объясняется типовая цепочка: пользователь получает ссылку с параметром, открывает её, клиентский код берёт параметр и передаёт его в опасный DOM-приёмник. В формулировке упоминаются `localStorage` и иные хранилища браузера как особенно рискованные места для хранения токенов.

**`02:35:04–02:36:39` — Ведущий.** На примере поискового параметра описывается отражение значения на странице. В учебном варианте пользователь переходит по ссылке с параметром, а строка без надлежащей обработки оказывается в HTML. Ведущий показывает, что тестовое всплывающее окно — не самостоятельная угроза, а следствие того, что браузер начал исполнять введённое как код.

**`02:37:21–02:37:52` — Ведущий.** Слушателей спрашивают, где могут лежать интересные для атакующего данные. В ответ упоминаются токены и хранилища браузера; ведущий подчёркивает, что хранение чувствительных данных в легко доступном клиентскому JavaScript месте ухудшает последствия XSS. Названия одного из хранилищ в этой части повреждены, поэтому фиксируется только различимое `localStorage` и общий вывод.

**`02:39:05–02:41:25` — Ведущий.** Для отражённого XSS значение передаётся серверу, а затем попадает в HTML-ответ. Для хранимого XSS вредоносная нагрузка уже сохранена: каждый последующий пользователь страницы получает её вместе с данными. Ведущий отмечает, что хранимый сценарий обычно опаснее по масштабу воздействия.

**`02:39:05–02:40:56` — Ведущий.** Отражённый вариант поясняется через форму или URL-запрос: пользователь передал значение, сервер вставил его в ответную страницу, а браузер интерпретировал результат. Ведущий добавляет важную оговорку о валидации: запрет в HTML-поле, например запрет отрицательного числа, не является серверной проверкой — запрос можно сформировать вне формы.

**`02:40:56–02:41:25` — Ведущий.** Хранимый XSS описывается как более устойчивый сценарий: данные попали в базу или другое серверное хранилище, и при каждом открытии страницы они возвращаются пользователям. Ведущий говорит образно, что сервер уже «раздаёт» эту полезную нагрузку всем, кто получает соответствующий ответ.

**`02:42:04–02:44:35` — Ведущий.** Две базовые линии защиты:

1. строгая серверная валидация входных данных по ожидаемому типу, структуре и диапазону;
2. корректное контекстное кодирование вывода, чтобы специальные символы отображались как данные, а не интерпретировались как HTML/JavaScript.

Упоминается, что дополнительные практики стоит изучать по материалам OWASP; точная ссылка в этой части не распознана.

**`02:42:04–02:43:34` — Ведущий.** В терминологии безопасной разработки обсуждаются источники данных и опасные приёмники в DOM. Термины распознаны не полностью, поэтому конкретный API не называется. Суть сохранена: если код использует механизм, который создаёт разметку/страницу из строки, нужно контролировать источник данных; если данные уже выводятся, они должны быть закодированы для соответствующего контекста.

**`02:43:34–02:44:26` — Ведущий.** Вторая мера формулируется как кодирование вывода: специальные символы не исчезают для пользователя, но представляются браузеру в форме, не запускающей их как разметку или скрипт. Ведущий ещё раз противопоставляет валидацию входа и кодирование выхода: это не взаимозаменяемые, а дополняющие меры.

### `02:44:35–02:57:34` — CSRF, атрибуты cookie и открытый редирект

**`02:44:35–02:48:23` — Ведущий.** Следующий сценарий — **CSRF (Cross-Site Request Forgery)**. Пользователь уже аутентифицирован на целевом сайте; затем он открывает стороннюю страницу с формой или скриптом, который инициирует запрос к целевому сайту. Если браузер автоматически приложит действующие cookie, сервер может принять запрос как действие пользователя. Пример с переводом денег используется только как иллюстрация изменения состояния.

**`02:44:46–02:45:21` — Ведущий.** Сценарий начинается не с взлома банка, а с обычного условия: пользователь уже авторизован в важном веб-сервисе, а в другом месте ему показывают привлекательную внешнюю ссылку. Ведущий намеренно использует узнаваемый пример, но оговаривает его как модель, а не описание конкретного банка.

**`02:45:21–02:47:20` — Ведущий.** Пользователь переходит на сторонний сайт; на нём может быть красивая страница с кнопкой и скрытая форма. Нажатие на видимую кнопку инициирует запрос не к «подарку», а к API целевого сервиса. Если запрос отправлен в контексте уже существующей сессии, браузер способен подставить cookie автоматически. В учебной речи для иллюстрации назван перевод денег, потому что он ясно демонстрирует опасность неконтролируемого изменения состояния.

**`02:47:20–02:48:23` — Ведущий.** Итог формулируется как «скрытая атака на сайт, где пользователь уже авторизован». Важно не то, что кто-то узнал пароль, а то, что сервер не отличил намеренное действие пользователя от межсайтового запроса, созданного внешней страницей.

**`02:48:23–02:50:09` — Ведущий и участник.** Участник замечает, что современные браузеры ограничивают подобные сценарии сильнее, чем раньше. Ведущий подтверждает: многие атаки зависят от конфигурации и атрибутов cookie. Базовые меры:

- непредсказуемый **CSRF-токен**, проверяемый сервером для операции изменения состояния;
- атрибут `Secure` — передавать cookie только по защищённому соединению;
- `HttpOnly` — не давать JavaScript доступ к cookie;
- `SameSite` — ограничивать отправку cookie в межсайтовых запросах.

**`02:48:23` — Участник.** Уточняет, не требуют ли такие атаки условий, которые современные браузеры уже изолируют. Ведущий признаёт изменение поведения браузеров за последние годы, но возвращает обсуждение к конфигурации: уязвимость зависит от того, как именно сервер и cookie настроены, а не только от возраста примера.

**`02:49:23–02:50:09` — Ведущий.** CSRF-токен объясняется как непредсказуемая строка, которую сервер создаёт и проверяет для запроса изменения состояния. Сторонняя страница не получает такой токен из целевого контекста, поэтому один лишь факт наличия cookie не должен позволить ей выполнить операцию. Затем перечисляются флаги cookie; формулировка передаёт с искажениями их названия, но распознаваемые `Secure`, `HttpOnly`, `SameSite` нормализованы выше.

**`02:50:09–02:53:29` — Ведущий.** Поясняется смысл `SameSite`: строгий режим допускает отправку cookie в пределах того же сайта; более мягкий режим допускает ограниченный набор навигационных сценариев; отсутствие ограничения увеличивает риск межсайтовой подстановки cookie. Рекомендуются также проверки `Origin` и `Referer` как дополнительная защита. Названия отдельных режимов этой части передаёт с ошибками, но общая логика сохранена.

**`02:50:09–02:52:29` — Ведущий.** На вопрос о режимах `SameSite` ведущий поясняет разницу через переходы внутри одного сайта и переходы с внешнего ресурса. В строгом варианте cookie не должны свободно следовать за внешним запросом; более мягкий вариант оставляет часть нормальной навигации. Речь идёт не о «защите на все случаи», а о сокращении ситуаций, в которых чужая страница может использовать пользовательскую сессию.

**`02:52:29–02:53:29` — Ведущий.** В качестве дополнительных сигналов сервер может анализировать `Origin` и `Referer`. Ведущий не выдаёт это за замену токену: эти заголовки названы дополнительными проверками. На этом заканчивается техническая линия CSRF.

**`02:53:29–02:57:34` — Диалог.** Обсуждаются современные настройки браузеров, время жизни сессии и соразмерность ограничениям: чувствительные приложения могут требовать повторную аутентификацию чаще. Затем вводится **open redirect (открытый редирект)**: приложение позволяет передать произвольный URL в параметре и перенаправляет туда пользователя. Это может придавать фишинговой ссылке видимость доверенного домена.

**`02:54:26–02:57:14` — Диалог.** Участники уточняют, как долго должна жить сессия. Универсального числа не формулируется: это зависит от чувствительности приложения, и в серьёзных сценариях пользователя могут просить войти заново после периода неактивности. Ведущий использует банки как понятную аудитории иллюстрацию, не формулируя конкретный тайм-аут как обязательное требование.

**`02:57:34–02:59:28` — Ведущий.** Открытый редирект объясняется через параметр `url`/назначение перехода: приложение иногда действительно должно уметь отправить пользователя дальше по бизнес-сценарию. Но если значение берётся целиком из запроса, злоумышленник может собрать ссылку с доверенным первым доменом и скрытым далее внешним назначением. Пользователь видит знакомый адрес, нажимает, а затем оказывается на другом сайте.

**`02:57:44–03:01:55` — Ведущий.** Для открытого редиректа предпочтительнее использовать не произвольный URL, а идентификатор заранее разрешённого назначения. Список допустимых адресов должен храниться и проверяться сервером. Если внешний адрес необходим, его нужно сопоставлять с allowlist.

**`03:00:21–03:01:55` — Ведущий и участники.** Участники уточняют, где должен находиться список разрешённых направлений. Ответ: на backend/сервере, а не в клиентском коде. Ведущий возвращается к той же логике, что и в A01: клиентский параметр не является источником доверия; сервер сопоставляет запрошенное значение с собственным разрешённым перечнем.

### `03:02:07–03:05:42` — выполнение команд ОС `[частично неразборчиво]`

**`03:02:07–03:04:49` — Ведущий и участники.** Затрагивается сценарий, где контролируемые пользователем параметры попадают в обработку системой как код или команда ОС. По смыслу это **инъекция команд ОС** `[восстановлено по смыслу; формулировка существенно повреждена]`. Последствие — выполнение команд с правами приложения. Ведущий формулирует общий приоритет: по возможности вообще не передавать пользовательские данные в интерпретатор команд; если выполнение системных действий неизбежно, допустимы только жёстко заданные операции, allowlist и минимальные привилегии.

**`03:04:49–03:05:42` — Диалог.** Обсуждается, может ли локальный контроль запускаемых программ помочь в таком сценарии. Вывод в этой части неполный: защита среды может быть полезна как дополнительный слой, но не исправляет первопричину в приложении.

---

## A06 — Небезопасный дизайн

### `03:05:42–03:11:40` — ошибки бизнес-логики и отрицательное количество

**`03:05:42–03:07:02` — Ведущий.** Небезопасный дизайн описывается как ошибочные допущения в бизнес-логике и архитектуре. Функция может быть технически реализована «правильно» в узком смысле, но позволять недопустимое действие, если разработчики не сформулировали нужные ограничения. Такой класс ошибок трудно полностью обнаруживать автоматически, поскольку он сильно зависит от контекста конкретного продукта.

**`03:07:02–03:09:18` — Ведущий.** Учебный пример — количество товара в корзине. По бизнес-логике количество не должно быть отрицательным, однако отсутствие серверной проверки может допустить отрицательное значение. При расчёте итоговой суммы это способно дать отрицательную цену и фактически зачислить средства пользователю. Второй упомянутый сценарий — некорректно реализованный возврат товара или работа с электронными товарами.

**`03:09:18–03:10:24` — Ведущий.** Ограничения следует обеспечивать не только в интерфейсе, но и на сервере, а при возможности — на уровне СУБД: домен значений, диапазон и запрет недопустимых состояний. Это создаёт несколько независимых уровней защиты.

**`03:10:03–03:11:40` — Ведущий.** Нормализованная практика — **ЛР_6 — «Время расплаты (отрицательное количество → злоупотребление бизнес-логикой)» (A06)**. Участникам предлагается в локальной учебной среде проверить, как отрицательное количество влияет на корзину и кошелёк. Подчёркивается педагогическая цель: увидеть первопричину и затем сформулировать профилактику, а не просто «решить challenge».

### `03:11:40–04:22:42` — завершение практики и разрыв фрагмента

**`03:11:40–03:17:18` — Ведущий и участники.** Ведущий подводит итог лекционной части и отмечает, что лабораторные задания дают «низко висящие плоды»: в учебном приложении можно быстро увидеть результат, но цель — понять, какую проблему демонстрирует задание. Далее звучит переход к следующему практическому блоку, вероятно ЛР_4–ЛР_6; название блока и организационные детали в этой части повреждены.

> **[Разрыв фрагмента: 03:17:18–04:22:42. Содержание не реконструируется.]**

---

## Блок о безопасности ИИ и обучении

### `04:22:42–04:28:42` — ввод и источники актуальных рекомендаций

**`04:22:42–04:24:50` — Второй ведущий.** Сообщается, что заключительный блок будет более дискуссионным: предлагается обсудить состояние образования и то, чему учить в быстро меняющейся области. Ведущий представляется как сотрудник команды продуктовой безопасности; имя и некоторые должностные детали текст передаёт ненадёжно.

**`04:24:50–04:27:30` — Второй ведущий.** Тема делится на две части, продолжающиеся в этот и следующий день. Центральный вопрос — как обучать безопасности на фоне широкого распространения генеративного ИИ. Ведущий обещает не столько перечислять риски, сколько показать, где брать современную актуальную информацию и как использовать существующие рекомендации при разработке и обучении.

**`04:27:30–04:28:42` — Второй ведущий.** Упоминаются материалы OWASP по рискам для больших языковых моделей и рекомендации по безопасной реализации ИИ-систем. Точное название документа и версия в этой части распознаны неустойчиво, поэтому не фиксируются как достоверные. Основной тезис: безопасность следует переносить в процесс проектирования и разработки, а не оставлять только на финальное тестирование.

### `04:28:42–04:36:12` — риски ИИ-систем, данные и цепочка поставок

**`04:28:42–04:31:29` — Второй ведущий.** Вместо изобретения собственного перечня рисков предлагается брать действующие публичные классификации и следить за их обновлениями. Отмечается, что новые версии материалов отражают сдвиг от изолированных моделей к агентным системам. В текст фигурируют годы и даты ревизий, но они повреждены, поэтому документ не фиксирует их как факт.

**`04:31:29–04:34:21` — Второй ведущий.** Проблемы цепочки поставок сохраняются и в ИИ: модель, данные, компоненты и инфраструктура образуют более сложный набор зависимостей. Поднимается тема доверенного ИИ: надо понимать, на каких данных построена модель, как они влияют на результаты и как проверять происхождение компонентов.

**`04:34:21–04:36:12` — Второй ведущий.** Трудность контроля обучающих данных иллюстрируется простым примером: корпоративная база знаний может содержать противоречивые и устаревшие документы. Даже при известном внутреннем наборе данных нельзя механически считать ответы модели верными. Ведущий подчёркивает необходимость проверять качество и актуальность источников, а не только удобство ответа.

### `04:37:08–04:45:37` — сервисы, системные инструкции, контекст и галлюцинации

**`04:37:08–04:39:00` — Второй ведущий.** Утечки данных происходят не только в «новых» ИИ-инструментах: аналогичный риск есть у любых внешних онлайн-сервисов, куда отправляются корпоративные документы, например для преобразования файлов. Следовательно, вопрос классификации и допустимости передачи данных остаётся базовым.

**`04:39:00–04:41:21` — Второй ведущий.** Отдельно рассматриваются агентные системы и их составляющие. текст частично искажает термины, но по контексту названы системная инструкция (**system prompt**) и векторные представления / хранилища (**embeddings / vector store**) `[термины восстановлены по смыслу]`. Системная инструкция задаёт модель поведения и ограничения; её раскрытие может быть нежелательным. Модель не становится источником достоверной информации за пределами своих данных и подключённых источников.

**`04:41:21–04:44:13` — Второй ведущий.** Разбирается параметр температуры: с ростом случайности модель чаще формирует варианты, которые выглядят правдоподобно, но могут быть выдуманы. Приводится опыт поиска несуществующего метода во фреймворке: модель убедительно «придумывала» API. Для критических операций нужен человек, который проверяет результат и не превращает ответ модели в безусловную инструкцию.

**`04:44:13–04:45:37` — Второй ведущий.** Поднимается проблема оценки качества моделей. Общие бенчмарки не дают гарантии правильности в конкретной организации или предметной области. Важны тестовый набор, контекст применения, точность и механизм контроля человеком; часть фразы об оценочных характеристиках неразборчива.

### `04:45:37–04:50:49` — актуальность, подключённые источники и обновления

**`04:45:37–04:46:30` — Второй ведущий.** Для получения актуальной информации модель или агент может обращаться к внешним ресурсам либо к доступным внутри организации данным. Такой механизм полезен, но не снимает вопрос о доверии к источникам, ограничениях доступа и корректности извлечения информации.

**`04:46:30–04:49:54` — Второй ведущий.** Обсуждается стоимость работы с данными и моделями, а затем — риски обновления компонентов. На фоне инцидентов цепочки поставок нельзя считать любое обновление автоматически безопасным: новая версия может исправить одну проблему и привнести другую. Приводится, но не раскрывается полностью, пример инцидента вокруг платформы/сервиса моделей; названия и детали в этой части слишком искажены для достоверной фиксации.

**`04:49:54` — Участник.** Просит дать определение агенту.

### `04:50:49–04:56:38` — что считать агентом: дискуссия о терминологии

**`04:50:49–04:52:47` — Второй ведущий и участник.** Первое объяснение: агентная система взаимодействует с языковой моделью и предоставляет ей набор инструментов. Участник просит более простую и строгую формулировку и замечает, что у разных авторов и документов термин «agent» трактуется по-разному.

**`04:52:47–04:55:48` — Второй ведущий.** Рабочее определение в рамках занятия: агентная система — это не только прямой запрос к модели и получение текста; она даёт модели доступ к внешним инструментам, позволяет получить результаты их работы и использовать эти результаты при формировании ответа. Ведущий осторожно отмечает, что терминология пока не вполне устоялась. Обсуждается также автономность: модель может выбрать вызов доступного инструмента, но окончательная архитектура и границы полномочий задаются системой.

**`04:55:48–04:56:38` — Второй ведущий.** В качестве примера упоминается известный отечественный фреймворк создания агентов, но его название текст передаёт ненадёжно. Важен не бренд, а типовая конструкция: модель → инструмент → результат инструмента → новый ответ модели.

### `04:56:38–04:59:20` — стандартизация и непрерывная актуализация обучения

**`04:56:38–04:57:34` — Второй ведущий.** Упоминается работа над проектом национального стандарта по безопасной разработке систем искусственного интеллекта. Статус, номер и участники в формулировке не подтверждены, поэтому фиксируется только как реплика занятия, а не как нормативный факт.

**`04:57:47–04:59:20` — Второй ведущий.** Возвращается к задаче преподавателя: учебные программы и материалы быстро устаревают, поэтому их нужно регулярно актуализировать. В числе проверок ИИ-систем называются проверка данных, сочетаний данных и получаемых ответов. Модель, подключённая к страницам или инструментам, может получать более свежий контекст, но и сгенерированный ею код/совет по безопасности требует отдельной проверки.

---

## Фрагмент 3

### `00:00:00–00:03:38` — завершение дня: контроль знаний и педагогическая цель

**`00:00:00–00:00:56` — Участник и ведущий.** Начало реплики повреждено. Затем обсуждается, как получить адекватную оценку результатов обучения. Ведущий переводит разговор к исходному вопросу: «зачем мы учим и какой результат хотим получить?» Противопоставляются формальное проведение занятия и реальное обучение; контроль знаний нужен, но его форма может быть разной.

**`00:00:56–00:01:42` — Диалог.** Участники обсуждают, что существующая форма контроля не является единственно возможной. Конкретные предложения в этой части неразборчивы. Зафиксирован общий тезис: нельзя оценивать только факт выполнения задания, не связывая оценку с целью обучения.

**`00:01:42–00:02:31` — Участники.** Идёт эмоциональная дискуссия о строгости преподавателей, требованиях и жизненной ситуации студентов. Большая часть реплик фрагментарна, поэтому дословная реконструкция была бы недостоверна. Содержательный вывод не извлекается увереннее, чем: критерии контроля должны быть соразмерны цели и аудитории.

**`00:02:45–00:03:38` — Ведущий / участники.** Формально завершается день: участникам предлагают подумать над затронутыми вопросами; один из участников обещает на следующий день показать пример или проблему, с которой столкнулся при выгрузке/оформлении материалов `[неразборчиво]`. Звучат благодарности и прощание до завтра.

---