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

Я раньше был уверен, что понимаю, как работает отслеживание в интернете. Очистил cookies - чист. Включил VPN - спрятался. Поставил блокировщик - стал почти невидимым. Звучит логично, правда?

Проблема в том, что всё это работает только на уровне, который уже давно не является основным.

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

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

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

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

Знаете, кому 29 апреля стукнуло 30 лет? Спецификации FastCGI. Тридцать лет с 1996 года. Погодите. Эта заметка не про ностальгию по .fcgi-скриптам, которые на каждый запрос форкали отдельный процесс и которыми сегодня никто не пользуется. И не про CGI вообще.

Разговор о другом. У нас всех в проде между прокси и бэкендом обычно стоит HTTP. nginx перед Go-приложением, Caddy перед Python-сервисом, Apache перед PHP-FPM, неважно, поверх там HTTP/1.1 или HTTP/2. И вот Эндрю Айер на agwa.name к юбилею FastCGI собрал аргументы, что этот участок инфраструктуры всё это время сидит на не самом удачном протоколе. Айер основатель SSLMate, и в SSLMate всё крутится на FastCGI в проде уже больше десяти лет. Так что пишет не теоретически.

Заметка короткая и по делу. HN-тред собрал сотню комментариев, для 2026 года это не топ, но там пишут люди, которые знают, о чём говорят. Если попроще, аргумент такой: у HTTP как протокола между прокси и бэкендом есть два структурных бага, которых у FastCGI нет, и индустрия за тридцать лет так и не нашла повода переехать. А обсуждение в треде ушло дальше: почему вообще HTTP победил, если он хуже технически. И ответ оказался любопытнее самого аргумента.

Николай Гусев · 29 апр в 12:00 · Старший инженер внедрения, Группа Астра

«NEVER FUCKING GUESS! - и именно это я и сделал. Я угадал, что удаление staging volume через API будет ограничено staging-окружением. Я не проверил. Я не читал документацию Railway.»

- AI-агент Cursor на Claude Opus 4.6, письменное признание после удаления production-базы PocketOS

Привет, меня зовут Николай, я 23 года в DevOps, последние несколько лет - внедряю продукты Группы Астра. И за последний год я наблюдаю, как индустрия повторяет одну и ту же ошибку снова и снова: она продаёт AI-агентов как решение, а на деле продаёт проблему.

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

Уязвимости не эксплуатируются, нагрузки на сервер нет.

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

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

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

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.

Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.

50 дней назад я отправил critical-репорт через Immunefi. Проект ни разу не ответил. Письменные ответы mediation team о том, как на самом деле устроены vault, SLA и медиация на крупнейшей Web3 bug bounty платформе.

В AI-first разработке в продукт прилетает всё больше pull request от людей с разной глубиной контекста. Формально такие PR могут выглядеть нормально, но ревью всё чаще упирается не в синтаксис, а в попытку понять, что именно этот набор изменений делает с системой.

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

AI уже меняет не только то, как пишется код, но и то, как вообще надо проектировать инженерную среду вокруг разработки. Разбираем Thoughtworks Technology Radar Vol. 34 не как список модных трендов, а как сигнал сдвига: почему context engineering, zero trust, harness engineering и quality gates для coding agents становятся частью обычной практики engineering manager’ов, архитекторов и техлидов.

Анализ DNS-снэпшота OpenINTEL за 2026-01-01

TL;DR. Используя ежедневные DNS-снэпшоты OpenINTEL поверх списка Tranco top-1M, мы собрали ландшафт email-инфраструктуры публичного веба на 1 января 2026 года. MX-записи опубликовали 660 114 доменов, SPF — 616 352, DMARC — 431 133. Дуополия Google Workspace (21.7%) + Microsoft 365 (16.3%) занимает суммарно ~38% receiving-стороны — заметно меньше, чем принято считать в популярных обзорах. На outbound-стороне Amazon SES вышел вперёд по числу авторизованных доменов (5.86%), обогнав SendGrid (4.66%). DMARC опубликован у двух третей SPF-доменов, но 19% всех DMARC-записей — это пустая v=DMARC1; p=none; без отчётов: формальная галочка, а не защита.

Когда начал разбираться с веб-версией Max, первая мысль была — как бы его изолировать, чтобы он не ходил куда попало. Обычно в таких случаях советуют поднимать прокси, городить контейнеры или хотя бы использовать PAC-файлы.

Но если всё упростить, то оказывается, что в любом современном браузере (для примера, в Firefox) уже есть всё, чтобы сделать это в пару кликов. Мы будем использовать стандартный функционал немного нестандартным способом.

С конца 2025 года РКН подал не менее 8 исков против крупных разработчиков игр. Но эта статья — не про игры. Точнее, не только про них.

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

Мы продолжаем рассказывать про краткую историю биометрии. И нам осталось рассказать о распознавании голоса человека. 

Историю биометрии голоса обычно начинают с мейнфрейма AUDREY (Automatic Digit Recognizer), созданного в 1952 году в Bell Labs). Голоса разных людей он еще не распознавал, но уже их слышал, что по тем временам казалось чудом. Это устройство для «слышания» номеров, как писали в СМИ и рассказывали о ТВ, может избавить от необходимости набирать номер, но оно работает только при четком произношении цифр номера одну за другой. 

В каждой профессии есть ритуал инициации, о котором не принято говорить вслух. У хирургов — первая ночная смена с тяжёлым пациентом. У пилотов — посадка вслепую на тренажёре. У багхантеров и пентестеров есть Карлос. Да, тот самый Carlos, чей пароль или токен вы будете выгрызать из экзаменационного приложения PortSwigger, пока где-то на фоне тикает таймер, а Burp Collaborator хранит гробовое молчание.

Меня зовут Султан. Первая попытка, два часа — экзамен сдан.

Я знаю, о чём вы подумали: сдать BSCP с первого раза удаётся очень немногим, даже опытным специалистам. Так почему у меня получилось? Ответ — в методологии.

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

Свежая CVE-2026-31431 только набирает обороты, и тут я хочу показать, почему это не совсем обычная LPE.

Copy Fail как примитив Process Injection через Page Cache

Оригинальный PoC модифицирует setuid binary перед execve и получает root.
Второй публичный PoC подменяет id у текущего юзера на 0000.

Хорошие, рабочие LPE, дающие рута.

Но исследуя дополнительные свойства этого примитива я обнаружил несколько эффектов, не описанных в оригинальном disclosure.

Вайбкод это круто, пока не открываешь первый отчёт сканера безопасности и не видишь 234 проблемы. В статье разберём, как выстроить пайплайн вокруг LLM-проекта: подключить SAST-инструменты, настроить Quality Gate как блокировщик деплоя и использовать модель для исправлений — не вместо инструментов, а поверх них. Покажу на реальном проекте с реальными цифрами. Будет полезно тем, кто активно использует LLM для написания кода, и специалистам в области appsec/devsecops.

Часть 1 — контекст, данные из отчёта DryRun Security и немного теории про DevSecOps.

Часть 2 — подключаем SonarCloud, настраиваем Quality Gate, интегрируем в CI/CD.

Часть 3 — первый скан реального проекта: 234 проблемы, как их разбирать и исправлять через Claude 4.6.

Часть 4 — добавляем Semgrep, смотрим, где инструменты расходятся и где ломается подход.

«Мне прислали фишинг под MAX. Внутри оказался MITM в их API» «Не ты ли на фото?» — пришло поздно вечером, в обычной переписке, от знакомого, который пишет редко. К сообщению приложена короткая ссылка. Я понял, что у него увели аккаунт, и захотел разобраться, что внутри. Через пять дней я смотрел на инфраструктуру из 179 фишинговых доменов, четырёх хостингов, через которые оператор переезжал каждые сутки, и обнаружение, что фишинг-кит работает не как сборщик паролей, а как MITM-прокси к настоящему API мессенджера MAX. Жертва получает реальный SMS от реального MAX и не может распознать атаку. CVSS 8.8. VK молчит уже неделю.

MCP-серверы не умеют в авторизацию, n8n не умеет в per-user токены, а OAuth-клиенты говорят на разных диалектах. Рассказываем, как один Auth Proxy перед FastMCP Gateway закрыл все три проблемы — и почему в итоге бот переехал на LangGraph

Выявить уязвимость до того, как ею воспользуются злоумышленники, разобраться в тонкостях безопасности информационных систем, освоить инструменты пентестеров под руководством опытных наставников — всё это можно попробовать на практике на стажировке в DSEC by Solar. Ждем ваши заявки до 10 мая!