fix

2_0_vulns/LLM07_SystemPromptLeakage.md

@@ -1,8 +1,8 @@
-## LLM07:2025 Утечка системного промпта
+## LLM07:2025 Утечка системных инструкций
 
 ### Описание
 
-Уязвимость утечки системного промпта в LLM связана с риском, что системные инструкции или промпты, используемые для управления поведением модели, могут содержать чувствительную информацию, которую не предполагалось раскрывать. Системные промпты предназначены для того, чтобы направлять вывод модели в соответствии с требованиями приложения, но они могут случайно содержать конфиденциальные данные. Если эти данные обнаружены, их можно использовать для проведения других атак.
+Уязвимость утечки системных инструкций (промпта) в LLM связана с риском, что системные инструкции или промпты, используемые для управления поведением модели, могут содержать чувствительную информацию, которую не предполагалось раскрывать. Системные промпты предназначены для того, чтобы направлять вывод модели в соответствии с требованиями приложения, но они могут случайно содержать конфиденциальные данные. Если эти данные обнаружены, их можно использовать для проведения других атак.
 
 Важно понимать, что системный промпт не следует рассматривать как секрет и использовать в качестве меры безопасности. Соответственно, такие чувствительные данные, как учетные данные, строки подключения и т. д., не должны содержаться в языке системного промпта.
 
@@ -13,9 +13,9 @@
 ### Общие примеры рисков
 
 #### 1. Раскрытие чувствительной функциональности
-  Системный промт может раскрывать важные детали системы, такие как API-ключи, учетные данные базы данных или внутреннюю архитектуру, что делает приложение уязвимым для несанкционированного доступа. Например, раскрытие типа используемой базы данных может привести к атакам через SQL-инъекции.
+  Системный промпт может раскрывать важные детали системы, такие как API-ключи, учетные данные базы данных или внутреннюю архитектуру, что делает приложение уязвимым для несанкционированного доступа. Например, раскрытие типа используемой базы данных может привести к атакам через SQL-инъекции.
 #### 2. Раскрытие внутренних правил
-  Системные промты могут раскрывать информацию о внутренней логике приложения, такой как лимиты транзакций или максимальная сумма кредита, что может помочь злоумышленникам обойти меры безопасности или использовать уязвимости системы. Например, если чат-бот банка раскрывает лимит транзакции или максимальную сумму кредита, злоумышленник может обойти эти проверки безопасности.
+  Системные промпты могут раскрывать информацию о внутренней логике приложения, такой как лимиты транзакций или максимальная сумма кредита, что может помочь злоумышленникам обойти меры безопасности или использовать уязвимости системы. Например, если чат-бот банка раскрывает лимит транзакции или максимальную сумму кредита, злоумышленник может обойти эти проверки безопасности.
     >"Лимит транзакции установлен на уровне $5000 в день для одного пользователя. Общая сумма кредита для пользователя составляет $10,000".
   Эта информация позволяет злоумышленникам обходить средства безопасности приложения, такие как выполнение транзакций, превышающих установленный лимит, или превышение общей суммы кредита.
 #### 3. Раскрытие критериев фильтрации
@@ -28,20 +28,20 @@
 
 ### Стратегии предотвращения и смягчения рисков
 
-#### 1. Разделение чувствительных данных и системных промтов
-  Избегайте включения чувствительной информации, такой как учетные данные или роли пользователей, непосредственно в системные промты. Храните эти данные отдельно в защищенных средах, к которым модель не имеет доступа.
-#### 2. Избегайте использования системных промтов для строгого контроля поведения
-  Не полагайтесь на системный промт для обеспечения критической логики приложения. Вместо этого используйте внешние системы безопасности для мониторинга и контроля правил, таких как фильтрация вредоносного контента или контроль поведения.
+#### 1. Разделение чувствительных данных и системных промптов
+  Избегайте включения чувствительной информации, такой как учетные данные или роли пользователей, непосредственно в системные промпты. Храните эти данные отдельно в защищенных средах, к которым модель не имеет доступа.
+#### 2. Избегайте использования системных промптов для строгого контроля поведения
+  Не полагайтесь на системный промпт для обеспечения критической логики приложения. Вместо этого используйте внешние системы безопасности для мониторинга и контроля правил, таких как фильтрация вредоносного контента или контроль поведения.
 #### 3. Реализация защитных механизмов
   Используйте независимые защитные механизмы за пределами LLM для проверки и подтверждения того, что выводы модели соответствуют безопасности. Это поможет обнаружить отклонения или утечку, которая может представлять угрозу.
 #### 4. Обеспечение независимого контроля безопасности
   Критически важные меры управления, такие как разделение привилегий, проверка границ авторизации и подобные, не должны делегироваться LLM, будь то через системный промпт или другим способом. Эти меры должны выполняться детерминированно и быть поддающимися аудиту, а LLM (на данный момент) не подходят для этого. В случаях, когда агент выполняет задачи, требующие разных уровней доступа, следует использовать несколько агентов, каждый из которых настроен с минимальными привилегиями, необходимыми для выполнения требуемых действий.
 ### Примеры сценариев атак
 
 #### Сценарий #1
-   Системный промт содержит учетные данные для инструмента, к которому LLM имеет доступ. Утечка промта позволяет злоумышленнику использовать эти данные для несанкционированного доступа.
+   Системный промпт содержит учетные данные для инструмента, к которому LLM имеет доступ. Утечка промпта позволяет злоумышленнику использовать эти данные для несанкционированного доступа.
 #### Сценарий #2
-  Злоумышленник извлекает системный промт, который запрещает генерировать оскорбительный контент, внешние ссылки и выполнение кода. Злоумышленник использует атаку на внедрение промта, чтобы обойти эти защитные механизмы и выполнить удаленную команду.
+  Злоумышленник извлекает системный промпт, который запрещает генерировать оскорбительный контент, внешние ссылки и выполнение кода. Злоумышленник использует атаку на внедрение промпта, чтобы обойти эти защитные механизмы и выполнить удаленную команду.
 
 ### Ссылки на источники
 

2_0_vulns/LLM08_VectorAndEmbeddingWeaknesses.md

@@ -1,8 +1,8 @@
-## LLM08:2025 Уязвимости Векторов и Эмбэддингов
+## LLM08:2025 Уязвимости Векторов и Эмбеддинги
 
 ### Описание
 
-Уязвимости векторов и эмбэддингов представляют собой серьезные риски безопасности в системах, использующих метод **Retrieval Augmented Generation** (RAG) с большими языковыми моделями (LLM). Недостатки в том, как генерируются, хранятся или извлекаются векторы и эмбеддинги, могут быть использованы злоумышленниками для внедрения вредоносного контента, манипулирования выводами модели или доступа к чувствительной информации.
+Уязвимости векторов и эмбеддинги представляют собой серьезные риски безопасности в системах, использующих метод **Retrieval Augmented Generation** (RAG) с большими языковыми моделями (LLM). Недостатки в том, как генерируются, хранятся или извлекаются векторы и эмбеддинги, могут быть использованы злоумышленниками для внедрения вредоносного контента, манипулирования выводами модели или доступа к чувствительной информации.
 
 Retrieval Augmented Generation (RAG) — это метод адаптации модели, который улучшает производительность и контекстную релевантность ответов от LLM-приложений, комбинируя предварительно обученные языковые модели с внешними источниками знаний. Для этого используются механизмы векторов и эмбеддингов. (См. #1)
 
@@ -12,7 +12,7 @@ Retrieval Augmented Generation (RAG) — это метод адаптации м
   Недостаточные или неправильно настроенные меры контроля доступа могут привести к несанкционированному доступу к эмбеддингам, содержащим конфиденциальную информацию. Если управление доступом не организовано должным образом, модель может извлечь и раскрыть персональные данные, собственническую информацию или другие чувствительные данные. Неавторизованное использование защищенных материалов или несоответствие политикам использования данных во время дополнения может привести к юридическим последствиям.
 #### 2. Утечки информации из разных контекстов и конфликты данных федерации знаний
   В многопользовательских средах, где несколько классов пользователей или приложений используют одну и ту же векторную базу данных, существует риск утечек контекста между пользователями или запросами. Ошибки конфликта знаний федерации данных могут возникать, когда данные из разных источников противоречат друг другу (См. #2). Это также может происходить, когда LLM не может заменить старые знания, полученные в процессе обучения, новыми данными из Retrieval Augmentation.
-#### 3. Атаки на инверсию встраиваний
+#### 3. Атаки на инверсию эмбеддингов
   Злоумышленники могут использовать уязвимости для инверсии эмбеддингов и восстановления значительного объема исходной информации, что ставит под угрозу конфиденциальность данных (См. #3, #4).
 #### 4. Атаки с отравлением данных
   Отравление данных может происходить как умышленно со стороны злонамеренных игроков (См. #5, #6, #7), так и непреднамеренно. Отравленные данные могут поступать от внутренних или внешних неверифицированных поставщиков данных, что ведет к манипуляциям в выводах модели.