Hacker News Digest

В 2026 году 16-летний исследователь безопасности Фаав обнаружил критическую уязвимость в внутреннем сервисе Microsoft Titan, позволявшую обойти аутентификацию. Сервис не проверял цифровую подпись JWT-токенов — достаточно было подделать поле upn на admin, чтобы получить права администратора и выполнять произвольные SQL-запросы к 17,3 триллионам строк данных без реальных учётных данных. Доступ к таблицам был получен лишь через метаданные из архивов Wayback Machine и тестовые примеры, без доступа к внутренней сети.

Фаав использовал собственный AI-бота Antares для автоматического поиска уязвимостей, но ключевой прорыв произошёл после ночной догадки: замена upn на admin сработала. Уязвимость была немедленно исправлена Microsoft, за что исследователь получил $5 000. Важнейший урок: даже сложные системы аутентификации бесполезны, если не проверяется подпись токена — это фундаментальная ошибка, которую легко допустить, но невозможно игнорировать.

Сообщество считает выплату в $5 000 за уязвимость, позволяющую выполнять произвольные SQL-запросы к 17 трлн строк, заниженной и не отражающей реальную стоимость эксплойта. В то время как @muglug полагает, что сумма оправдана вероятностью использования бага государственными акторами, @bix6 и другие требуют минимум $100 000. Программы вознаграждений Microsoft часто называют «патетичными» на фоне других компаний. Критическим уязвимым местом признан алгоритм JWT "none", который необходимо удалить из спецификаций и реализаций. Для защиты рекомендуется использовать и регулярно обновлять библиотеку Microsoft Identity Service Essentials (MISE). Низкие выплаты и эксплуататорский контроль Microsoft над текстом раскрытия (особенно в случае с несовершеннолетним автором) могут подтолкнуть исследователей к продаже данных на чёрный рынок или привести к юридическим конфликтам. Для исправления ситуации предлагается повышать вознаграждения за критические баги и ввести законодательные гарантии защиты исследователей, раскрывающих уязвимости без нанесения вреда.

Страница Trust Status Salesforce предоставляет информацию о текущем состоянии сервисов и позволяет пользователям получать персонализированные обновления о техническом обслуживании и инцидентах через My Trust Center. Основная цель — повышение прозрачности и доверия за счёт индивидуальных уведомлений, адаптированных под конкретные арендаторы (tenants) клиентов. На странице также реализована система управления согласием на использование cookie-файлов, разделённая на три категории: обязательные, функциональные и рекламные. Обязательные cookie-файлы всегда активны и обеспечивают базовую работу сайта, включая аутентификацию и безопасность. Функциональные и рекламные cookie-файлы можно включать или отключать по выбору пользователя: первые улучшают производительность и анализ трафика, вторые отслеживают поведение для таргетированной рекламы. Интерфейс включает переключатели для каждой категории, детали по каждому типу cookie и кнопки для применения, сброса или принятия всех настроек. Страница также содержит ссылки на политику конфиденциальности, основной сайт Salesforce и Trust-платформу, а также отмечает copyright 2026 года. Все элементы направлены на соблюдение норм защиты данных и предоставление пользователям контроля над их информацией.

Обсуждение дополняет статью, раскрывая реальные проблемы эксплуатации Salesforce: устаревшая инфраструктура, сложная диагностика из-за неясного статус-пейджа, и критику бloatware-подхода, несмотря на компетентность SRE-команды. Сбой произошёл из-за каскадного исчерпания ресурсов в устаревшей службе входа Salesforce, что подтверждается деталями инцидента на их статус-странице. Статус-страница Salesforce остаётся непрозрачной для пользователей — содержит произвольные ID и неясные описания сбоев, несмотря на попытки персонализации. Сбой совпал с Dreamforce, что усилило негативное восприятие, так как компания демонстрирует свои продукты в момент критического падения. По опыту @stmw, SRE-команда Salesforce компетентна, но масштаб PaaS с миллионами кастомных приложений создаёт уникальные инженерные вызовы, которые неизбежно приводят к сбоям. Некоторые пользователи считают, что Salesforce превратился в монолитный бloatware, который нужно заменить простыми альтернативами; другие признают сложность его инфраструктуры. Инцидент подтверждает, что даже крупные платформы уязвимы к сбоям в базовых компонентах, таких как аутентификация, и это не связано с AI или DNS, как предполагали некоторые. Пользователи отмечают, что Salesforce-системы часто содержат сотни кастомных полей с дублирующей семантикой, что усложняет поддержку и увеличивает риск сбоев. Сбой вызвал ироничные комментарии о том, что пользователи получили «бесплатный день без спама» и смогли реально поработать.

В августе GitHub пережил два крупных сбоя: 6‑го и 17‑го число сервисы, включая сайт, аутентификацию, Actions, API, Pull Requests, Issues и Copilot, были недоступны почти восемь часов. Причиной стал резкий рост нагрузки, превысивший возможности центрального дата‑центра в США, где ключевой компонент не смог масштабироваться. Восстановление потребовало перераспределения трафика, изоляции проблемного оборудования и поэтапного возврата сервисов; ошибки в Copilot‑службах даже вызвали бесконечные повторные попытки клиентов, усугубив нагрузку.

В ответ компания ускорила инвестиции в ёмкость: за последние месяцы добавили более 3 млн процессорных ядер, 120 петабайт высокоскоростного хранилища и значительный сетевой ресурс, перенёс часть нагрузки в Azure (сейчас 58 % платформенного трафика обслуживается там). Были введены ограничения на повторные запросы, бюджеты таймаутов и пересмотрены низкоприоритетные оповещения, чтобы избежать каскадных сбоев. Тем не менее, рост активности — 2,9 млрд коммитов в месяц и 24 млн новых репозиториев — требует дальнейших архитектурных изменений, чтобы гарантировать надёжность, без которой разработчики не могут создавать и выпускать программное обеспечение.

Сбой GitHub вызван не нехваткой емкости, а отсутствием отказоустойчивости: системы коллапсируют при перегрузке, вместо того чтобы отбрасывать низкоприоритетный трафик. Клиентские retry-циклы, особенно в VS Code, усилили нагрузку в 10 раз и замедлили восстановление — это системная проблема, а не баг. Рост коммитов с 1,4 до 2,9 млрд в месяц за несколько месяцев указывает на массовое внедрение AI-агентов, что не было учтено при проектировании инфраструктуры. Рост CPU и хранилища не решает проблему — если архитектура не предусматривает graceful degradation, масштабирование лишь откладывает катастрофу. Нужно выставлять алерты при 80% загрузки, отслеживать лимиты не только сервисов, но и sidecar-контейнеров (например, Istio). Внедрять client-side throttling: при 5xx клиенты должны замедлять запросы, а не перезапрашивать. Трафик отдельных клиентов должен изолироваться, чтобы перегрузка одного не затрагивала других, особенно платных. Прогнозирование нагрузки (как в CloudWatch) важнее реактивного масштабирования. GitHub стал уязвимым централизованным монополистом — его сбой затрагивает всю экосистему, что стимулирует альтернативы: децентрализованные форки и локальные системы код-ревью. Платформа, скрывающая ошибки под спиннерами, нарушает принцип прозрачности для разработчиков. Рост GitHub Actions в выходные показывает, что AI-автоматизация затронула и личные проекты. Споры: разделить бесплатные и платные репозитории, чтобы enterprise-клиенты не страдали от AI-трафика — или сохранить открытость? Ввести плату за коммиты — или считать убытки GitHub оправданными, если они стимулируют Azure и OpenAI? Разработка AI-агентов для оптимизации внутренней инфраструктуры логична, но компания фокусируется на внешних функциях, а не на стабильности.

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

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

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

SSO Wall of Shame — список вендоров, считающих SSO роскошью, а не базовой безопасностью.

SSO позволяет компании управлять доступом через собственный поставщик идентификации (Google, Okta, Azure AD), централизованно создавать/удалять аккаунты и мгновенно отключать уволенных сотрудников. Для любой организации >5 человек это критично.

Однако вендоры прячут SSO за «Enterprise»-тарифами, где цена выше в 2–4 раза или привязана к большому пакету ненужных функций. Это тормозит внедрение безопасности.

Примеры завышенных надбавок

Вендор	Базовая цена	SSO-цена	Рост
Airtable	$10/польз./мес	$60	+500 %
Appsmith	$15	$2 500	+16 567 %
Coursera	$399/польз./год	$49 875/год	+12 400 %
Cloudflare	$20/домен/мес	$1 000	+4 900 %
Breezy HR	$171/мес	$1 500	+777 %
DatoCMS	$100/мес	$667	+567 %
Canva	$10/польз./мес	$40	+300 %
Figma	$12	$45	+275 %
Bitrise	$90	$270	+200 %
Box	$5	$15	+200 %

(и ещё ~30 компаний с ростом 15–167 %).

Вывод: если вендор «серьёзно относится к безопасности», SSO должен быть либо в базе, либо за умеренную доплату.

• «SSO-налог» — это не техническая, а ценовая сегментация: крупные клиенты обязаны иметь SSO (SOC2), поэтому за него платят.
• Поддержка SSO действительно дорога: множество тикетов, сложные интеграции, вызовы инженеров, особенно при частных IdP.
• Часть вендоров всё же даёт базовый SSO через Google/GitHub/Microsoft, но «частный IdP» остаётся маркером Enterprise.
• Малым компаниям SSO тоже нужен по контрактам, но высокие цены отталкивают; кто-то предлагает субсидии или прокси-решения.
• Итог: SSO = не «фича», а показатель зрелости клиента и объём его кошелька.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.