Искусство. Код... ИИ?

🗂 Поддержка agentic-проектов в SECURITY.md security-policy-generator (скилл для генерации SECURITY.md с моделью угроз и кастомизированными под проект правилами безопасного кодинга для агентов — подробно рассказывал о нём тут) теперь поддерживает agentic security, для релевантных проектов, покрывая все аспекты OWASP ASI, как моделью угроз, так и правилами генерирования безопасного кода. Пример готового SECURITY.md, сгенеренного новой версией скилла, можно подсмотреть в c0wrk. Btw, я пока так и не смог спровоцировать агента (c0wrk|OpenCode × GLM-5.2|DeepSeek-V4 Pro|GPT-5.6 Sol) сгенерировать уязвимый код в проектах, с построенным этим скиллом SECURITY.md, хотя очень и целенаправленно пытался 🙈 🙌 #безопасность_кода #ИИ_инструменты

🤩 ИИ подвержен мемам (и это — плохая новость) Во время работы над c0wrk, я столкнулся с забавным багом, выяснение причин которого привело к неожиданному выводу. Спека OpenAI требует, чтобы в передаваемой в очередном запросе истории сообщений (том самом контексте) было всегда не пустым одно из двух полей: content (собственно текст, возвращенный LLM'кой) или tool_calls (запросы на вызовы инструментов). ДАЖЕ, если в оригинальном сообщении оба этих поля были пустыми, что вполне возможно, когда модель отвечает в reasoning_content (этим, например, часто грешит DeepSeek). Поэтому в sp4rk — SDK, на котором основан c0wrk, был воткнут костыль на эту тему, вставляющий в пустой content строку "(proceeding)", когда нужно было удовлетворить то условие спеки. Эта вставка осуществлялась только в передаваемую LLM историю, и только тогда, когда само сообщение уже было давно отрисовано в UI чата, что должно было исключить появление этой строки в нём визуально. Тем не менее, рано или поздно, по ходу сессии, эта строка начинала появляться в чате с раздражающей частотой. Я не мог понять, откуда она берется, ведь после её вставки не было ни одного пути в коде, который бы приводил к её отрисовке. И неслабо удивился, когда наконец нашел причину. Эту строку в чат вставляла... сама LLM. Модель, видя повторяющийся в контексте паттерн «когда нечего написать в контенте, там должно быть "(proceeding)"», начинала сама возвращать эту строку вместо пустого контента. А ведь, могло быть и не "(proceeding)", а нечто более осмысленное и побуждающее к действию. Да и замусорить контекст навязчивой конструкцией можно и извне. Формально, эта строка для LLM стала тем, что в маргинальных научных кругах называют мемами. Далеко не все знают, что понятие «мем» появилось задолго до возникновения современного интернета, позволившего человечеству обмениваться забавными картинками. Этот термин ввёл эволюционный биолог Ричард Докинз в 1976 году в своей книге «Эгоистичный ген», для обозначения информационных реплик

Год каналу, а за год накопилось столько всего, что пора сделать навигацию 😑 Уязвимости и AI Security — Superset. Три уязвимости — XSS в NextChat — CVE-2025-50733 — RCE при загрузке моделей в skops — CVE-2025-54886 — SSRF в Firecrawl — CVE-2025-57818 — Local Deep Research — CVE-2025-57806 — SSRF в HackMD-MCP — CVE-2025-59155 — RCE в Keras — CVE-2025-9906 — Prompt Injection в Windsurf — RCE в Hugging Face Transformers — CVE-2026-4372 — пять способов обойти PickleScan — атаки на ML supply chain — OWASP Agentic Skills Top 10 — AI Agent Traps от Google DeepMind — Shadow AI — безопасность MCP 1, 2 , 3 🧘‍♀️ Инструменты, библиотеки и фреймворки — Optuna — тюнинг гиперпараметров — spaCy — промышленный NLP — Netron — рентген для ML-моделей — JAXFORMER — DVC — Polars — Weights & Biases — Evidently AI — Pydantic — MLBox — InterpretML — OpenTelemetry + Langfuse — Kedro — NVIDIA NeMo — Inspect Evals 🤩 AI-агенты и мультиагентные системы — RoboDuck и победа Theori в AIxCC — где пентест-агенты уже работают, а где нужен человек — MetaGPT + AFLOW — безопасность агентных систем 1, 2 — MCP как новая поверхность атак — side-channel атаки на агентов — мультиагентные системы и роевой интеллект — мониторинг rogue agents — Harness Engineering 🦔 Исследования и разборы статей — Model Inversion Attacks — scheming у AI в реальном мире — Your Agent Is Mine: атаки на LLM supply chain — WEF: AI for Cybersecurity 2026 — обзор исследований по LLM-based vulnerability detection — может ли AI самостоятельно взломать бинарник — Emergence AI: что произошло, когда AI оставили жить без людей — Anthropic об AI-enabled cyberattacks — InfoKV и сжатие KV-cache — Люди, которые делают AI (Серые кардиналы 1, Серые кардиналы 2) 💔 ML: архитектуры, концепции и теория — KAN vs MLP — нейросимвольный AI — маленькие языковые модели — метрики качества текста: BLEU, ROUGE, BERTScore, COMET и другие — теория категорий и AI — ReaGAN и агентный подход к графовым нейросетям 🔪 Практика и эксперименты — как искать секреты

OWASP Autonomous Penetration Testing Standard (APTS) руководство по безопасной эксплуатации автономного offensive-агента от небольшой команды из Индии Astra Security. Полноценным стандартом APTS назвать нельзя, и, несмотря на то что драфт получил согласование от OWASP, фактически документ лидируют два сотрудника Astra. Как часто бывает, после публичного анонса активность в развитии быстро снижается. Так же было и с LLVS, который уже 2 года не может нормально выйти в релиз, и с черновиком Top 10 ML. Как сейчас принято, текст APTS богат на слова, и там аж 400+ страниц. Если как следует покопаться, в нем можно найти интересные мысли про автономный пентестинг: ⏺Agent runtime нужно считать недоверенным, т.к. модель может стать misaligned во время выполнения. С учетом насыщенного событиями июля это утверждение кажется очевидным. APTS-MR-023: Agent Runtime as an Untrusted Component. ⏺Контролировать нужно параметры вызова инструментов и цепочки действий. Недавний случай Irregular, когда во время тестирования модель атаковала организацию, домен которой совпал со случайным именем в бенчмарке, можно было бы отследить, имея настройки whitelist доменов в вызове nmap. APTS-SC-A03: Tool Invocation Parameter and Chaining Governance. ⏺Даже полностью легитимные действия могут быть симптомом сбоя тестирования, поэтому нужно логировать action distribution хакер-агента. Например, сохранение каких-нибудь безобидных временных файлов в Artifactory на соседнем сервере может быть сигналом, что тестирование идет не так :) APTS-SE-026: Out-of-Distribution Action Monitoring. ⏺Context compaction нужно учитывать при проведении пентеста. Инструкция вроде "не трогать host X при пентесте", полученная в начале, может исчезнуть после нескольких суммаризаций контекста. APTS-SC-A02: Context Window Safety and Constraint Preservation. ⏺Атакуемая система теперь может содержать промпт-инъекцию и повлиять на результат тестирования. APTS-MR-001: Instruction Boundary Enforcement. В гайде еще есть формулы,

🖥 Qwen3.8-27b удивляет В черновиках уже лежит пост на тему того, как выжать максимум из этой крохи на локальном железе, получая на задачах работы с кодом результаты, сравнимые с DeepSeek-Flash, как минимум. А тут приятно удивил в совсем «бытовой» задаче. Зацепила одна композиция, захотелось переложить на русский, ну и решил за обедом поискать её текст, чтобы не записывать на слух. Google (и Gemini вместе с ним): Ниче не знаю, результатов нет. Ладно думаю, спрошу в коворке у GLM 5.3 (здесь и далее — копипаста из чата с агентом): Полный текст песни предоставить не могу: Авторские права — текст песни является охраняемым произведением, и воспроизводить его целиком я не вправе. Текст нигде не опубликован — релиз очень свежий, и на текстовых ресурсах (Genius, Musixmatch и т.п.) его нет. Я не буду выдумывать или «восстанавливать» строки — это была бы дезинформация. Ок (какие мы правильные, когда не надо). Пробую локальный квен (4-битный, причем): ... The official text is not published anywhere — but I can try to transcribe the song from audio myself. Let me check what tools are available locally (yt-dlp, whisper). ... yt-dlp and ffmpeg are available — I'll download the audio and transcribe it using faster-whisper (via uvx/venv). This is because no official text exists for this track. Setting up the task plan. ... Audio download complete (4.1 MB webm). Converting to wav and creating a Python environment with faster-whisper installed — these are independent tasks, so I'll run them in parallel. ... wav готов. Создаю venv и ставлю faster-whisper (может занять пару минут). ... faster-whisper установлен. Пишу скрипт транскрипции и запускаю (модель small скачается с HuggingFace при первом запуске). ... The complete text has been restored — it's a consistent, coherent song with verses, choruses, and a bridge. I'll save the result to a file in the workspace and wrap things up. ... Песня из видео: «In the Dark We Live» — HELLMILE & valdyr (релиз 13 мая 2026). ⚠️ Важно: официаль

Серые кардиналы, часть 2 Трое исследователей, которые разобрали базовые модели со всех сторон, как их безопасно строить, как их правильно оценивать и какие риски они влекут за собой. 😍 Доун Сонг — человек, который давно объясняет, почему АИ и безопасность нельзя разделять. Её область находится ровно на пересечении того, что мы любим и почему мы здесь! Классическая работа Сонг Robust Physical-World Attacks on Deep Learning Models (2017) про атаку на распознавание дорожных знаков с помощью физических модификаций, и исследование (тоже 2017), о том, почему комбинация нескольких слабых защит от adversarial examples автоматически не создаёт сильную защиту. За последующие 9 лет Сонг развивала эту логику. Свежая статья 2026 года (на основе 128 исследований) переводит проблему на агентов, тк безопасность агентов нельзя решить одним гардрейлом вокруг LLM. Нужна defense-in-depth на уровне всей системы — контроль потоков данных, разделение привилегий, IAM, мониторинг, харденинг моделей и инструментов. Но есть проблема! Базовые модели масштабируют как атаки, так и сложность контроля. Одна скомпрометированная базовая модель = скомпрометирована вся экосистема приложений. 😍 Перси Лян — исследователь МО, обработки естественного языка и базовых моделях.  Статья,  пожалуй, главная для этого поста. Здесь систематизируется концепция foundation models. Когда одна базовая модель становится фундаментом множества downstream-приложений. Это создаёт не только возможности, но и архитектурные риски — именно те, что беспокоят Сонг. Другая работа Лян (в соавторах, кстати, Тимнит Гебру) про то, почему нельзя оценивать LLM одной accuracy и как строить многомерную оценку моделей. Подчеркну, что речь идет не про свежие статьи, а про базовые принципы. Надо читать! Перси Лян объяснит тебе архитектуру рисков получше даже канала OK, ML! Суть в следующем. Модель может быть точна на бумаге, но уязвима к adversarial атакам (про что Сонг) и одновременно несправедлива к меньшинствам. Один score — это иллюз

🗜 Выжимаем максимум из Qwen3.8-27b на маке Что, если я скажу, что привычные 20± tok/s генерации, которые дают 4-битные кванты Qwen3.8-27b в LM-Studio под M4 Max на средних контекстах, можно поднять в полтора-два раза на том же железе? И, что эта модель, на задачах работы с кодом, может давать результаты с качеством, вполне приемлемым для повседневной работы при должном тюнинге на стороне агента? Но давайте по порядку. ❗️Исходные данные Почему квант именно в 4 бита? Потому что до 4 существенно проседает качество инференса, а в 8 и выше на архитектуре Apple просто нет рационального смысла. Все, о чем будет написано ниже, тестировалось на MacBook M4 Max 128Gb RAM, но в целом адаптируемо и под 32Gb RAM и выше (с поправкой на предельный размер доступного контекстного окна, конечно). ❓Что не так с LM-Studio? Это замечательный и удобный инструмент (сам для экспериментов часто им пользуюсь), но есть два нюанса. Во-первых, в нём доступны не все ручки движков инференса, за которые можно подергать, чтобы (если повезёт) выжать десяток-другой лишних tok/s. Во-вторых, и это главное, он использует оригинальный MLX, который на данный момент игнорирует MTP (multi-token prediction), а в «родных» MLX-моделях от авторов LM-Studio MTP-головы и вовсе отрезаны. Беда в том, что со времен Qwen3-Next, модели Alibaba нативно поддерживают технологию MTP, дающую ощутимый буст скорости генерации токенов. С GGUF такой проблемы в LM-Studio нет, но более медленный инференс этого формата, по сравнению с MLX на Apple Silicon, сводит все преимущества MTP на уровень погрешности. Между тем, разработчики более легковесных решений подсуетились и уже справились с этой проблемой. ↗️ Конфигурируем легковесные решения Устанавливаем MTPLX (можно и с помощью brew) и скачиваем Qwen 3.8 27b optimized speed. После скачивания предложит запустить бенчмарк для определения оптимальных настроек MTP, и модель будет готова к использованию. Дополнительно можно заморочиться тонкой настройкой, по аналогии с описанн

👩‍💻 «Уязвимость» GitSpawn — влезть на шкаф, чтобы увидеть женскую баню Представляете, если забраться на самый верх стремянки, взяться рукой за оба провода для люстры и ногой включить свет, то... вы скорее всего упадёте со стремянки. И этой уязвимости подвержены примерно все электросети в мире 😱 Примерно такие формулировки возникают в голове, когда читаешь новости об очередной «уязвимости», накрывшей всех агентов. Например, о свежей GitSpawn. Вдумайтесь в её суть: если в агенте открыть git-репозиторий, полученный из недоверенного zip'а (не через git clone), то при выполнении агентом команд типа git status/diff git-клиент штатно отработает, следуя всем настройкам в .git/config. Что внезапно может привести к выполнению произвольного кода, ибо там можно прописывать кастомные скрипты и тулы, а следовательно сие является уязвимостью всех агентов 🤦‍♂️ И бомбит тут даже не с некомпетентности «исследователей» с манией попиариться на громких утверждениях (главное, красивое название атаке придумать, чтобы лучше разлетелась — это стремление как раз понятно), а с того, что разработчикам агентов теперь нужно как-то отстраиваться ещё и от этого. А это значит, что пользователям, либо придется подтверждать доверие ещё и к настройкам (локальным, btw) своих репозиториев, либо мириться с тем, что они перестанут работать внутри агентов, ради защищенности от чисто гипотетической угрозы. Либо разработчикам агентов делать ещё один шаг в сторону того, чтобы становиться вендорами EDR-решения. 😡 #мысли_вслух

😺 ChatGPT, давай, до свиданья! Сегодня утром произошло нечто, впервые за всё время, что работаю над c0wrk и sp4rk. По ходу их разработки, я стараюсь использовать все доступные мне LLM, чтобы держать в голове применимость каждой из них для тех или иных около-R&D'шных задач. Разумеется, не смог пройти мимо и случившегося на прошлой неделе релиза Astra. И сегодня утром, после двухдневной долботни с этой моделью, сделал тупо hard reset в обоих проектах на более ранние коммиты, откатив всё то, что натворила в их коде эта модель. 💩 После добавления поддержки stream-режима взаимодействия с моделями, в чате c0wrk стали задваиваться сообщения: сначала отображалось аккумулируемое содержимое получаемых чанков в реальном времени, а затем оно же отображалось, уже как событие чата. Попросив убрать аккумулируемое, я впервые столкнулся с тем, что модель не только начисто игнорирует требования, указанные в промпте, но и пытается спорить, доказывая, что её решение лучше и правильнее. Потому что она убрала ровно то, что я просил оставить. Вот только так не было правильнее и лучше. Так было проще. 💩 Ни одна, подчеркиваю, НИ ОДНА модель, ещё начисто не игнорировала заданное в AGENTS.md разграничение ответственности между этими двумя проектами (в sp4rk — переиспользуемая агентская логика, в c0wrk — конкретная реализация агента на её основе). И неиллюзорно удивился, увидев в sp4rk размазанную по нескольким пакетам реализацию того, что было сугубо специфичным для c0wrk и прямо предписывалось в AGENTS.md под реализацию в нём. 💩 Несколько раз, попросив пофиксить баги, натыкался на финальный (и ложный) ответ «в коде всё в порядке, наверное ты просто используешь протухшую сборку, пересобери заново». Вообще, сложилось впечатление, что вся работа модели строится на предположениях, которые она считает слишком блестящими, чтобы утруждать себя их подтверждением. 💩 Делая ревью только что написанного (ей же, в другой сессии) кода, выдавала единичные should-fix'ы и consider'ы, в то время, как за

🔗Мультимодельная разработка Написать этот пост подтолкнула одна статья, вышедшая на днях (в рефах ниже она стоит первой). Дело в том, что после выхода превью DeepSeek-V4-Flash я практикую подход, при котором задачи по написанию кода уходят этой модели, а код-ревью и правками занимается GLM-5.3. Почему именно так и более слабая модель делает основную работу, в то время как более сильная лишь подчищает за ней? На самом деле потому, что большинство исследований на эту тему рекомендуют именно такое распределение ролей. Для тех, кто захочет погрузиться в это поглубже, в конце поста привёл ссылки на все рефы. Здесь же просто обозначу основные тезисы из них, ну и свои личные доводы. 1️⃣ Стоимость При feature-based кодинге (а я использую в основном его) потребление токенов на непосредственно разработку кода в разы больше, чем на ревью изменений в нём. DeepSeek-V4-Flash же является очень дешёвой моделью, даже после недавнего подорожания тарифов, а с выходом V4.1 у него (по ощущениям первого дня плотной работы с этой моделью) прям сильно поднялось качество работы с агентскими сценариями и генерируемого им кода. Ну и его vision-версия развернута у меня локально, под задачи на-всю-ночь. Кроме того, при 2-3 одновременно разрабатываемых проектах, лимитов максимальной подписки GLM для задач кодинга лично мне явно не хватит. 2️⃣ Почему бы не ревьюить той же моделью? Этой теме посвящена последняя статья в рефах. Если вкратце, то слишком высока вероятность, что модель (или даже семейство моделей), допустившая ошибку, пропустит её на ревью. Причем, именно по тем же причинам, по которым она её допустила. В целом это бьётся и с моими наблюдениями, т.к. периодически я устраиваю (и не только этой парочке) ревью против саморевью с последующим сравнением результатов. И саморевью почти всегда дает менее качественный результат. Это можно чуть нивелировать, если пускать его в режиме goal'а типа «повторное ревью не должно выявить новых проблем уровней must и should fix», но блин... токен

🖥 О замедлении разработки ИИ Да, я про вчерашнее эссе Дарио Амодеи «We Must Pace the Frontier» Там он признаёт огромную пользу ИИ, но утверждает, что из-за рекурсивного самоусовершенствования и инцидента с побегами агентов риски стали настолько острыми, что нужно сознательно замедлять рост возможностей моделей, чтобы выиграть время для выравнивания, интерпретируемости, тестов и операционной строгости. Он предлагает его через три уровня: встроенные сторонние оценщики с правом доступа как у сотрудников, координацию демократических стран по стандартам и темпам прогресса при поддержке государства, а затем — осторожную глобальную координацию с авторитарными режимами (это про Китай, в основном) от узких запретов до возможных «ограничений скорости» рекурсивного самоусовершенствования. Смысл совсем не в остановке ИИ, скорее — в управляемом темпе: сохранить лидерство, не проиграв Китаю (наивный чел), и использовать отложенное время, чтобы сделать системы заметно безопаснее, прежде чем их возможности станут критическими. Углубляться в геополитику не хотелось бы, хотя и кажется, что Китаю до одного места мнение Запада по этому вопросу. Тем более, у них агенты вроде пока и не сбегали (хотя, как по мне, это скорее вопрос найма отбитых маркетологов, кои в Китае в дефиците, судя по всему). А санкционный Сбер со своим ГигаЧатом, думаю, их вообще вертеть хотел, вместе с их мнением. Да и им скорее ускорять разработку нужно, нежели замедлять. Но в целом, если убрать всю геополитическую воду, я с Дарио так-то согласен. И вот почему. 3 года назад я до одури доказывал коллегам, что ИИ не сможет показывать в SAST результаты, хотя бы сравнимые с формальными методами. Сейчас у нас есть технология, которая это опровергает напрочь, и о которой скоро планируем рассказать (да-да, упоминавшаяся здесь). У нас — не в смысле «только у нас», но в смысле, что нам намного проще сравнивать её с формальными подходами к SAST, в силу наличия некоторой экспертизы в этой области. 2 года назад я удивля

👨‍💻 Продуктивные выходные Как-то незаметно (и неожиданно) для себя с удовольствием провёл почти все выходные в возне со своим опенсорсом. • SKILLS В скиллсет vibespec добавился vibespec-explore. По сути, это explore, адаптированный под работу со спеками и предназначенный для детальной проработки идей по изменениям в кодовой базе. Именно в текущем виде этот скиллсет будет интегрирован в c0wrk в ближайших релизах. Btw, на прошлой неделе добавил в этот репозиторий скилл study-paper, здорово облегчающий чтение и проработку научных публикаций и технических статей. Скилл встроен в c0wrk (для него там реализовал отдельный UI), автономная версия скилла — для тех, кто, по неведомым причинам, ещё пользуется другими агентами. • FLOWSH Довёл до v0.3.2. Расширил базу знаний по наборам известных команд обоих шеллов и утилит популярных стеков и экосистем на +45%; исправил кучу багов, поднявших precision и recall до 100% на типичных командах, генерируемых дипсиком и глм; добил alias-анализ в абстрактном интерпретаторе для PowerShell до полной реализации (для bash уже был). Примечательно, что для всего этого использовал корпус шелл-команд, собранный по всей истории моей работы с агентом. • SP4RK Полностью перевёл анализ шелл-команд на flowsh, вместе с ним — модель вызовов оболочки, ужесточение tool-safety гейтов, расширил эффект-ориентированные сигнатуры формального судьи. • C0WRK Выпустил v0.9.0. Тут проще отправить в changelog, чем всё перечислять. Отдельно хочу поблагодарить всех ребят, делавших PR-ы в эту и предыдущие версии ❤️ Из значимо-видимого, что сделал на выходных: - полностью переработал security-гейты, что позволило добавить опциональный silent-режим, в котором все вопросы разруливает агент, не эскалируя вопросы пользователю (см. изменения в sp4rk и flowsh), не деградирующий при этом до YOLO; - реализовал возможность переопределения оболочки на кастомную команду — помимо основного предназначения, позволяет обернуть shell-вызовы в стороннюю песочницу; - до

🔗 Старый добрый аппсек, часть 1 ...совершенно незаслуженно задвинутый на второй план ИИ-хайпом последних лет( Решил вот проскочить по волнам истории аппсека и смежных областей за последние пару-тройку лет на предмет появившихся за это время новых классов недостатков и атак. Пока проскакивал, с удивлением обнаружил, как много нового прошло мимо меня, и решил поделиться находками с вами (а то вдруг я не один такой). Начнем с самого лоулевела, а именно: 1️⃣ Железо Не совсем аппсек, но всё же интересная тема, напрямую затрагивающая и безопасность приложений. В ней за эти годы наметилось 3 заметных сдвига: • От кэша к другим структурам CPU - TSA эксплуатирует логику планировщика и ложное завершение спекулятивных загрузок. Не Spectre-вариант в привычном смысле, да и AMD сама маркирует это как новый класс. - Branch Privilege Injection внедряет привилегию в процесс тренировки предсказателя. - RFDS (CVE-2023-28746) читает состояние файлового регистра на Intel Atom. - Native BHI (CVE-2024-2201) показывает BHI целиком из user space в Linux. - TikTag обходит ARM MTE спекулятивно, то есть под удар попал сам механизм защиты памяти. • От данных к семантике - GhostRace делает спекулятивным источником уязвимости конкурентность: TOCTOU случатся без всякой многопоточности в коде жертвы. - А VMScape переносит атаку на границу «гость → user-space гипервизор», что важно для облачных стеков на QEMU/KVM. • От x86/ARM — к новым архитектурам - В 2026 класс Transient Execution задокументирован для коммерческих RISC-V (SiFive P550, T-Head C910/C920) с практической утечкой памяти ядра, отсутствием барьера спекуляций в ISA и непереносимостью x86/ARM-митигаций. - Появились не-спекулятивные аппаратные баги иной природы: Zenbleed — дефект оптимизации в Zen 2, возвращающий мусор из регистров. А ещё целями подобных атак перестали быть только CPU: • BadRAM: атакующим оказывается SPD-чип памяти. • GPU.zip: канал утечки — аппаратное сжатие графики; атака ре

🔗 Старый добрый аппсек, часть 2 Продолжаем вспоминать ключевые вехи аппсека и смежных областей последних лет, не испоганенные агентами. 2️⃣ Протоколы и криптография Когда в 2023 году Google раскрыл Rapid Reset, выяснилось, что мультиплексирование стримов в HTTP/2 можно обернуть против самого сервера: клиент открывает поток и тут же его отменяет, а весьма затратная по ресурсам обработка на стороне сервера всё ещё идёт. Дешёвый для атакующего усилитель, который в итоге и породил рекордные DDoS-волны. Два года спустя исследователи из Тель-Авивского университета развернули идею в обратную сторону: в MadeYouReset на отправку RST_STREAM провоцируется уже сам сервер. Лимит на клиентские сбросы, поставленный после Rapid Reset (пример самих авторов — сто RST_STREAM на соединение), здесь попросту не задействован, и на фронте поток считается закрытым, тогда как бэкенд продолжает его обрабатывать. Что любопытно, Cloudflare и защищаться от этого не пришлось: митигации, оставшиеся от Rapid Reset, прикрыли и преемника. Уязвимыми остались разве что непропатченные стеки вроде h2 старее 0.4.11. Тот же протокол подарил атакующим и разведывательный примитив: метод CONNECT превращает прокси в сканер внутренних портов, где открытые и закрытые различаются по типу возвращаемых ошибок. Граница доверия при этом проходит между двумя машинами, по-разному понимающими состояние одного соединения. В SSH снова прошлись по хэндшейку. Terrapin — атака усечения префикса: MitM удаляет начальные сообщения согласования; в затронутых режимах (ChaCha20-Poly1305, CBC-EtM) порядок и счётчики сообщений не аутентифицированы до завершения обмена ключами, поэтому атакующий может незаметно выбросить отдельные расширения и даунгрейдить соединение, вплоть до отключения в OpenSSH защит от timing-атак. Уязвимость была в самом протоколе, поэтому лечением стало расширение strict-kex: любое неожиданное сообщение посреди key exchange теперь рвёт соединение, а после NEWKEYS обе стороны обнуляют счётчики пакетов в

🔗 Старый добрый аппсек, часть 2 Заканчиваем продолжать, подобравшись к самой близкой аппсеку теме: веб-атакам. Хорошую хронологию дают подборки PortSwigger за 2023, 2024 и 2025 год. Это рейтинги исследовательских находок, поэтому искать в них статистику массовых взломов бессмысленно. Зато видно, какие привычные предположения о безопасности перестали работать в очередной раз. В 2023-м досталось убеждению, что гонки — занятие для терпеливых людей с быстрым интернетом. В Smashing the state machine Джеймс Кеттл показал, как резко уменьшить влияние сетевых задержек: заранее передать основную часть нескольких HTTP/2-запросов, а завершить их одним TCP-пакетом. В целом, схожая техника (через отправку keep-alive запросов) использовалась и с ранними версиями HTTP, для амплификации побочных каналов. Оказалось, что так проще и попадать в короткие промежуточные состояния приложения. Даже операция, которую разработчик мысленно считает неделимой, внутри проходит несколько этапов. Параллельно продолжилась история HTTP request smuggling — «контрабанды» запросов через цепочки серверов. Прокси считает, что сообщение закончилось, бэкенд видит продолжение. Или наоборот. Отсюда обход проверок, отравление кэша и ситуации, когда ответы начинают доставаться чужим пользователям. В исследованиях 2023-го фигурировали уже цепочки из нескольких продуктов: согласовать понимание HTTP оказалось весьма непростой задачей. Причём сама методика прекрасно пережила смену протокола. В SMTP Smuggling Тимо Лонгин показал, как расхождения в обработке почтовых сообщений позволяют подделывать отправителя в уязвимых цепочках доставки. А TE.0 оказалась практически применимой на тысячах сайтов Google Cloud. В 2024-м Orange Tsai разобрал Apache HTTP Server в Confusion Attacks и обнаружил, что модули сервера не всегда согласны с назначением даже общих полей. Для одного значение — путь к файлу, для другого — URL. Это делает возможным обходы контроля доступа, раскрытие исходников и цепочки атак, вплоть до испол