Hacker News Digest

Исследователь безопасности обнаружил критическую уязвимость удалённого выполнения кода на сайтах документации Google для разработчиков. Всё началось с анализа OAuth-потока: при обращении к /oauth2authorize сервер устанавливал сессионную cookie Flask размером около 1200 байт. Поскольку cookie подписываются, но не шифруются, содержимое оказалось доступно для чтения. Внутри лежал сериализованный через pickle объект OAuth2WebServerFlow, содержавший в открытом виде client_id и client_secret OAuth-приложения Google.

Ключевая находка: этот же client_secret использовался как SECRET_KEY для подписи сессий Flask. Исследователь воспроизвёл подпись офлайн через itsdangerous с производным ключом cookie-session — результат совпал байт в байт. Это означало полную потерю целостности сессии: можно было подделать любые значения и получить валидную подпись. Поскольку callback распаковывал объект потока через pickle.loads, атакующий мог подсунуть произвольный pickle с опасным опкодом REDUCE, что давало неаутентифицированное RCE.

Для доказательства без вреда продакшену использовался payload с time.sleep(N) — задержка ответа точно соответствовала заданному числу секунд. Уязвимость затронула несколько хостов DevSite, включая firebase.google.com, developer.android.com и source.android.com. Google выпустил хотфикс в течение суток, а выплата составила $90 000: базовые $75 000 за RCE уровня S0 с коэффициентом 1.2 за качество отчёта. Рекомендации включают ротацию секретов, отдельный SECRET_KEY для каждой инсталляции, хранение OAuth-объекта на сервере и отказ от pickle на границе с клиентом.

Обсуждение поднимает вопросы о признании вклада LLM, роли человеческой экспертизы, влиянии стиля LLM‐текстов на восприятие, недопустимости практик вроде pickle в cookie и будущем размера баунти, подтверждая, что Google продолжает выплачивать крупные вознаграждения за критические уязвимости. Спор: одни считают, что автор должен указывать, что LLM (Claude) нашёл уязвимость, иначе человек лишён агентства; другие утверждают, что без человеческого направления LLM бы не нашёл баг, поэтому кредит остаётся за исследователем. Большинство согласны: LLM — лишь инструмент, его использование должно быть открыто, но результат зависит от опыта и вопросов, задаваемых человеком. Совет: рост применения ИИ может снизить размер баунти до уровня стоимости токенов, поэтому исследователям стоит готовиться к более скромным выплатам. Критика стиля: блог, написанный полностью LLM, отталкивает читателей и усложняет восприятие технических деталей. Упоминание: использование pickle в cookie с подписью — серьёзное упущение, маловероятно пройти код‐ревью или автоматическое тестирование в крупных проектах. Совет для новичков: осваивать AI‐инструменты, но одновременно углублять фундаментальные знания о протоколах и механизмах, иначе AI останется лишь «начинающим» помощником. Выплата $90 000 за найденную уязвимость подтверждает, что Google всё ещё готов платить крупные суммы за критические RCE, несмотря на обсуждения об изменении рынка.

SAML — протокол аутентификации на основе XML, созданный в 2002 году комитетом OASIS из четырёх конкурирующих стандартов — стал основой индустрии единого входа (SSO). Он успешно решал задачу централизованной аутентификации в эпоху роста SaaS, особенно в академии и корпоративной IT, но его сложность оказалась катастрофической: XML-подписи, требующие проверки через непрозрачные библиотеки вроде libxmlsec, стали источником уязвимостей, которые большинство реализаций просто игнорируют. Дизайн «по комитету» привёл к избыточности, а архитектура — к хрупкости, несовместимости и трудностям в поддержке.

Современные альтернативы, особенно OpenID Connect (OIDC) на основе JSON и OAuth 2.0, значительно проще, безопаснее и легче интегрируются. Ведущие компании вроде Fly.io и Tailscale уже отказались от SAML, доказав, что даже для крупных корпоративных клиентов OIDC — жизнеспособный выбор. Для провайдеров идентичности путь отказа от SAML долгий, но пошаговый: остановить новые SAML-интеграции, перевести клиентов на OIDC, назначить дату отключения. SAML заслужил своё место в истории как катализатор SSO, но его пора заменить — как и XML, как и устаревшие подходы, которые больше не оправдывают свою цену.

SAML остается актуальным в корпоративной среде из-за поддержки IdP-инициированных потоков и устойчивости в закрытых сетях, несмотря на свою сложность, а OIDC не решает всех проблем, особенно в условиях изоляции от публичных провайдеров.

• Совет: Для интеграции SAML в JVM-приложения рекомендуется использовать pac4j — он упрощает работу с различными фреймворками и скрывает сложность низкоуровневых деталей.

• SAML и OIDC оба страдают от сложных реализаций: SAML — из-за XMLDSIG и канонизации, OIDC — из-за уязвимостей JWT (none-алгоритм, отсутствие проверки audience).

• Спор: Некоторые утверждают, что SAML уязвим из-за XML-подписей, но другие отмечают, что OIDC с JWT имеет не менее опасные уязвимости, включая возможность смены алгоритма подписи на 'none'.

• Проблема SAML не в XML как таковом — в 2002 году XML был логичным выбором, а альтернативы (ASN.1, кастомный формат) были не проще и не безопаснее.

• Совет: Для enterprise-продуктов поддержка SAML обязательна, так как корпоративные клиенты требуют совместимости с их существующими IdP, и отказ от SAML делает продукт невосприимчивым к рынку.

• SAML поддерживает IdP-инициированные потоки, что критично для корпоративных SSO, тогда как OIDC требует инициации от SP, что не всегда возможно в закрытых сетях.

• Спор: Одни считают, что SAML безопасен благодаря встроенной подписи, защищающей от MITM, другие возражают, что уязвимости в реализациях (например, проверка подписи по HMAC из атакуемого документа) делают его ненадежным.

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

• Совет: Для снижения сложности SAML можно поддерживать только дайджесты топ-10 провайдеров и игнорировать нишевые реализации — это уменьшает объем поддержки без потери функциональности.

• Проблемы SAML не в стандарте, а в его реализациях: библиотеки libxml2 и другие неправильно обрабатывают XML-ноды, что позволяет обходить аутентификацию через MITM.

• Совет: Индивидуальные решения вроде IndieAuth и новых паттернов на базе OAuth, FedCM и DIDs обещают децентрализованную аутентификацию, но пока не получили широкой поддержки.

• OIDC не может работать с приватными IdP без публичного доступа, тогда как SAML поддерживает интеграцию в изолированных корпоративных сетях без внешних зависимостей.

• Комитетная разработка SAML привела к 'кухонному ракетостроению' — избыточным функциям, которые усложняют реализацию, в отличие от фокусированных решений вроде WireGuard.

• Совет: При интеграции SAML всегда проверяйте, что подпись применяется только к конкретной части документа, а не ко всему телу — это частая ошибка в реализациях.

• Большинство компаний не хотят поддерживать децентрализованную аутентификацию, потому что предпочитают монетизировать SSO через дополнительные услуги: анти-спам, восстановление паролей, контроль создания аккаунтов.

Thunderbird версии 145 теперь официально поддерживает нативный доступ к Microsoft Exchange через протокол Exchange Web Services (EWS). Это означает, что больше не требуется стороннее расширение для работы с почтой. Интеграция обеспечивает полное отображение папок, синхронизацию сообщений, управление папками как локально, так и на сервере, а также обработку вложений. Для настройки достаточно создать новый аккаунт в Thunderbird, выбрать Exchange и разрешить клиенту автоматически определить параметры.

В настоящее время поддерживается только функционал электронной почты; интеграция с календарем и адресной книгой находится в разработке и будет добавлена в будущих релизах. Thunderbird использует стандартный процесс входа Microsoft (OAuth2) и автоматически определяет настройки аккаунта, что упрощает переход с Outlook. Разработчики также отмечают, что Microsoft постепенно отказывается от EWS в пользу более современного интерфейса Microsoft Graph, поддержка которого также запланирована на будущее.

• Thunderbird теперь поддерживает Exchange, но пока без календаря и контактов, что вызывает сомнения в полноте реализации.
• Пользователи отмечают, что Thunderbird всё ещё не реализовал полную поддержку календаря и адресной книги, что делает его менее привлекательным для корпоративных пользователей.
• Некоторые комментаторы подчеркивают, что Microsoft не предоставляет полной документации или стабильного API для Exchange, что делает разработку сложной.
• Некоторые пользователи выражают обеспокоенность, что Thunderbird не поддерживает Graph API, что может ограничить его функциональность.
• Некоторые комментаторы подчеркивают, что Thunderbird не поддерживает MAPI, что может ограничить его функциональность.