Информационная безопасность *

Почему мы классифицируем движение руки, а не картинки со светофорами — и как встроить это в форму двумя строками

Картиночные капчи в 2026-м решаются моделями компьютерного зрения за миллисекунды, а каждый ваш клик по «выберите автобусы» бесплатно размечает чужой датасет. Плюс две свежие проблемы: Google в начале 2025 срезал бесплатный лимит reCAPTCHA с 1 000 000 до 10 000 проверок в месяц, а с апреля 2026 ужесточил модель ответственности за данные по GDPR. Из России reCAPTCHA к тому же нестабильна.

Общая проблема для сети — как доказать, что ты человек, не сдавая паспорт, лицо и номер телефона. Мы предлагаем: drop-in капчу, которую посетитель не кликает, а рисует. В описании — архитектура, ML-часть, приватность и код интеграции. Проект открытый. Буду рад аргументированным замечаниям.

Об одной и той же уязвимости в Authentik — популярной опенсорсной системе корпоративного входа — независимо и почти одновременно сообщили восемь исследователей. Уязвимость (CVE-2026-57580) позволяла вставить в поле с идентификатором пользователя (NameID) XML-комментарий, обрезать значение до чужого адреса и привязать к жертве подконтрольную атакующему учетную запись — подпись при этом оставалась валидной. Срабатывало это не у всех: нужны определенные настройки сопоставления учетных записей, отличные от заданных по умолчанию. Закрыли проблему в версиях 2026.2.6 и 2026.5.5. Один из восьмерых — Эрик Чан (Eric Chiang), технический директор компании Oblique Security; для него эта находка была одной из шестнадцати. Свою историю он рассказал в блоге 19 августа, а то, что желающих оказалось восемь, объясняет просто: очевидно, он не единственный, кто теперь взламывает с помощью ИИ.

Завершилась третья смена Positive Hack Camp: познать русский кибербез и прокачать свои скиллы приехали в Москву более 80 начинающих специалистов из 20 стран. Прилетели они за свой счет — а с нашей стороны были мощная экспертиза, крутые преподаватели и культурная программа. Рассказываем, как все прошло.

«У нас ИИ нет, мы только планируем внедрение» – самый обманчивый ответ. На практике это почти всегда означает: инвентаризации нет, видимости нет, политик нет. При этом сотрудники уже используют публичные модели, IDE-агенты, локальные ассистенты и low-code инструменты с доступом к рабочим данным.

Классический Shadow AI – это использование сотрудниками ChatGPT, Claude или аналогичных сервисов без ведома ИТ и службы безопасности. Но большинство LLM Firewall видят только на уровне вызова «теневых» моделей (API-трафик к моделям) и почти не видят то, что происходит на локальных машинах.

При этом настоящий Shadow AI живет глубже: в MCP-инструментах, локальных desktop-агентах, встроенных в корпоративные приложения, в IDE разработчиков и на рабочих станциях сотрудников. Именно поэтому контроль Shadow AI сегодня невозможно рассматривать отдельно от runtime-контроля ИИ-агентов.

Кибератаки часто проявляются через отклонения от нормального поведения пользователей, устройств и инфраструктуры – например, нетипичные права, пустые поля в системных отчетах, подозрительные адреса. Чтобы выявлять их, в системах управления событиями информационной безопасности (SIEM) используют разные инструменты, в том числе – списки исключений. Показываем, как эти механизмы помогают автоматизировать работу ИБ и быстро замечать сложные атаки, на примере системы «СёрчИнформ Мониторинг безопасности».

Я Станислав Калабин, инженер-архитектор компании Axel PRO. Если постараться найти открытую информацию про 802.1x на популярных видеохостингах, презентациях или рекламных материалах, то все выглядит идеально, но в реальной корпоративной сети все обычно устроено сложнее.

Помимо ноутбуков и рабочих станций, в инфраструктуре присутствуют десятки типов устройств. Большинство из них относятся к классу IoT (Internet of Things, «интернет вещей») и специализированного оборудования, хотя сюда также входят принтеры, МФУ, IP-телефоны и другие корпоративные устройства, которые не умеют проходить стандартную аутентификацию 802.1x

В статье разберемся, как контролировать устройства, которые не поддерживают полноценную аутентификацию по 802.1x?

Всем привет! Я продолжаю развивать свою библиотеку для создания распределённых приложений. Она уже легла в основу новой версии rats-search (распределённый торрент-поисковик) и rasync (синхронизация папок, файлов и исходников между устройствами), а также, судя по всему, используется в стороннем клиенте UltraVNC (VNC-клиент).

Библиотека позволяет развернуть собственную P2P-сеть, связать пользователей между собой и выстроить обмен данными через потоки разных типов — бинарные, строковые и другие. Главная особенность — автоматическое обнаружение участников (peer discovery), что особенно актуально в условиях постоянных блокировок и сетевых ограничений.

На данный момент поддерживаются C/C++, Java (Android), Python и Node.js.

Это очередное обновление: ещё больше стабильности в работе различных функций. Обо всём подробнее — далее.

Последний стабильный релиз на сегодня — 2.1.2. Исходный код и собранные бинарные файлы доступны для:

Как при автоматической проверке документов отличить оригинал от цветной ксерокопии или даже муляжа? Один из надежных признаков подлинности – наличие оптически-переменных защитных элементов (OVD, Optical Variable Device), например голограмм. Их внешний вид меняется при изменении угла обзора и положения источника света.

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

Что может пойти не так, если в надежном криптографическом алгоритме цифровой подписи вместо случайного числа использовать константу? Для компании Sony эта невнимательность обернулась полной компрометацией мастер-ключа PlayStation 3. История безопасности консолей полна таких поучительных примеров: от переполнения буфера из-за слишком длинной клички лошади в игре Zelda – до глитч-атак на цепи питания. Давайте разберем, какие инженерные уроки можно извлечь из тридцатилетней гонки вооружений между хакерами и платформодержателями.

Тема хранения токенов — одна из самых больных в авторизации. Многие, не до конца понимая, как авторизация должна работать, кладут оба токена в cookie или — что ещё хуже — в localStorage. В этой статье мы соберём схему, в которой access‑token живёт в памяти приложения, refresh‑token — в HttpOnly‑cookie, а фронтенд сам восстанавливает сессию после перезагрузки страницы и незаметно обновляет протухший access.

Бекенд — на Go, фронтенд — на Vue 3 (Vuex + vue‑router + axios), но концепция так же применима к React и Next.js. Верстку и стили оставляю за кадром — в статье только логика авторизации.

Привет, Хабр!

Мы традиционно собрали DDoS-статистику за II квартал 2026 года и посмотрели, какие тенденции проявились за этот период. В начале года злоумышленники вернулись к классическим TCP- и UDP-сценариям. А что было дальше? Сохранился ли этот вектор и куда сместился фокус атакующих — разбираемся под катом.

Привет, Хабр! Я Денис Макрушин, работаю в Яндексе, и вместе с командой SourceCraft Security строю платформу для безопасной агентской разработки, а в свободное время ищу уязвимости в ИИ‑агентах и иногда рассказываю об исследованиях в своем блоге. Чем дольше этим занимаюсь, тем лучше вижу тенденцию: индустрия обсуждает, что агенты умеют делать, но реже говорит о том, какие решения и как проще внедрять, чтобы сделать агентскую инфраструктуру безопаснее. Вместе с моими коллегами Ратмиром Самархановым и Андреем Погирейчиком мы решили проверить гипотезу: «наши ИИ‑агенты в разработке могут быть скомпрометированы и существуют простые средства для контроля их безопасности». Расскажем о первых результатах.

Привет, Хабр! Сегодня мы постараемся вас удивить необычной темой. Для начала давайте попробуем на секунду представить, что у нас как у вида реально есть какое-то будущее (если регулярно читать новости, то в этом можно серьезно усомниться) и что обещаниям в пресс-релизах госкорпораций можно верить. 

Забытая на полвека Луна определенно вернулась в повестку дня — в апреле 2026 года Artemis II впервые с 1972 года совершили пилотируемый облет Луны и вернулись на Землю. Китай обещает высадку на спутнике уже в 2030-м, и, кажется, у каждой из крупнейших держав есть свой план по строительству лунной базы.

В чем самое большое отличие мира 1972 года от нашего? Правильно, интернет и всеобщая связанность устройств по сети. А это значит, как мы с удивлением поняли, что эту самую лунную базу можно будет подвергнуть DDoS-атаке! Но как этот процесс будет происходить? И какие будут последствия? Приглашаем вас в путешествие по увлекательной технической фантазии не столь уже и далекого будущего.

Читатель принёс мне в комментарии документ ФСТЭК как аргумент: длина пароля должна быть не менее 15 символов. Документ оказался настоящим, цифра в нём есть, но работает она не так, как её процитировали.

Заодно выяснилось, что «Рекомендации по защите сетевого периметра информационных (автоматизированных) систем» лежат на сайте регулятора с 10 марта, в них 35 пунктов, и разбора этого документа нигде нет.

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

1000 сайтов в час вместо нескольких часов на каждый — так работает ЮScan, сервис автоматизированного аудита от ЮMoney. Его основная задача — помочь банкам и платёжным организациям не допустить подключения сайтов, которые маскируют запрещённую или рискованную деятельность под легальный бизнес. Сервис автоматически проверяет ресурс и выявляет подобные случаи ещё до начала сотрудничества.

С 2020 года через ЮScan проверено более 550 тысяч заявок. За это время ЮKassa не получила штрафов за обслуживание запрещённых видов деятельности.

Кому это нужно? Если вы обрабатываете более 10 000 страниц в сутки, работаете с эквайрингом, маркетплейсами, KYC/AML-проверками или выполняете требования 152-ФЗ, ручные процессы неизбежно становятся узким местом. Меня зовут Ирина, я руковожу антифродом в ЮMoney. Расскажу, как устроен ЮScan: как обходить тысячи страниц, находить рискованный контент и превращать данные в понятный скоринг.

Про ИИ-ботов пишут в основном пересказами документации вендоров: этот собирает данные для обучения, тот ходит за содержанием по запросу пользователя. Я решил посмотреть, что происходит на самом деле — прежде всего по журналам доступа сервера. Ниже представляю вам разбор: кого видно в логах, что они запрашивают, чем отличаются два типа ботов у одного вендора и почему файл llms.txt в этой картине почти не встречается.

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

И второй вопрос: чем, по-вашему, занимается современный хакер? Скорее всего, вам представляется злоумышленник, ворующий аккаунты в социальных сетях, не так ли?

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

Моя история

Я долгое время размышлял о мошенничестве с токенами — проблеме, с которой впервые столкнулся, когда работал разработчиком ПО в ИИ-шлюзе.

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

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

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

Имя пакета в реестре часто оказывается первым сигналом того, что компоненту можно доверять. Разработчик видит название вроде google-cloud-storage, opentelemetry-sdk или apache-airflow-providers-slack раньше, чем открывает исходный код, и ожидает, что знакомый префикс указывает на известный проект. В PyPI это ожидание пока ничем не подтверждено: реестр формально не связывает общее начало имени с его владельцем, поэтому любой свободный вариант может зарегистрировать посторонний пользователь.

В конце июня 2026 года в Python‑сообществе приняли PEP 752 (мы писали об этом здесь). Он предлагает закреплять за организацией не отдельные имена, а префикс и все будущие проекты, которые ему соответствуют. Если PyPI реализует этот механизм, то пакет с именем вроде «google‑cloud‑new‑service» сможет опубликовать только та организация, которой принадлежит право на этот префикс или которой разрешили пользоваться этим правом. На первый взгляд, решение очевидное. Однако общий префикс не всегда означает, что все пакеты принадлежат одному издателю. Иногда он обозначает семейство официальных библиотек, а иногда экосистему сторонних дополнений. 

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

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

На этот раз первым сигналом стал мой собственный supply chain‑мониторинг. Он сообщил о новом npm‑пакете plugin-react-vite. На первый взгляд это выглядело как очередной тайпсквоттинг - ничего особенно необычного.

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

В результате расследование ушло далеко за пределы одного package.json: от подозрительной зависимости я пришел к второму этапу размером около 30 тысяч строк, а затем - к нескольким месяцам активности, связанным пакетам, нескольким npm‑аккаунтам и уже известному кластеру.

Именно этот путь я и хочу разобрать.