Статья носит исключительно образовательный/ознакомительный характер. Она не служит цели, рекламировать какой-либо инструмент или ПО. Все наименования программного обеспечения, упомянутые в статье приведены из личного опыта.
Новый пост-квантовый гибридный алгоритм шифрования для высоко-нагруженных систем с реализацией на TypeScript. Ring-LWE, работа с ключами с использованием MAC и SHAKE-256, защита от основных видов атак и другие мысли в реализации протокола QuarkDash.
Идея этого проекта пришла мне в голову около семи лет назад, но до реализации я добрался только сейчас, т.к. есть некоторое время на это, пока ищу новую работу. Ну, и важно упомянуть, что я уже более 10 лет занимаюсь русской локализацией продуктов и сервисов Mozilla.
Мы привыкли говорить о защите серверов, рабочих станций, сетевого периметра, удостоверяющих систем, средств контроля доступа и ещё десятка важных вещей. Но браузер в организациях при этом слишком часто остаётся где-то в серой зоне. Он как будто есть сам по себе: установлен, как-то настроен, где-то применяются политики — и на этом разговор обычно заканчивается.
Хотя на практике браузер давно уже не просто программа для просмотра сайтов. Это рабочий шлюз ко всему: внутренним системам, облачным службам, корпоративной почте, документообороту, административным панелям, порталам, личным кабинетам и множеству других сервисов, через которые в компании реально проходят данные и процессы. Именно об этом я недавно писал в BIS Journal, где попытался показать браузер как важное, но часто недооценённое звено корпоративной кибербезопасности.
Для меня эта тема не случайна. Раньше я занимался развитием продукта X-Config в Spacebit — решения, связанного с безопасностью конфигураций программного обеспечения. Тогда мне пришлось довольно глубоко погрузиться в саму логику безопасной настройки: как появляются профили, как они согласуются, где заканчивается методология и начинается ручная рутина, почему даже хорошие требования без нормального инструментария быстро превращаются в набор разрозненных действий. В интервью для «Банковского обозрения» мы как раз обсуждали профили безопасного конфигурирования, роли специалистов по ИБ и администраторов, а также то, что такие профили должны жить не как памятка в PDF, а как часть управляемого процесса.
Docker Swarm предоставляет встроенный механизм управления секретами: пароли, ключи API и сертификаты передаются в контейнеры через зашифрованный канал и монтируются в /run/secrets/. Звучит безопасно — пока вы не осознаете, что любой пользователь с доступом к docker exec может прочитать эти секреты в любой момент жизни контейнера.
В этой статье я разберу, почему стандартные способы защиты не работают, и покажу решение на основе именованных каналов (FIFO), которое позволяет секрету быть прочитанным ровно один раз — при старте приложения.
Всем привет! Подводим итоги марта по части самых интересных CVE. Дайджест был бы неполным без десяточки от Cisco: небезопасная десериализация под RCE в Cisco FMC, активно эксплуатируемая с конца января.
Отдельно также отметилась компрометация цепочки поставок сканера уязвимостей Aqua Trivy с далеко идущими последствиями, включая кражу исходников у той же Cisco. В ИИ-платформе Langflow критическая уязвимость под внедрение кода без аутентификации, в Chrome два нулевых дня в Skia и V8, а в Microsoft Excel эксплойт Copilot под утечку данных без участия пользователя. Об этом и других ключевых уязвимостях марта читайте под катом!
Привет, Хабр! Я Дмитрий Белозеров из МТС Линк, моя команда отвечает за ПО и оборудование для переговорных комнат и сервис Rooms. Сейчас BYOD-системы для переговорок — это мастхэв. Простота подключения, независимость от вендора и сниженные затраты на обслуживание — это то, что привлекает компании.
Мы тоже предлагаем такие решения. В своей практике я часто сталкиваюсь с тем, что при внедрении BYOD-систем не все учитывают полный спектр расходов, которые подразумевает правильное использование таких переговорных. В посте расскажу про эти неочевидные затраты. Надеюсь, будет полезно тем, кто пока только планирует такое у себя.
Расскажем, как нам удалось повысить качество определения истинных секретов в результатах сканирования кода с 0.70 до 0.90 PR AUC с помощью LLM.
Пока мы ждём, что в Telegram наконец раскатится обновлённая реализация Fake-TLS, хочу рассказать о своей реализации MTProto-прокси 2018 года, которая снова становится актуальной, и об одной из её уникальных возможностей.
MTProto-прокси — решение для обхода блокировок Telegram в странах с интернет-цензурой (мы говорим про Иран конечно же 😄). Типичная схема выглядит так: оператор поднимает прокси с одним секретным ключем на всех, публикует одну ссылку, и тысячи людей ей пользуются. Просто, но у этой модели есть реальные ограничения:
Нет контроля доступа. Любой, у кого есть ссылка, может пользоваться вашим сервером бесконечно. Отозвать доступ у конкретного пользователя без смены общего секрета — а значит, без поломки ссылок у всех остальных — невозможно.
Нет аналитики на пользователя. Видно общее число соединений и IP-адреса, но не понять, кто активен, кто раздал свою ссылку полусотне друзей и кто потребляет весь ваш трафик.
Ограниченная монетизация. Да, есть “спонсорские каналы”, но если хотите продавать доступ — не за что зацепиться: секрет один на всех, привязать подписку не к чему.
А что если у каждого пользователя будет свой уникальный секрет, дающий доступ только ему? Тогда можно продавать подписки, отзывать доступ у отдельных пользователей, ограничивать использование и отслеживать уровень активности.
Добрый день! Сегодня расскажу, как с помощью PHP создать генератор случайных байт ( чисел ) с помощью 12 таймеров. Энтропия данного генератора составляет примерно 7.1 бит на символ ( у меня ), но на более мощном железе может подняться до 7.9–8, что по идее неотличимо от истинной случайности. Вот, как работает весь «конвейер»:
Внимание! Проект экспериментальный, не сертифицирован, не рекомендуется для использования в системах, требующих официального криптографического одобрения. Для учебных целей и экспериментов — пожалуйста.
Во многих командах сегодня все выглядит «как положено»: Kubernetes, CI/CD, Terraform, DevOps-команда на месте.
Но по мере роста системы появляется другой эффект: разработка тормозит не из-за кода, а из-за инфраструктуры. Любое изменение проходит через одну точку — DevOps.
И дело не в том, что команда работает плохо. Просто через нее проходит все: задача уходит в очередь, возвращается на доработку и снова ждет. Бизнес давит на скорость, но инфраструктура не успевает.
Привет, Хабр! Меня зовут Павел Лавров, я owner нового продукта в экосистеме Orion soft — GitOps-платформы HyperDrive. И в этой статье я расскажу, почему проблема не в людях и не в инструментах — она в самой модели работы с инфраструктурой. Давайте разберемся, как возникает это узкое место и что меняется, если его убрать.
Хабр, привет!
На связи команда инженер-аналитиков R-Vision. Мы проанализировали широкий спектр уязвимостей, выявленных в марте, и включили в дайджест лишь те, что представляют наибольший практический интерес по уровню риска, подтверждённой эксплуатации и актуальности для специалистов по информационной безопасности.
31 марта 2026 года один из самых популярных npm-пакетов в мире превратился в оружие. Разбираем, как устроена атака на цепочку поставок через axios, почему классические средства защиты могут не выручить на этапе заражения – и как DNS-уровень оказался барьером, который предотвратил крупнейший инцидент.
Мгновенная атака
Представьте, что вы едете в отель. Один из больших сетевых - из более чем 5000 отелей по всему миру. Устали после пересадки и с единственной мыслью в голове - как можно скорее добраться до номера и открыть ноутбук, доделать задачи к утреннему релизу.
Все еще хорошо – информационная система сети отелей работает исправно, заселяя больше 500 гостей в минуту.
Вы открываете дверь такси и выходите. До стойки ресепшн рукой подать, идти чуть больше минуты - 89 секунд. Но дойдя до нее вы видите, как меняется лицо администратора. Глядя в экран, она видит сообщение о сбое всех систем.
Именно столько – 89 секунд прошло между публикацией вредоносной версии axios и первым заражением. Горизонтальное же продвижение злоумышленников, вооруженных мощью автономных AI-агентов может быть мгновенным. Получив доступ к переменным окружения, токенам CI/CD, ключам доступа к облакам, БД, API платёжных шлюзов, секретам Kubernetes с компьютеров разработчиков – дальнейшее дело техники.
И это реальное описание того, что могло бы случиться, если бы клиент не использовал сервис DNS-фильтрации.
Привет! Меня зовут Леонид Плетнев, я бизнес-партнер по информационной безопасности в 1С-Битрикс.
Современные онлайн-сервисы по автоматизации бизнеса позволяют быстро создать портал и получить полезную функциональность: мессенджер, видеозвонки, совместная работа с документами, CRM, ИИ-помощник и многое другое. Вы получаете доступ к инфраструктуре и функционалу, не думая о серверах и обновлениях. Вендоры прикладных облачных решений обычно обеспечивают легкий старт - пять минут и кажется, что информационная система готова к работе. Но так ли это на самом деле?
За последние годы атаки заметно изменились. Если раньше шифровальщики ограничивались отдельными серверами или рабочими станциями, то теперь они целенаправленно идут к системе резервного копирования. Если это удается — атака уже выиграна, даже если остальная инфраструктура формально еще работает. В этот момент становится очевидно: сам факт наличия резервных копий ничего не гарантирует. Поэтому сегодня приходится защищать не только данные, но и саму систему резервного копирования.
Полгода назад написал первую статью про RBACX — RBAC/ABAC-движок авторизации для Python. С тех пор вышло 25+ релизов, и библиотека стала заметно мощнее: добавил ReBAC с поддержкой OpenFGA и SpiceDB, пакетную проверку прав, ИИ-генерацию политик из OpenAPI-схемы, Redis-кэш, async Django, шортхэнд для ролей и закрыл три security-бага. Рассказываю что, зачем и как это вообще делается в одного.
Всем привет!
В какой-то момент у меня появился простой вопрос: «А можно ли заставить ассистента произнести что-то, что он в норме говорить не должен?» Без API, без навыков программирования, без автоматизации и т.п.
Оказалось - можно.
В этой статье рассмотрены две недавние атаки на цепочку поставок, направленные на пользователей популярных пакетов PyPI — litellm и telnyx. Также авторы предоставили рекомендации для разработчиков и сопровождающих проекты на Python о том, как подготовиться и избежать подобных инцидентов в будущем.
LLM-агенты отлично решают алгоритмические задачи. Но что произойдет, если поместить их в реальную инфраструктуру – с CI/CD, branch protection и security-политиками?
Я провел эксперимент: дал агентам простую задачу – внести изменение в репозиторий и замерджить его в main, соблюдая все правила. При этом у них был доступ к тем же инструментам, что и у разработчика, включая GitHub CLI и админский токен.
Результат оказался немного неожиданным. Практически все модели успешно выполнили задачу, но ни одна так, как я ожидал.
28 марта состоялась, с одной стороны, довольно камерная встреча небольшого круга специалистов: Backend‑разработчиков Java. Разумеется, на встрече были и фронтэнд‑специалисты, и фулстек‑программисты, но когда залу задавали вопросы, кто есть кто — максимальное и максимально доминирующее количество рук было именно от специалистов бекенда.
Как это было. Я пришел на час позже, не в 12 обеда, но в час дня. Сразу попал в зал на лекцию, где рассказывались не суперсложные вопросы, но затрагивались вопросы времени в Java, рассинхронизации серверов, специфики подсчета времени в таком старом языке, как Java, с учетом максимальной экономии памяти и того, что было до UTC: функции вне библиотеки time для подсчета минут и секунд при анализе времени постов, создания того или иного контента, проведения операций в целом.
Мы привыкли, что повтор r в ECDSA — это случайный сбой: плохой генератор, ошибка реализации, повтор nonce. Но что, если за одним repeated-r скрывается целое семейство дефектов (defect-family), которое можно не только обнаружить, но и перенести на другие закрытые ключи?
Представляем закрытую исследовательскую систему — стратификационный анализ ECDSA-подписей на secp256k1. Вместо точечных аномалий мы смотрим на фазовые корпуса подписей, используем торическую геометрию, kNN и перестановочные тесты. Результат:
· Во внешнем корпусе из 30 адресных контекстов и 6257 подписей repeated-r найден только в 1 контексте, межадресных коллизий r — 0. · 58 из 58 контролируемых переносов defect-family с реального адреса-донора на панель реальных адресных целей прошли с полной ECDSA-валидацией реконструированных подписей. · Встроенный publication-safety audit заблокировал открытый bundle, обнаружив 498 проблем (30 критических) — от raw (r,s,z) до восстановленных синтетических k и фрагментов закрытых ключей.
В публичной версии отчёта — только математика, агрегаты и безопасные листинги. Никаких инструкций по эксплуатации. Это продолжение методологии AuditCore, но уже на уровне стратифицированного анализа.
