Уязвимости в дата-репозиториях. Обзорно главное

Репозитории для анализа данных и ML - зона повышенного риска ⚠️. Быстрое прототипирование, работа с чувствительными данными и специфичные инструменты создают уникальные векторы атак.
Вот ключевые из них:

1. 🤫 Секреты в коде.
Самая распространённая и критичная уязвимость. Хардкод API-ключей (например, к AWS S3, OpenAI, базам данных), токенов доступа и даже паролей прямо в Jupyter Notebook, конфигурационных файлах и скриптах. При попадании такого кода в публичный репозиторий злоумышленники получают прямой доступ к платным сервисам и данным.

Лечение
‘git grep’ + ‘truffleHog’, ротация ключей, менеджер секретов.

2. 🧑‍💻 RCE через десериализацию
Библиотеки pickle и joblib - стандарты для сохранения ML-моделей в Python - небезопасны. Десериализация файла из ненадёжного источника может привести к выполению произвольного кода на машине.

Лечение
yaml.safe_load(), ONNX, sandbox.

3. 💻 Открытые ноутбуки
Юпитер ноутбуки, развёрнутые с настройками по умолчанию, часто остаются доступными для всех в сети (особенно в облаках). Пароли, токены и результаты запросов с конфиденциальными данными могут быть видны в интерфейсе.

Лечениеты в коде.
‘nbstripout’ аудит перед коммитом. Регулярно аудить права доступа (IAM) к S3-бакетам, базам данных и другим ресурсам. Принцип наименьших привилегий - база 🤭.

4. 🙈

DoS через загрузку моделей. 
Эндпоинт для загрузки моделей без проверки размера файла может быть атакован путём отправки огромного файла, что приводит к переполнению диска и отказу в обслуживании (Denial-of-Service).

Data Poisoning. Злонамеренное изменение обучающих данных для подрыва работы модели (например, добавление в выборку для классификации спама писем с определённым словом, помеченных как "не спам").

Adversarial Attacks. Специально сконструированные входные данные, предназначенные для обмана модели (например, незаметные для человека изменения в изображении, заставляющие модель видеть не то, что есть на самом деле)

Лечение
Pre-commit хуки, сканирование в CI/CD, обучение DS основам безопасности.Менеджеры секретов, безопасные форматы сериализации, инструменты для мониторинга (Evidently AI, WhyLabs).

#DataSecurity #MLSecurity #PickleRCE #SecretsManagement #DevSecOps

🔗 Полезные ссылки:
1. TruffleHog— сканер секретов
2. nbstripout — очистка ноутбуков
3. OWASP Top 10 — главные уязвимости

Два «питомца» для ИИ-пентеста: CAI и PentAGI

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

CAI

Открытый фреймворк, реализующий функциональность ассистента пентестера.

• Сканы, поиск уязвимостей (SQLi, XSS, LFI) и базовая эксплуатация — всё в режиме автономного агента.

• Дружит с 300+ LLM (от OpenAI до Ollama), логирует действия через Phoenix и ставит guardrails, чтобы бот не сломал сам себя.

• В CTF-замерах оказался в среднем в 11 раз быстрее человека, а на отдельных задачах — в 3600 раз.

• Уже отмечен в TryHackMe и Hack The Box: находит бреши, читает /etc/passwd, но пока далёк от идеала — цепочки атак увы ещё не особо осиливает. Кожаный мешок с соответствующей экспертизой где-то рядом всё же нужен — агент далеко не всегда безошибочен и не во всем автономен.

PentAGI

По-настоящему автономный ИИ-пентестер со встроенными тулзами и собственной «долгой памятью»

• Более 20 классических инструментов (nmap, Metasploit, sqlmap и т.п.) прямо из коробки.

• Встроенный браузер и поиск (Google, DuckDuckGo, Tavily) для разведки.

• Векторная база знаний (PostgreSQL + pgvector), чтобы помнить свои прошлые результаты и выстраивать сложные цепочки последовательных атак в рамках одного дерева.

• Отчёты и метрики в Grafana/Prometheus, всё в Docker, разворачивается относительно легко.

• Ориентирован на топовые облачные LLM и весьма прожорлив до токенов (но оно того стоит).

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

...или пугать, это уж как посмотреть 😬

Как разработчику быстро вкатиться в тему LLM? Часть 5 (заключительная)

Часть 4

5. Мультиагентные системы и протоколы взаимодействия

Работая над нетривиальном агентом, разработчик может столкнуться с ситуацией, когда реализуемая им логика перестает укладываться в концепцию агента-соло. Например, когда разделение ролей, параллелизм, изоляция рисков или масштабируемость дают измеримую выгоду по качеству, времени или стоимости. Иногда перестает хватать контекстного окна, или промпт оказывается переусложненным из-за разнородности задач, или возникает необходимость использовать несколько различных моделей. В таких случаях переходят от одноагентных систем к мультиагентным (MAS), где каждый из агентов решает часть общей задачи. В такой системе нет единого центра – координация происходит либо за счёт прямого общения агентов, либо через некоторую общую среду. Основные концепции MAS неплохо описаны в этой статье.

Вот лишь некоторые возможные паттерны ролей агентов в MAS:

• Planner → Executors: планировщик дробит задачу, исполнители — узкоспециализированные агенты.

• Critic/Verifier: независимая проверка фактов/ограничений, «красные команды», контрафактуальная проверка.

• Tool-specialists: агенты-обёртки над конкретными инструментами (Bash, Snowflake, Jira).

• Memory/RAG-агенты: отдельный агент управление знанием (индексация, извлечение, цитирование).

О проектировании MAS неплохо написано тут.

Агентам в MAS нужно как-то взаимодействовать с окружением и друг-другом. С этой целью были созданы протоколы A2A от Google, и MCP от Anthropic. Поверхностно ознакомиться с ними поможет эта статья. Вкратце:

• MCP – представляет собой «универсальный разъём a-la USB» между LLM-агентом и внешними инструментами. Протокол вводит три роли участников: Host (основное приложение/интерфейс, где работает агент), Client (компонент-встроенный коннектор при модели) и Server (поставщик инструментов или данных). Фактически, Host координирует диалог и хранит общую память, Server предоставляет реализацию какого-то действия (например, доступ к базе знаний или вызов внешнего API), а Client-соединение позволяет модельному агенту запрашивать у Host доступные инструменты и вызывать их. За счёт этого агент может использовать произвольные инструменты через единый протокол, не требуя от разработчика писать для каждого API свой код обработки.

• A2A же — протокол «агент-агент», дополняющий MCP: если MCP фокусируется на подключении инструментов, то A2A стандартизирует коммуникацию между независимыми агентами (каждый из которых может быть отдельным сервисом). Агент в A2A публикует свой «карточку» с описанием возможностей, а другие агенты могут посылать ему задания через HTTP. В сочетании, MCP и A2A покрывают разные уровни: MCP – подключение одного агента к инструментам и контексту, A2A – связь между разными агентами.

Для начала работы с MCP неплохо также ознакомиться и с этой статьей.

Разумеется, изобретать заново архитектуры MAS и реализовывать протоколы взаимодействия особой необходимости нет — существуют специализированные фреймворки, в которых «всё уже украдено до нас». Наиболее популярным из них является CrewAI: Python-фреймворк, упрощающий создание и оркестрацию группы агентов. В нём вводятся основные сущности – Agent (автономный агент с определённой ролью и целями), Task (задача для агента), Crew (группа агентов, объединённых общей целью), Tool (внешний инструмент, которым могут пользоваться агенты). Фреймворк берёт на себя маршрутизацию задач между агентами и сбор результатов. Стартовать с ним поможет эта статья.

Более подробный обзор доступных открытых решений для разработки ИИ-агентов представлен здесь.

Задачка на потренироваться:

Доработать coding-агента из предыдущего задания, добавив к нему verifier-агента на базе другой reasoning-модели, верифицирующего полученные результаты.

———

На этом, серия постов про вкатывание в разработку для LLM подошла к концу. Но не рубрика «LLM для разработчиков». Stay tuned, как говорится☺️

Awesome AI Apps - технический гид по созданию LLM-приложений

🦙 Репозиторий awesome-ai-apps - коллекция продакшен-примеров для построения приложений на базе LLM. Внутри — проекты на LangChain, LlamaIndex + habr, CrewAI, Agno, Mastra, Nebius AI Studio, GibsonAI и много других полезных!..

Что можно найти:
- минимальные прототипы на базе OpenAI SDK, LangGraph, Camel AI — идеальны для экспериментов,
- готовые сценарии вроде финансового трекера, HITL-агента или бот для веб-автоматизации,
- демонстрации работы с Model Context Protocol (MCP) для репозиториев, документов или бд. Это особенно актуально для стандартизации, взаимодействия между агентами и внешними сервисами. Ну и тем, кто оттягивает знакомство с MCP, еть уже готовые анализ GitHub-репо, QnA по документации, работа с Couchbase и GibsonAI DB. Не оттягивайте 🤪.
- агенты с persistent memory (на Memori), которые позволяют строить более контекстно-зависимые системы (например, arXiv Researcher или Social Media Agent).
- примеры Agentic RAG (они не устарели!!!) с использованием Qdrant, Exa, LlamaIndex. Поддержка работы с PDF, кодом и OCR (Gemma3).
- комплексные пайплайны (например, Meeting Assistant, который конвертирует митинг в задачи и заметки, или Finance Service Agent на FastAPI)

Что под капотом (продублируем для удобства твоего гугл эдвэнсед, большинство ссылок выше) и ждет, когда затащишь себе?
🫰 LangChain + LangGraph для оркестрации агентов.
🫰 Agno как фреймворк для построения agentic workflows.
🫰 CrewAI для мультиагентных исследований.
🫰 LlamaIndex как основа RAG и документных ассистентов.
🫰 Memori для хранения контекста и долгосрочной памяти.
🫰 Nebius AI и Bright Data — как инфраструктурные провайдеры.

Установка (единый паттерн):

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/<project_name>
pip install -r requirements.txt

🧘‍♀️ Каждый проект снабжен своим README.md, а там можно и сразу стартовать.

Этот репозиторий можно в чистом виде 🏖️ R&D-песочница, быстро тестировать разные стеки, паттерны взаимодействия агентов, интеграции MCP и реализацию RAG. Гении, как известно, воруют 👌

#AI #LLM #RAG #LangChain #LlamaIndex #CrewAI #Agno #Memori #AIagents #opensource #MCP #Python #MachineLearning #GenerativeAI

Давно хотел поделиться этой диаграммой. Впервые появившись в серии публикаций «Six Pillars of DevSecOps», она прошла некоторые эволюционные этапы, один из которых присутствует у вашего покорного слуги в офисе, в качестве подаренного коллегами на ДР визуала на пол стены 🎨

Комментировать тут особо нечего. Идеальный Secure SDLC, к которому надо стремиться. Хотя, тут ещё есть что добавить, как минимум — в плане защиты от supply-chain атак, как по мне.

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

Простая и наглядная иллюстрация, которая будет постоянно напоминать о том, почему у вас в проекте все плохо с безопасностью 😁

UTCP: новая альтернатива MCP

Универсальный протокол вызова инструментов (Universal Tool Calling Protocol, UTCP) представляет собой смену парадигмы взаимодействия ИИ-агентов с внешними инструментами и сервисами. В отличие от традиционных подходов, требующих серверов-обёрток и прокси-слоёв, UTCP обеспечивает прямое взаимодействие между агентами ИИ и инструментами через их собственные эндпоинты.

Сегодня, чтобы подключить ИИ к внешним инструментам, разработчики вынуждены писать обёртки: агент → MCP-сервер → инструмент, и неизбежно сталкиваются с:

• лишними задержками и точками отказа;
• дублированием безопасности;
• необходимости в инфраструктуре ради вторичного посредника.

UTCP убирает необходимость в такой прослойке. В целом, сравнение UTCP и MCP можно свести к следующему: UTCP — это «мануал» (описание инструмента), а MCP — «посредник» (сервер, оборачивающий инструмент). UTCP предполагает архитектуру прямого взаимодействия «агент → инструмент», тогда как MCP — «агент → MCP-сервер → инструмент».

Отсюда вытекают и все преимущества UTCP:

• Инфраструктура: UTCP не требует новых сервисов (достаточно добавить endpoint в существующий API), MCP же нуждается в отдельном сервере(-ах) для каждого набора инструментов.

• Производительность: UTCP выполняет вызов за один шаг (агент сразу обращается к API инструмента), MCP добавляет “двойной прыжок” через посредника, увеличивая накладные задержки.

• Безопасность: UTCP использует нативную аутентификацию/авторизацию инструмента, MCP вынужден реализовывать и хранить учетные данные на своей стороне, что расширяет поверхность атаки.

• Поддержка протоколов: UTCP гибок (HTTP, WebSocket, CLI, gRPC и т.д. – вплоть до чтения локальных файлов), а MCP ограничен форматом JSON-RPC поверх единственного транспорта.

• Поддержка и масштабирование: UTCP-интеграции практически не требуют поддержки (статический JSON с описанием), масштабируются вместе с существующим сервисом; MCP-серверы же добавляют постоянные заботы (деплой, обновления, мониторинг, масштабирование отдельно от основного API).

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

🐍 Пример клиента:

import asyncio
from utcp.client import UtcpClient
from utcp.shared.provider import HttpProvider

async def main():
    # Инициализируем UTCP-клиента
    client = await UtcpClient.create()
    # Определяем HTTP-провайдер (manual endpoint) для сервиса погоды
    manual_provider = HttpProvider(
        name="weather_service",
        provider_type="http",
        http_method="GET",
        url="http://localhost:8000/utcp"  # URL, возвращающий UTCP-описание (manual)
    )
    # Регистрируем инструменты из указанного manual (добавляем описание)
    tools = await client.register_manual_provider(manual_provider)
    print(f"Registered {len(tools)} tools")
    # Вызов инструмента "get_weather" с параметром location
    result = await client.call_tool(
        "weather_service.get_weather",
        arguments={"location": "San Francisco"}
    )
    print(f"Weather: {result['temperature']}°C, {result['conditions']}")

В случае уже имеющейся MCP экосистемы, доступен также адаптер (пока только для Node.js и Python): utcp-mcp, который позволяет подключить свыше 230 существующих MCP-инструментов через единый сервер, использующий под капотом UTCP. Это облегчает постепенный переход на новый протокол без потери доступа к старым интеграциям.

⚠️ TL;DR:

UTCP (Universal Tool Calling Protocol) позволяет ИИ-агентам напрямую обращаться к API и CLI-инструментам — без промежуточных серверов, JSON-RPC и кастомных «прокладок». Поддерживает HTTP, gRPC, WebSocket, CLI и стримы. Есть SDK для Python, Node.js, Go и MCP-адаптер под Node.js и Python.

Поэзия как джейлбрейк: стихи ломают защиту LLM

Авторы исследования «Adversarial Poetry as a Universal Single-Turn
Jailbreak Mechanism in Large Language Models» протестировали 25 моделей (OpenAI, Anthropic, Google, DeepSeek, Mistral, Meta, Qwen и др.), подавая им опасные запросы… в рифму.

Два эксперимента:

1. 20 вручную написанных стихов о кибератаках, CBRN (химическое, биологическое, радиологическое и ядерное оружие), манипуляциях и потере контроля.
2. 1200 «вредных» промптов из открытого бенчмарка MLCommons AILuminate, автоматически превращённых в стихи.

Результаты оценивали LLM-судьи и люди. Метрика — ASR (Attack Success Rate), доля небезопасных ответов.

Результаты

Ручные стихи: 62% средний успех атаки
• gemini-2.5-pro: 100%
• DeepSeek / Mistral / Qwen: 80–95%
• Лишь Claude и GPT-5-nano удержали 0–10%.

Автогенерированные стихи:
• Проза: 8% ASR
• Стихи: 43% ASR → рост в 5 раз

По темам:

• Приватность: +45 п.п.
• Ненасильственные преступления: +39 п.п.
• CBRN: +38 п.п.

Обсуждение кибератак в стихах дало 84% успеха 🤩

Почему поэзия работает

1. Фильтры обучены на прозе, а метафоры и ритм «смещают» текст от ожидаемого распределения.
2. Модели воспринимают стихи как безопасный жанр и снижают строгость отказов.
3. Большие модели уязвимее — лучше понимают переносный смысл, но не успевают применить защитные эвристики.
4. Эффект универсален: наблюдается у всех провайдеров и почти во всех категориях вреда.

Что это значит

• Текущие бенчмарки и сертификация (в духе EU AI Act) переоценивают безопасность — они не проверяют стилистические обходы.
• Нужны новые тесты, где намерение пользователя выражено не только прямым текстом, но и через поэзию, нарратив, юмор и бюрократический стиль.
• Без этого защиты условны: LLM остаются уязвимыми к самым простым «поэтическим» джейлбрейкам.

⚠ TL;DR:

Исследование показало: достаточно переписать вредный запрос в стихах — и защита крупных языковых моделей рушится. Поэтическая форма становится универсальным одностадийным джейлбрейком: для некоторых моделей доля небезопасных ответов превышает 90%, в среднем рост атак-успеха — в 4–5 раз по сравнению с прозой.

Как разработчику быстро углубиться в тему LLM? Часть 1

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

1. Токенизация и эмбеддинги
2. Механизмы внимания
3. Архитектуры трансформеров
4. Популярные архитектуры LLM
5. Проблемы и решения при работе с LLM
6. Обучение моделей
7. Эффективный инференс и деплой

Звучит, как план, правда? ☺️

1. Токенизация и эмбеддинги

Современные большие языковые модели работают на основе векторных представлений и механизма внимания, заложенного в архитектуру трансформеров. Первым шагом в обработке текста является токенизация — разбиение входной строки на токены, которые могут представлять собой слова, части слов или отдельные символы. Компиляторщиков и разработчиков средств анализа кода этот термин может слегка смутить, т.к. в NLP токенами не всегда принято считать то, что является ими в формальных языках. На практике широко используется subword-токенизация, например Byte-Pair Encoding: так, слово unhappiness может быть преобразовано в последовательность «un», «happi» и «ness». Такой подход уменьшает размер словаря и позволяет эффективно работать с редкими или ранее невстречавшимися словами.

Каждый токен получает уникальный идентификатор, по которому модель извлекает его вектор из матрицы эмбеддингов. Эмбеддинг — это высокоразмерный числовой вектор, отображающий семантику токена. После токенизации каждый элемент текста фактически превращается в набор чисел, отражающих его смысловые связи. Чем ближе по смыслу токену друг к другу, тем меньшее расстояние между ними в векторном пространстве. Например, вектор для слова apple окажется ближе к fruit, чем к car.

У моделей типа GPT-3 таблица эмбеддингов может быть очень большой: при словаре ~50 000 токенов и размерности эмбеддинга ~12 288 получается матрица порядка 50 000 × 12 288. Однако в современных крупных MoE-моделях, за счет sparse-архитектуры, эти оценки кратно меньше: 2k для 30B, 4k для 235B, например.

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

Познакомиться с этой темой ближе позволит статья «Глубокое погружение в токенизацию», для более глубокого погружения можно упороться в видеолекции (первая, вторая) от ФКН ВШЭ, или от Стэндфорда (выборочно, из первых 6 лекций), если «глубинное обучение» режет слух, и хочется привычного «deep learning».

Для специализированных задач типа анализа исходного кода, существуют отдельные модели эмбеддингов. Так, jina-embeddings-v2-base-code поддерживает английский язык и около 30 языков программирования, способна обрабатывать последовательности до 8192 токенов и оптимизирована для семантического поиска по коду. В таких моделях принципы токенизации и построения эмбеддингов остаются теми же, но словарь и обучающие данные адаптированы к структурам и паттернам программного кода.

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

• code2vec / code2seq: Path-Attention поверх AST
• GraphCodeBERT: Transformer поверх DFG + элементы GNN
• CuBERT: Transformer поверх фич CFG
• Devign: GNN поверх AST+CFG+DFG
• Code T5 / Code T5+: Transformer поверх AST-токенов

Ну и куда же без изучения тематической awesome-подборки, на правах домашнего задания 🤓

Почему мы почти не фокусируемся на работе, и как с этим бороться

Часто случается так, что в конце дня вы ощущаете себя рабом, отпахавшем на галере, с одной стороны, но и с ощущением бесцельно прожитого дня, с другой? Особенно в дни, когда пришлось сорваться в офис с привычной удаленки на несколько встреч? 🤗

Вышедшая на днях статья «The Math of Why You Can’t Focus at Work» утверждает, что большинство проблем с концентрацией легко объясняются не силой воли или дисциплинированностью, а не зависящими от них тремя параметрами, которые можно формализовать в понятную и в чем-то даже изящную систему.

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

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

Ключевые параметры

1. Частота прерываний (λ)

Любой внешний стимул — сообщение, пуш-уведомление, созвон, «разговор на пару минут» — дробит рабочий день на мелкие фрагменты. Рост λ — гарантированная потеря структуры дня, независимо от навыков, настроения собранности.

2. Стоимость возврата в контекст (Δ)

После прерывания нужно время на реконструкцию модели задачи. Среднее Δ выглядит маленьким (5–15 минут), но на масштабе дня превращается в часы «скрытых» потерь.

3. Порог глубокого фокуса (θ)

Для нетривиальных задач нужен минимальный непрерывный интервал. Если временной слот < θ, работа идёт, но ценность почти не растёт — ничем, кроме рутины, заняться не удаётся.

Возможные сценарии

Шумный день

• Около двух десятков прерываний.
• Большинство доступных интервалов не пересекает θ.
• Около 4 часов полезной работы и всего один нормальный блок фокуса.

Формально «работали весь день», фактически — мало в чём продвинулись.

День с контролем среды

• Меньше внешних событий + быстрый возврат в задачу.
• 6+ часов продуктивного внимания.
• Несколько последовательных глубоких интервалов.

Здесь эффект нелинейный: снизили λ на 20–30%, а качество дня выросло кратно.

Что важно

• Вред приносит не количество задач, а фрагментация внимания.
• Одно «вставленное» совещание портит весь рабочий график, разрушая потенциальные интервалы ≥ θ.
• Пинг-культура в чатах увеличивает λ до уровня, где глубокая работа становится статистически маловероятной.
• Без управления этими параметрами невозможно стабильно планировать сроки, качество работы и комплексные задачи.

Автор также собрал симулятор карты рабочих дней, моделирующий предложенную им систему по заданным параметрам (залипнув в котором, можно запросто прощелкать слот-другой глубокого фокуса, btw).

⚠ TL;DR:

Продуктивность — это не дисциплина, а параметры среды.

Управляете прерываниями (λ), сокращаете количество возвратов в контекст (Δ), защищаете фокусные слоты (θ) — получаете системный кратный прирост качества и скорости.

Игнорируете — получаете «рабочие будни», в которых почти ничего не достигнуто, кроме ощущения лютой вымотанности к концу дня.

Уже лишь только ленивый не написал про CVE-2025-55182 aka React2Shell, пересказывая своими словами райтапы, пересказанные ранее другими авторами с пересказанных ещё кем-то постов.

Повторяться смысла нет, но вот ещё раз вспомнить, что делать разработчикам, чтобы не допустить подобную уязвимость у себя в проекте — лишним точно не будет.

✖️ Что НЕ сделали разработчики React'а?

Команда React не предусмотрела надёжную проверку и фильтрацию данных при десериализации входных нагрузок RSC (React Server Components). В результате они могли расширять свойства объектов без достаточной валидации (например, путём инъекции proto), что позволяло загрязнять прототипы (prototype pollution) и выполнять произвольный код на сервере.

✅ Что делать разработчикам?

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

💻💻:

• Используйте структуры данных без прототипа: вместо пустых объектов {} применяйте Object.create(null) или литерал {__proto__: null}. Это предотвратит наследование опасных свойств от Object.prototype.

• При необходимости используйте ассоциативные коллекции — применяйте new Map() и new Set() вместо обычных объектов. У них нет «прототипа» в классическом понимании, и методы вроде .get()/.has() возвращают только значения.

• Замораживайте глобальные прототипы: например, вызов Object.freeze(Object.prototype) (и/или Object.seal) заблокирует добавление или изменение свойств базового прототипа. Это затруднит атаки, но нужно учитывать, что многие библиотеки рассчитывают на динамическое расширение объектов.

• При запуске Node.js можете указать флаг --disable-proto=delete — он полностью удалит свойство __proto__ из стандартных объектов.

• Санитизируйте имена полей при объединении/парсинге JSON: запрещайте или фильтруйте ключи вроде __proto__, prototype, constructor и подобных. Лучше всего – явно разрешать (whitelist) только ожидаемые имена полей и отбрасывать все остальное.

• Избегайте небезопасных merge-функций (например, lodash.merge, рекурсивных функций объединения объектов) при работе с внешними данными. Если мёрдж неизбежен, тщательно проверяйте, как реализована функция: нет ли в ней присвоения прототипов или вызова setattr (в JS – методов вроде Object.assign/reduce).

💻 Python:

• Не используйте pickle, или хотя бы не выполняйте pickle.loads на входных данных. Если нужна сериализация, используйте безопасный формат (JSON, json/yaml без пользовательских конструкторов).

• Избегайте рекурсивного слияния атрибутов объектов из пользовательских словарей. Любая функция типа merge(src, dst) может при наличии поля __class__ или __globals__ обойти границы объекта и изменить класс или глобальные переменные. Проверяйте, что входные данные не содержат ключей, начинающихся с __ или равных именам методов объектов.

• Ограничивайте динамическое добавление атрибутов. При необходимости используйте __slots__ в классах или явно задавайте список полей (например, через dataclasses), чтобы неизвестные атрибуты просто игнорировались. По возможности не добавляйте атрибуты в классы по именам из JSON.

• Проверяйте использование setattr и init: ни в коем случае не допускайте передачи строкового кода или списка методов для выполнения через eval/instance_eval внутри __init__ или других «магических» методов.

• Замораживайте и не раскрывайте конфиденциальные переменные: не давайте внешнему коду доступ к глобальному состоянию приложения (модули, конфиг и т.д.), тем более через __globals__/__class__.

Продолжение — в следующем посте.

Начало — в предыдущем посте.

💻 Ruby:

• Аналогично JS и Python, опасен рекурсивный deep_merge или любое слияние, которое устанавливает инстанс- или класс-переменные на основе данных пользователя.

• Не доверяйте deep_merge на объектах: стандартный Hash#deep_merge безопасен для чистых хешей, но при объединении атрибутов объекта он может добавить методы. Всегда контролируйте, какие атрибуты ставятся через attr_accessor или instance_variable_set. Если используется ActiveSupport или Hashie для слияния, проверяйте, закрыты ли методы (Hashie блокирует переопределение методов, но ключи вида _/! могут обойти защиту).

• Не используйте eval/instance_eval или небезопасный to_proc на пользовательских данных.

• Ограничивайте область действия включаемых модулей: при include/extend убеждайтесь, что приватность методов не «размывается» — по возможности убирайте ненужные методы через undef_method или делайте их private. Это не устранит атаку слияния, но уменьшит «плохой» код, который можно подменить.

• Замораживайте, по мере возможности: Ruby позволяет вызывать freeze на объектах, исключая дальнейшее изменение их переменных. Подумайте о замораживании всех неизменяемых конфигурационных объектов, если это не сломает логику приложения.

🖥 PHP:

• Прямого аналога прототипов тоже нет, но есть опасность перезаписи свойств: функции-слияния с объектов не имеют смысла (результат – stdClass), однако стандартные foreach или (object)$array могут изменить экземпляр класса. Избегайте кода вида foreach($data as $k=>$v) { $obj->$k = $v; } без фильтрации ключей.

• Используйте массивы вместо объектов: например, при json_decode($json) указывайте вторым параметром true, чтобы получить массив, а не объект. Тогда не получится неявно «пролить» данные в объект.

• Проверяйте ключи и поля: если какие-то поля приходят из запроса и затем ставятся в атрибуты объектов — убедитесь, что это ожидаемые поля. Незнакомые ключи — игнорируйте или блокируйте.

• Не используйте unserialize() на пользовательских данных: это другая категория уязвимостей, но тоже позволяет менять внутренние данные объектов. Для передачи сложных структур лучше json_encode/decode с валидацией.

Другие языки:

• В💻 Java и 💻 необходимо следить за безопасностью десериализации и рефлексии (в том числе — неявной, на стороне используемого фреймворка). Например, не внедрять из JSON имена классов/методов напрямую (Class.forName и т.п.); в конфигурационных классах делать поля private final. Используйте sealed или final классы везде, где это возможно. В 👣 и 👣 Rust аналогичная история: в общем подходе по-прежнему нужно валидировать JSON по структуре (Go) и использовать serde/serde_json (Rust) без включения нестандартных поведений.

Как-то так 🤓

⚠ TL;DR:

Лонгрид — не заслуживает внимания, оставайтесь c уязвимыми проектами)

Архитектура безопасности ИИ-агентов в Google Chrome

На фоне добавления в Chrome интеграции с Gemini, и в предверие выхода agentic-фич в браузере, команда Google Security разродилась любопытной статьей на тему их видения архитектуры безопасности всего этого хозяйства.

Основной угрозой для браузера его авторы [заслуженно] считают косвенные промпт-инъекции (indirect prompt injection, IPI), которым оказались подвержены, и недавно вышедшие Comet с Atlas'ом, и уже упомянутая, вышедшая ранее интеграция Chrome с Gemini, и бог его знает, какие ещё браузеры (подробнее почитать об этом можно, например, тут: [1], [2], [3]).

Для борьбы с IPI они предлагают простую (тем и привлекающую) архитектуру, в рамках которой браузер получает отдельную модель-критика — защитный слой, который оценивает каждое действие агента ещё до того, как оно достигнет реального интерфейса. Критик намеренно изолирован от внешнего контента и анализирует только параметры будущего шага, тем самым исключая возможность влияния внешнего контента на его решения.

Чтобы агент не превратился в универсальный механизм доступа ко всему, что видит браузер, вводится концепция «Origin Sets»: агент заранее привязывается к ограниченному набору ориджинов (в терминах, близких к SOP), релевантных решаемой задаче. Причём для каждого устанавливается собственный уровень взаимодействия: чтение, или чтение-запись. Это позволяет контролировать, какие источники он анализирует и где имеет право изменять данные.

Когда же речь заходит о наиболее чувствительных действиях — отправке форм, переводе средств, изменении пользовательских настроек — агент обязан передать решение самому человеку. Лишь после явного подтверждения пользователь разрешает действие, а прозрачный журнал операций даёт возможность понять, как агент пришёл к тому или иному результату. Т.е. здесь предлагается Human-in-the-Loop с обоснованием.

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

⚠ TL;DR:

Google думают, что создали защиту от косвенных промпт-инъекций в контексте agentic-бразуера. По сравнению с попытками предшественников, она, мало того, что просто есть, так ещё и выглядит эстетично.

Но запастись попкорном, на всякий случай — лишним не будет 🍿

🤖 AI Code in the Wild: «хотели, как лучше...»

AI-кодер — будто «стажёр-всезнайка на стероидах»: пишет много и быстро то, что выглядит аккуратно и эстетично. А потом внезапно выясняется, что он по всему GitHub размножил один и тот же уязвимый паттерн...

Авторы опубликованного на днях исследования AI Code in the Wild собрали историю коммитов в топ-1000 репозиториев GitHub за 2022–2025 и отдельно 7000+ изменений кода, связанных с CVE, и на этом попытались измерить, где именно AI уже «живёт» и как он влияет на уязвимости.

Что выяснили:

• AI уже в кодовой базе, в заметной доле, но присутствует неравномерно.

Он особенно любит документацию (~38.6%), заметно залезает в бизнес-логику (~34.5%), а вот в конфигах/данных его уши торчат сильно реже (~9.65%) — видимо, туда его пока не особо пускают, уж больно легко сделать нехорошо продакшену парой токенов.

• У него есть «любимые» классы уязвимостей — и это даже не про сложную бизнес-логику.

В топе — ошибки обработки входных данных (62.7%) и криптографические продолбы (20.6%), оформленные настолько правдоподобно, что не всегда получается сходу их выявить. То есть AI отнюдь не изобретает новые баги, он старательно штампует узкий набор небезопасных идиом, мимикрируя их под нормально выглядящий код.

• По серьезности (CVSS) AI-уязвимости примерно такие же, как человеческие… но чаще торчат в сеть.

По распределению severity статистически авторы большой разницы не нашли (медианы близки), но вот по векторам атак — уязвимости, внесённые AI, слегка чаще оказываются эксплуатируемыми по сети (86.8% против 80.8% у «человеческих»).

• Самый неприятный вывод: AI-индуцированные уязвимости могут размножаться, как шаблоны.

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

Почему это заслуживает внимания:

Исследование аккуратно подводит к идее: в AI-эпоху «доверие» надо переносить с ревью одного PR на весь пайплайн — потому что скорость генерации AI-кода никак не масштабирует внимательность нашего брата. И если AI системно выдает повторяемые типы ошибок, их можно ловить правилами/типами/ограничениями так же системно, не надеясь на героизм ревьюеров.

Btw, описанная ими в статье методика классификации авторства кода (AI или человек), заслуживает отдельного внимания: ансамбль признаков и обучающая выборка из реального человеческого и синтетического AI кода, для получения вероятностной оценки.

⚠ TL;DR:

Это не очередная «AI иногда пишет небезопасно». Авторы берут топ-1000 репозиториев GitHub и тысячи CVE-патчей, детектят AI-код в реальных коммитах, и дальше показывают, что у AI есть повторяемые «любимые» ошибки (особенно в обработке входных данных и криптографии), и они имеют тенденцию размазываться по экосистеме как шаблоны, за счет использования одних и тех же моделей.