Безопасность

Keycloak на практике: realms, clients, потоки, деплой

Keycloak на практике: realms, clients, потоки, деплой

От решения к практике: разворачиваем Keycloak 26.7.0 (Quarkus) в docker-compose с внешним PostgreSQL, разбираем анатомию realm (confidential vs public clients, redirect URI, realm- и client-роли, группы, client scopes), потоки authorization code + PKCE и client credentials, получаем первый access-token curl-ом к token endpoint и читаем реальный декодированный JWT (iss, aud=backend, exp, realm_access.roles). Realm-as-code через kc.sh export/import вместо click-ops, token lifespans и protocol mappers ролей.

Свой auth или готовый IdP: когда брать Keycloak

Свой auth или готовый IdP: когда брать Keycloak

Не «как настроить Keycloak», а решение на уровень выше: когда вообще стоит брать готовый IdP вместо своего auth. Реальная цена «сделай сам» (восемь пластов — сессии, refresh, OAuth-флоу, MFA, passkeys, федерация — каждый отдельный проект и зона риска), что закрывает Keycloak, рамка «бай vs билд» (self-hosted vs managed Auth0/Cognito), РФ-угол on-prem и честная ops-цена stateful-сервиса

TLS-фундамент: цепочка доверия, рукопожатие и что видно в трафике

TLS-фундамент: цепочка доверия, рукопожатие и что видно в трафике

Десять поломок цепочки доверия на четырёх клиентах: исход везде одинаковый, а различает их сказанное — openssl называет все шесть причин отказа, Go и Java по четыре. Плюс имя сервера открытым текстом в первом же пакете и честный счёт сообщений 1.2 против 1.3

Конвейер для недоверенных файлов: архитектура, а не флаг

Конвейер для недоверенных файлов: архитектура, а не флаг

Заключительная часть серии: как построить приём пользовательских файлов так, чтобы уязвимость в парсере осталась локальной неприятностью. Рабочий конвейер на стенде, где каждая граница изоляции проверяется отдельно от остальных — включая случай, когда проба показывала «разрешено» по совершенно неверной причине.

Тихие отказы: сервис сломан, а логи чисты

Тихие отказы: сервис сломан, а логи чисты

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

SBOM видит, сканер молчит: слепое пятно вендоренных зависимостей

SBOM видит, сканер молчит: слепое пятно вендоренных зависимостей

Контролируемый эксперимент на живом стенде: один и тот же бинарник FFmpeg, упакованный под каноническим именем, получает 65 уязвимостей, а под вендорским — ноль. Разница только в имени пакета. Почему сканеры образов сопоставляют находки по идентичности компонента, а не по содержимому файла, что из-за этого пропускает Jellyfin, и как это чинить в своём конвейере.

PixelSmash: как 50-килобайтный видеофайл в папке роняет ваш сервер

PixelSmash: как 50-килобайтный видеофайл в папке роняет ваш сервер

Разбор CVE-2026-8461: heap out-of-bounds write в декодере MagicYUV (FFmpeg/libavcodec) из-за рассинхронизации slice_height с chroma vertical subsampling. Срабатывает не от клика по видео, а от генерации превью в файловом менеджере или сканирования библиотеки медиасервера — фикс в FFmpeg 8.1.2, но кто реально уязвим к RCE, а кто просто падает, сильно разнится. Вывод — про изоляцию декодера как рубеж обороны, который не зависит от скорости патчей.

Сканирование уязвимых зависимостей (SCA): Dependabot, osv-scanner, govulncheck

Сканирование уязвимых зависимостей (SCA): Dependabot, osv-scanner, govulncheck

SCA на практике: почему Dependabot показывал 0, а osv-scanner нашёл полсотни; чем различаются базы advisory (GitHub Advisory, OSV, Go vuln DB, RustSec) и методы (presence-based против call-graph govulncheck); плейбук починки транзитивных CVE по экосистемам (Go, Maven, Python, Rust) и честная работа с no-fix и ложными срабатываниями

HTTP/2 Bomb: как склейка двух старых приёмов кладёт веб-сервер

HTTP/2 Bomb: как склейка двух старых приёмов кладёт веб-сервер

Разбор атаки HTTP/2 Bomb: HPACK-бомба и удержание через нулевое flow-control окно по отдельности известны десять лет, но вместе кладут nginx, Apache, IIS, Envoy и Pingora за секунды. Как устроен механизм на уровне фреймов, кто уязвим и что пропатчено, почему Angie (и khorost.tech) не тронут, как проверить свой сервер — и почему эту склейку первым увидел ИИ