Безопасность цифровых данных всегда была приоритетом, но недавнее открытие, сделанное компанией Truffle Security из Сан-Франциско, поднимает серьезные вопросы о надежности системы аутентификации Google «Войти с Google". Эта уязвимость, связанная с механизмом OAuth, позволяет злоумышленникам получать доступ к конфиденциальной информации, используя, казалось бы, безобидные изменения в правах владения доменными именами.
Суть проблемы заключается в том, как сторонние SaaS-провайдеры используют данные, получаемые через Google OAuth. Вместо того, чтобы полагаться на уникальный и неизменяемый идентификатор пользователя, известный как "sub claim", многие сервисы используют адрес электронной почты и связанный с ним домен. Это создает возможность для злоумышленников, которые могут приобрести домен обанкротившейся компании и воссоздать учетные записи электронной почты бывших сотрудников. Получив таким образом доступ, они могут проникнуть в личные учетные записи этих сотрудников в различных SaaS-сервисах.
Эта уязвимость ставит под угрозу множество конфиденциальных данных. В частности, это может касаться HR-систем, содержащих налоговые документы, платежные ведомости и номера социального страхования. Кроме того, под ударом могут оказаться и платформы для проведения собеседований, содержащие отзывы о кандидатах, предложения о работе и отказы. Даже такие сервисы, как Slack, Notion, Zoom и OpenAI ChatGPT, могут стать жертвами этой бреши.
Первоначально Google не считал это уязвимостью, но после обращения Truffle Security, возглавляемой соучредителем и генеральным директором Диланом Эйри, Google пересмотрел свою позицию и 19 декабря 2024 года возобновил работу над отчетом об ошибке. Компания признала, что это представляет собой злоупотребление с серьезными последствиями. За обнаружение уязвимости Дилан Эйри получил от Google вознаграждение в размере 1337 долларов.
Google признал необходимость срочных мер и выпустил обновленную документацию 15 января (предположительно 2025 года), предупреждая о том, что не следует использовать поле электронной почты в ID-токене в качестве уникального идентификатора. Компания подчеркивает, что необходимо использовать поле "sub". Это поле, или так называемый "subject" claim, является уникальным и неизменяемым для каждого пользователя. Аналогичный механизм используется и в Microsoft Entra IDs, где для идентификации пользователя применяется "oid claim".
Важно понимать, что ответственность за предотвращение этой уязвимости лежит не только на Google, но и на самих поставщиках SaaS-услуг. Именно они должны обновить свои приложения, чтобы использовать "sub claim" для уникальной идентификации пользователей. Это означает, что многие сервисы должны будут внести значительные изменения в свои системы аутентификации, чтобы защитить данные пользователей.
Несмотря на действия Google, риск все еще существует, особенно для тех пользователей, которые были уволены из стартапов. Если сервисы по-прежнему будут использовать адрес электронной почты для проверки подлинности, эти пользователи останутся уязвимыми. Утеря контроля над электронной почтой в домене бывшей компании приведет и к утере контроля над данными в связанных аккаунтах.
Таким образом, проблема не в самом протоколе OAuth, а в том, как он был реализован Google и как сторонние сервисы используют полученные данные. Принципиально важным является понимание того, что "sub claim" является единственным надежным способом идентификации пользователя. Это неизменяемое поле, в отличие от адреса электронной почты и "hosted domain", которые могут меняться.
Уязвимость «Войти с Google" подчеркивает критическую необходимость в строгих мерах безопасности при обработке пользовательских данных. Все поставщики программного обеспечения должны пересмотреть свои процессы аутентификации и убедиться, что они не полагаются на подверженные манипуляциям идентификаторы. В противном случае, конфиденциальные данные пользователей будут оставаться в постоянной опасности.
Случай с Google является ярким примером того, как кажущиеся незначительными детали в реализации протоколов могут иметь далеко идущие последствия. Беспечность в этой области может привести к серьезным нарушениям безопасности и масштабным утечкам конфиденциальных данных. Внедрение безопасных практик, подобных использованию "sub claim", является не просто лучшей практикой, а необходимостью.
Изображение носит иллюстративный характер
Суть проблемы заключается в том, как сторонние SaaS-провайдеры используют данные, получаемые через Google OAuth. Вместо того, чтобы полагаться на уникальный и неизменяемый идентификатор пользователя, известный как "sub claim", многие сервисы используют адрес электронной почты и связанный с ним домен. Это создает возможность для злоумышленников, которые могут приобрести домен обанкротившейся компании и воссоздать учетные записи электронной почты бывших сотрудников. Получив таким образом доступ, они могут проникнуть в личные учетные записи этих сотрудников в различных SaaS-сервисах.
Эта уязвимость ставит под угрозу множество конфиденциальных данных. В частности, это может касаться HR-систем, содержащих налоговые документы, платежные ведомости и номера социального страхования. Кроме того, под ударом могут оказаться и платформы для проведения собеседований, содержащие отзывы о кандидатах, предложения о работе и отказы. Даже такие сервисы, как Slack, Notion, Zoom и OpenAI ChatGPT, могут стать жертвами этой бреши.
Первоначально Google не считал это уязвимостью, но после обращения Truffle Security, возглавляемой соучредителем и генеральным директором Диланом Эйри, Google пересмотрел свою позицию и 19 декабря 2024 года возобновил работу над отчетом об ошибке. Компания признала, что это представляет собой злоупотребление с серьезными последствиями. За обнаружение уязвимости Дилан Эйри получил от Google вознаграждение в размере 1337 долларов.
Google признал необходимость срочных мер и выпустил обновленную документацию 15 января (предположительно 2025 года), предупреждая о том, что не следует использовать поле электронной почты в ID-токене в качестве уникального идентификатора. Компания подчеркивает, что необходимо использовать поле "sub". Это поле, или так называемый "subject" claim, является уникальным и неизменяемым для каждого пользователя. Аналогичный механизм используется и в Microsoft Entra IDs, где для идентификации пользователя применяется "oid claim".
Важно понимать, что ответственность за предотвращение этой уязвимости лежит не только на Google, но и на самих поставщиках SaaS-услуг. Именно они должны обновить свои приложения, чтобы использовать "sub claim" для уникальной идентификации пользователей. Это означает, что многие сервисы должны будут внести значительные изменения в свои системы аутентификации, чтобы защитить данные пользователей.
Несмотря на действия Google, риск все еще существует, особенно для тех пользователей, которые были уволены из стартапов. Если сервисы по-прежнему будут использовать адрес электронной почты для проверки подлинности, эти пользователи останутся уязвимыми. Утеря контроля над электронной почтой в домене бывшей компании приведет и к утере контроля над данными в связанных аккаунтах.
Таким образом, проблема не в самом протоколе OAuth, а в том, как он был реализован Google и как сторонние сервисы используют полученные данные. Принципиально важным является понимание того, что "sub claim" является единственным надежным способом идентификации пользователя. Это неизменяемое поле, в отличие от адреса электронной почты и "hosted domain", которые могут меняться.
Уязвимость «Войти с Google" подчеркивает критическую необходимость в строгих мерах безопасности при обработке пользовательских данных. Все поставщики программного обеспечения должны пересмотреть свои процессы аутентификации и убедиться, что они не полагаются на подверженные манипуляциям идентификаторы. В противном случае, конфиденциальные данные пользователей будут оставаться в постоянной опасности.
Случай с Google является ярким примером того, как кажущиеся незначительными детали в реализации протоколов могут иметь далеко идущие последствия. Беспечность в этой области может привести к серьезным нарушениям безопасности и масштабным утечкам конфиденциальных данных. Внедрение безопасных практик, подобных использованию "sub claim", является не просто лучшей практикой, а необходимостью.
