Sso pop device что это такое
Что такое поп-устройство Sso?
Единый вход в систему (SSO) позволяет пользователям получать доступ к нескольким ресурсам (то есть к приложениям и процедурам адаптера) путем аутентификации только один раз.
Что такое пользователь SSO Pop?
Пользователь и устройство sso pop являются частью компонентов диспетчера учетных данных части единого входа учетных записей Microsoft, которые используются в текущих версиях Windows. … Без этого работа Windows 8. x или 10 стала бы очень шумной и раздражающей, с почти постоянными всплывающими окнами с просьбой войти в систему.
Что такое SSO_POP_Device?
SSO_POP_Device создается при входе в систему с учетной записью Microsoft. Это обычные учетные данные, которые вы можете «удалить», если хотите, но они вернутся снова. … SSO_POP_Device создается при входе в систему с учетной записью Microsoft. Это обычные учетные данные, которые вы можете «удалить», если хотите, но они вернутся снова.
Что такое VirtualApp Didlogical?
Virtualapp / Didlogical — это учетные данные, которые сохраняются при использовании любого из продуктов Windows Live, в том числе Windows Live Messenger, Windows Live Mail, Windows Live Sign-In Assisstant, Windows XP Mode и других служб Microsoft. Вы можете удалить запись из диспетчера учетных данных.
Могу ли я удалить учетные данные Windows?
В разделе «Учетные данные Windows и общие учетные данные» удалите все сохраненные учетные данные, относящиеся к Office 365 или Microsoft Office: выберите учетные данные. Щелкните «Удалить». Щелкните Да в окне предупреждения.
Что такое Windowslive?
Windows Live Mail — это программа электронной почты для настольных компьютеров, которую Microsoft представила на замену Outlook Express. Он является частью пакета Windows Essentials, который включает несколько прекрасных программ: Live Mail, Live Writer, Photo Gallery, MovieMaker и OneDrive.
Безопасен ли диспетчер учетных данных Windows?
Диспетчер учетных данных Windows совсем не безопасен. Это «безопасно» на уровне учетной записи пользователя, что означает, что любой процесс, который пользователь когда-либо запускал, и сам пользователь обязательно должны быть доверенными, чтобы с невозмутимым видом называть эту систему «безопасной».
Что такое универсальные учетные данные?
Общие учетные данные — любой ресурс, использующий базовую аутентификацию, например имя пользователя и пароль. В этом разделе будет ссылка на добавление, редактирование, резервное копирование, восстановление и удаление учетных данных в Windows Vault.
Как мне избавиться от Virtualapp Didlogical?
Безопасно ли удалить Virtualapp / Didlogical?
Как мне изменить свои учетные данные Onedrive?
Для чего используются общие учетные данные?
Общие учетные данные
Приложения используют функции управления учетными данными, чтобы запрашивать у пользователей определяемую приложением общую учетную информацию, такую как имя пользователя, сертификат, смарт-карта или пароль. Информация, введенная пользователем, возвращается в приложение для аутентификации.
Где хранятся общие учетные данные?
В Windows 10 и Windows 8.1 учетные данные на основе сертификатов и общие учетные данные сгруппированы в разделе Учетные данные Windows. Эти учетные данные автоматически сохраняются и управляются Windows и используемыми вами приложениями.
Где хранятся пароли в Windows?
Все пароли локальных учетных записей пользователей хранятся в окнах. Они расположены внутри C: windows system32 config SAM. Если компьютер используется для входа в домен, то это имя пользователя и пароль также сохраняются, поэтому можно войти в компьютер, когда он не подключен к домену.
Что произойдет, если я удалю учетные данные?
При очистке учетных данных удаляются все сертификаты, установленные на вашем устройстве. Другие приложения с установленными сертификатами могут потерять некоторые функции.
Как удалить старые учетные данные из Windows 10?
Попробуйте следующие шаги:
Как мне избавиться от сетевых учетных данных в Windows 10?
Как отключить сетевые учетные данные в Windows 10?
SAML простыми словами
Что такое SAML?
SAML — сокращение от Security Assertion Markup Language (Язык разметки декларации безопасности). Его ключевая роль в обеспечении сетевой безопасности заключается в том, что он позволяет получить доступ в несколько приложений, используя один набор учетных данных для авторизации. Он работает посредством обмена аутентификационной информацией в определенном формате между участниками, в частности, между системой управления доступами и веб-приложением.
Как работает SAML
SAML — это открытый стандарт обмена данными аутентификации, основанный на языке XML. Веб-приложения используют SAML, чтобы передавать аутентификационные данные между сторонами процесса: а именно, между системой управления доступами и провайдером услуг.
SAML появился в индустрии высоких технологий для упрощения процесса аутентификации, когда пользователям нужно было получить доступ к нескольким независимым веб-приложениям в разных доменах. До появления SAML, технология единого входа (SSO) была вполне достижима/выполнима, но базировалась на файлах cookies, которые были жизнеспособны только в пределах одного домена.
Здесь же, эта цель достигается за счет согласования процесса аутентификации с системой управления доступами. Веб-приложения могут использовать SAML через систему управления доступами для предоставления доступа пользователям. Такой метод аутентификации означает, что пользователям больше не нужно запоминать множественные комбинации логинов и паролей. Более того, он обладает несомненным преимуществом для провайдера в виде повышения уровня безопасности платформы, преимущественно благодаря отсутствию необходимости хранить пароли и разбираться и с их восстановлением.
Преимущества SAML
Благодаря своим многочисленным преимуществам, SAML является довольно широко используемым корпоративным решением. Во-первых, он улучшает пользовательский интерфейс, ведь теперь нужно всего лишь один раз авторизоваться, чтобы получить доступ к нескольким приложениям. Это не только ускоряет процесс аутентификации, но также означает, что вам нужно держать в памяти лишь один набор учетных данных для входа. В корпоративном плане SAML также значительно упрощает работу, т.к количество обращений в службу поддержки, связанных восстановлением утраченных и забытых паролей будет значительно ниже.
В дополнение, SAML не только улучшает взаимодействие с пользователем, но и обеспечивает повышенный уровень безопасности. Поскольку система управления доступами хранит всю информацию для входа, поставщику услуг больше нет необходимости хранить какие-либо учетные данные в своей базе.
Плюс ко всему, теперь, когда система управления доступами обеспечивает безопасную SAML аутентификацию, у компаний появляется возможность инвестировать появившееся время и ресурсы в разработку нескольких/новых уровней безопасности. Например, система управления доступами обеспечивает комплексную защиту личных данных, что включает в себя такие функции, как многофакторная аутентификация (MFA), которая защищает от наиболее распространенных атак на конфиденциальную информацию.
Процесс работы
SAML работает путем обмена пользовательской информацией (логины, состояние аутентификации, идентификаторы и другие данные) между системой управления доступами и поставщиком услуг. В результате это упрощает и обеспечивает безопасность процесса аутентификации, ведь теперь пользователю необходимо войти в систему только один раз, используя один набор данных для входа. Таким образом, когда пользователь запрашивает доступ к сайту, SAML передает аутентификационные данные поставщику услуг, который впоследствии предоставляет доступ пользователю. Проведем аналогию с реальностью.
Разумеется, перед предоставлением доступа к информации, компании проверяют ваши личные данные. Возьмем, к примеру, авиакомпании. Перед посадкой на самолет им необходимо убедиться что вы именно тот, за кого себя выдаете, чтобы обеспечить полную безопасность других пассажиров. Поэтому им необходимо предоставить официально заверенный государственный документ, удостоверяющий личность. Как только они убедятся в том, что информация в документе совпадает с указанной в билете, вы будете допущены на борт самолета.
Здесь государство является примером системы управления доступами, авиакомпания — поставщиком услуг, а ваше удостоверение личности, выданное правительством — SAML подтверждением. Когда вы подаете заявку на оформление документов государственного образца, вам необходимо заполнить бланк, прикрепить фотографию и, если это необходимо, также предоставить отпечатки пальцев. Далее государство (поставщик услуг) переносит информацию о вас в базу данных и выдает физический документ, подтверждающий личность.
Вернемся к нашему примеру с авиакомпанией. Перед посадкой на самолет сотрудники авиакомпании (поставщика услуг) снова проверяют удостоверение личности (SAML подтверждение). Сразу после успешной аутентификации, авиакомпания разрешает посадку на борт.
Что такое SAML SSO?
SAML Single Sign-On (Технология единого входа) — это механизм, использующий SAML в качестве инструмента, позволяющего пользователям авторизовываться сразу в нескольких приложениях, стоит только один раз ввести логин и пароль в системе управления доступами. SAML SSO обеспечивает гораздо более быстрый и удобный пользовательский интерфейс.
SAML SSO прост в использовании и более безопасен для пользователя, ведь теперь нужно запомнить всего лишь один набор учетных данных. По той же причине он обеспечивает быстрый и беспрепятственный доступ к приложениям, так как теперь нет необходимости каждый раз вводить логин и пароль. Вместо этого пользователь авторизуется в системе управления доступами и заходит в необходимое приложение, просто кликнув на его иконку или перейдя на сайт через URL.
В дополнение к расширенному пользовательскому интерфейсу, SAML SSO обладает и другими преимуществами. Он увеличивает производительность как пользователя, так и службы поддержки. Пользователям больше не нужно тратить время на авторизацию в разных приложениях, вспоминая логины и пароли. Как следствие, служба поддержки не будет завалена запросами на сброс и восстановление пароля, освобождая время сотрудников на решение других вопросов, связанных с технической поддержкой.
Что немаловажно — SAML SSO помогает сократить расходы. Например, если у службы поддержки есть запрос на сокращение количества обращений, вместо того, чтобы создавать систему собственной локальной аутентификации для решения этой задачи, они могут просто использовать уже готовую систему управления доступами, снижая трудозатраты на ее создание и внутреннее обслуживание.
В чем разница между OAuth и SAML?
OAuth и SAML — это протоколы, используемые для предоставления доступа. Однако, радикальным отличием между ними является то, что SAML используется для аутентификации, а OAuth для авторизации.
Пример SAML
Процесс аутентификации SAML базируется на claims (данных пользователя). На первом этапе, когда пользователь пытается получить доступ к сайту, поставщик услуг запрашивает аутентификацию пользователя у системы управления доступами. Затем, поставщик услуг использует SAML подтверждение, выданное системой управления доступами, для предоставления доступа пользователю. Проиллюстрируем данный процесс на примере:
Обучающие ресурсы
OneLogin предлагает несколько наборов инструментов разработчика SAML, которые можно использовать для внедрения SSO в свои приложения через систему управления доступами, предоставляющую SAML-аутентификацию.
Более того, вы можете получить дополнительные ресурсы с инструкциями по добавлению вашего приложения в каталог OneLogin, что необходимо изменить на стороне кода для внедрения SSO через OneLogin, а также полезные рекомендации и ответы на часто задаваемые вопросы.
Пакет разработчика The OneLogin SAML Toolkit предоставляет различные онлайн инструменты на https://www.samltool.com. Например, можно установить самостоятельно сгенерированный самозаверенный сертификат X. 509, который вы сможете использовать в тестовой среде.
Кроме того, поскольку SAML использует алгоритм кодирования Base64, OneLogin предлагает онлайн-сервис по кодированию и декодированию XML в Base64 и наоборот. Пакет разработчика также предоставляет ресурсы по шифрованию узлов из XML, подписи AuthNRequests и проверки вашего XML в соответствии со схемой SAML XSD.
В дополнение к поддержке сертификатов и предоставлению доступа к службам кодирования, декодирования, подписи и проверки XML, онлайн-инструменты OneLogin SAML предлагают разработчикам множество других полезных ресурсов. Например, вы можете создать XML метаданные службы управления доступами SAML. Есть также инструмент, который может извлечь NameID и другие необходимые данные из SAML-ответа. И наконец, онлайн-инструменты OneLogin SAML также предлагают услугу которая конвертирует XML- или SAML- сообщение в удобночитаемый к формат.
👨⚕️️ Что такое единый вход ( Single Sign-on или SSO)👨⚕️ – решение для обеспечения безопасности данных вашей компании
Single Sign-on или Единая регистрация – это метод аутентификации, который помогает войти в несколько приложений с использованием единой учетной записи.
Безопасность повышается за счет единого входа (SSO) в свете того факта, что пользователи избавляются от различных проблем с секретными паролями.
Давайте будем честными, пользователи не любят сложные пароли;
Единый вход в систему делает эту агонию более приемлемой за счет уменьшения количества сложных паролей, которые они должны помнить.
Есть две основные проблемы, с которыми сталкиваются эти предприятия:
Эти проблемы постоянно беспокоят тех, кто управляет информационными системами и данными или имеет дело с соответствием учетных записей в любой компании.
Существует четыре важных фактора, которые необходимо учитывать при разработке стратегии управления доступом и идентификации ИТ-отделом компании и системой безопасности.
Расширение стороннего доступа
Все больше организаций получают доступ к приложениям, данным и сетям компании.
Разные партнеры работают в разных местах, что может усложнить ситуацию, когда дело касается безопасности, и обеспечить доступ только нужным людям.
В исследовании, проведенном Aberdeen, было показано, что около 1/3 исследованных предприятий предоставили доступ по крайней мере 25 сторонним организациям, в то время как у 10% было свыше 200 внешних партнеров.
В этом случае единый вход (SSO) будет очень полезным решением для защиты активов вашей компании.
Балансировка между безопасностью и удобством использования
При работе с растущей пользовательской базой безопасность и стоимость имеют первостепенное значение.
Если предприятие не готово к расширению, риск проблем с безопасностью выше.
Кража данных такого типа может иметь разрушительные последствия для компании.
Хотя важно, чтобы система была доступна для людей, которым необходимо ее использовать, но и безопасность не менее важна.
Частота и стоимость кибератак
Производители имеют дело с большим количеством конфиденциальной информации и становятся жертвами большего количества фишинговых атак, чем любая другая отрасль.
Одна утечка данных стоит в среднем около 450 тыс. долларов, но может стоить значительно дороже.
Немного подготовки может сэкономить много денег и доверия.
Традиционные системные расходы
Использование традиционной системы может быть дорогостоящим, около 3,5 миллионов долларов для производителей.
В некоторых случаях это может стоить десятки миллионов, хотя использование единой платформы для управления доступом может сэкономить много денег и сэкономить время.
Многофакторная аутентификация и единый вход в систему (SSO), возможно, это решение, которое компания может внедрить, чтобы избежать атак на основе учетных данных.
Это оптимизирует весь процесс и обеспечивает поддержку для всех организаций, которые обращаются к системе, независимо от того, насколько далеко они оказались в облаке.
Уменьшите головную боль помощи пользователям с восстановлением пароля с помощью единого входа (SSO)
Представьте себе организацию с десятью различными администрациями.
Система единого входа (SSO) может невероятно уменьшить количество рабочей силы службы поддержки, которая требуется клиентам, поскольку им просто необходимо восстановить отдельную учетную запись.
Хотя это и не проблема безопасности, это является чрезвычайно очевидным преимуществом для организаций, использующих решение единой регистрации.
Единая регистрация (SSO) помогает уменьшить количество паролей, которые должны помнить пользователи.
Клиентам настоятельно рекомендуется использовать бесконечно уникальные пароли для разных систем.
Очевидно, что это не проблема, если клиент использует инструмент управления паролями, но как насчет того, насколько мы разумны, и на какое количество пользователей вы могли бы надеяться?
Система единого входа (SSO) может необычайно уменьшить количество паролей, которые необходимо запомнить пользователям, что может побудить пользователя выбрать значительно более надежный пароль.
Прозрачная авторизация на RDS с помощью SSO (Single Sign-On)
Single Sign-On (SSO — технология единого входа) это технология, позволяющая уже аутентифицированному (вошедшему в систему) пользователю получать доступ к другим сервисам без повторной аутентификации. Применительно к технологии терминальных серверов Remote Desktop Services, SSO позволяет избавить пользователя, выполнившего вход на доменном компьютере, от многократного ввода имени и пароля своей учетной записи в окне RDP клиента при подключении к RDS серверам или запуске опубликованных приложений RemoteApp.
В этой статье мы опишем особенности настройки прозрачной авторизации (Single Sign-On) пользователей на серверах RDS под управлением Windows Server 2016 и 2012 R2.
Требования к окружению:
Процедура настройки Single Sign-On состоит из следующих этапов:
Итак, в первую очередь нужно выпустить и назначить SSL сертификат. В EKU (Enhanced Key Usage) сертификата должно обязательно присутствовать идентификатор Server Authentication. Мы опускаем процедуру получения сертификата, т.к. это она выходит за рамки статьи (можно сгенерировать самоподписанный SSL сертификат, но его придется добавлять в доверенные на всех клиентах через GPO).
SSL сертификат привязывается в свойствах RDS Deployment в подразделе Certificates.
Далее на всех серверах c ролью Web Access для каталога IIS RDWeb нужно включать “Windows Authentication” и отключить анонимную проверку подлинности (Anonymous Authentication).
После сохранения изменений, IIS нужно перезапустить: iisreset /noforce
Если используется шлюз RD Gateway, убедитесь, что он не используется для подключения внутренних клиентов (должна стоять галка Bypass RD Gateway server for local address).
Следующий этап – настройка политики делегирования учетных данных. Создайте новую доменную GPO и привяжите ее к OU с пользователями (компьютерами), которым нужно разрешить SSO доступ на RDS сервера. Если вы хотите разрешить SSO для всех пользователей домена, допустимо редактировать Default Domain Policy.
Далее, чтобы избежать появления окна с предупреждением о надежности издателя удаленного приложения, нужно с помощью GPO на клиентских компьютерах добавить адрес сервера с ролью Connection Broker в доверенную зону с помощью политики «Список назначений зоны безопасности для веб-сайтов» (по аналогии со статьей Как убрать предупреждение системы безопасности при открытии файла в Windows):
Укажите FQDN имя сервера RDCB и зону 2 (Trusted sites).
После обновления политик на клиенте, при попытке запустить RemoteApp приложение, запрос пароля не появится, но появится окно с предупреждением о доверии к издателю данной программы RemoteApp:
Do you trust the publisher of this RemoteApp program?
Чтобы это сообщение не выводилось каждый раз при подключении пользователя, вам нужно получить отпечаток SSL сертификата (certificate thumbprint) RD Connection Broker и добавить его в список доверенных издателей rdp. Для этого на сервере RDS Connection Broker выполните команду PowerShell:
На этом настройка SSO закончена, и после применения политик, пользователь должен подключатся к ферме RDS по протоколу RDP без повторного ввода пароля.
Теперь при запуске клиента mstsc.exe (Remote Desktop Connection), если вы укажете имя RDS сервера, в поле UserName автоматически подставится имя пользователя в формате (user@domain.com).
Your Windows logon credentials will be used to connect.
Для использования Web SSO на RD Web Access, обратите внимание, что рекомендуется использовать Internet Explorer с включенным Active X компонентом MsRdpClientShell (Microsoft Remote Desktop Services Web Access Control).
Небезопасная аутентификация. Ищем баги в приложениях с Single Sign-On на базе SAML
Содержание статьи
Перед тобой практическое руководство по аудиту безопасности веб-приложений с поддержкой SAML SSO. Single Sign-On — это технология, которая позволяет логиниться в веб-приложение через сторонний сайт (провайдер). А SAML — это популярный XML-протокол для реализации SSO. Мы подробно расскажем, что такое SAML SSO, как он работает. Опишем, каким образом настроить свое приложение на работу с SAML IdP. И наконец, расскажем самое важное — какие инструменты нужно использовать для пентестов, на наличие каких уязвимостей нужно проверять приложение. XXE, атаки через преобразования, XPath-инъекции, ошибки при проверке подписи, атаки XSW, атаки на зашифрованные assertions и многое другое. Велком!
Что такое SAML SSO и зачем он нужен?
Single Sign-On (SSO) — это технология, которая позволяет залогиниться в веб-приложении через сторонний сайт-провайдер. К плюсам использования SSO можно отнести следующее:
К минусам можно отнести следующее:
Security Assertion Markup Language (SAML) — это открытый стандарт, который описывает фреймворк, позволяющий обеим сторонам (приложению и провайдеру) обмениваться аутентификационной и авторизационной информацией. Аутентификационная и авторизационная информация представляется в виде набора утверждений (assertions), которые подписаны провайдером (и в некоторых случаях зашифрованы).
На момент написания статьи последняя версия стандарта — SAML 2.0.
По стандарту SAML клиент (веб-приложение) и провайдер аутентификации обмениваются аутентификационными утверждениями (assertions) через XML. А это означает, что SAML основан на следующих стандартах w3c, относящихся к XML:
У SAML есть множество сценариев применения:
Web SSO (или SAML SSO в нашей терминологии) — это наиболее распространенный юзкейс для SAML, поэтому самый интересный с точки зрения безопасности. В нем мы и будем сегодня разбираться.
В аутентификации через SAML SSO участвуют три стороны:
User Agent аутентифицируется на стороне SAML IdP, а затем получает доступ к веб-приложению. Веб-приложение доверяет провайдеру и получает от него аутентификационную информацию. Стороны SAML SSO и их взаимоотношения представлены на рис. 1.
Рис. 1. Стороны SAML SSO и их взаимоотношения
Xakep #205. Взлом Single Sign-On
В качестве IdP провайдера может выступать один из онлайн-сервисов, таких как OneLogin, Ping Identity, Okta и другие. Или ты можешь развернуть свой IdP, используя софт — Shibboleth или OpenAM. Рассмотрим по шагам, каким образом приложение аутентифицируется на стороне провайдера и затем получает доступ к приложению.
Существует два альтернативных flow для SAML SSO: SP-initiated flow и IdP-initiated flow. Различие заключается в том, к кому обращается User Agent в начале процесса — к приложению или к провайдеру. Мы рассмотрим SP-initiated flow, который представлен на рис. 2.
На первом шаге User Agent обращается к приложению. Так как пользователь не был аутентифицирован, приложение перенаправляет браузер на страницу аутентификации провайдера — IdP Login URL. Этот URL приложение берет из конфигурации SAML. В момент редиректа приложение добавляет параметр SAMLRequest в строку запроса (query string).
Браузер делает запрос к IdP Login URL c параметром SAMLRequest. IdP аутентифицирует пользователя и делает редирект браузера обратно в приложение (на Assertion Consumer URL или ACS URL) с параметром SAML Response в строке запроса, который содержит закодированное сообщение Response. В сообщении Response содержатся утверждения (assertions), которые подписаны провайдером (и, возможно, зашифрованы). Провайдер использует значение ACS URL из конфигурации SAML для этого приложения.
Браузер запрашивает ACS URL и передает SAML Response в качестве параметра запроса. Приложение проверяет подпись сообщения Response и подпись каждого assertion (и, возможно, расшифровывает assertion). Для этого приложение использует сертификат провайдера, который хранится в конфигурации SAML.
Далее приложение на основе данных assertion создает сессию для пользователя, делает редирект браузера на страницу /app/profile и устанавливает cookie с идентификатором сессии пользователя.
Рис. 2. SAML SP-initiated flow
Настраиваем SAML SSO в приложении
После того как мы разобрались с теорией, приступим к настройке SAML SSO для тестируемого приложения. У нас есть развернутое приложение, теперь нам нужен SAML IdP (провайдер). Я предпочитаю OneLogin, он популярен, и многие приложения его поддерживают. Еще OneLogin предоставляет полезные утилиты, которые тебе пригодятся при тестировании безопасности. Утилиты находятся здесь.
Регистрируем бесплатный девелоперский аккаунт. Идем в APPS → Company Apps, затем нажимаем кнопку Add Apps. В строке поиска необходимо набрать SAML Test Connector, как показано на рис. 3. Далее выбираем SAML Test Connector (IdP w/attr).
Рис. 3. Создание тестового коннектора
Задаем имя для коннектора и нажимаем кнопку Save.
На стороне нашего приложения идем в настройки SAML IdP (рис. 4). Нам нужно скопировать значения полей Issuer, ACS URL, Logout URL. Эти три параметра нам генерирует приложение, и они используются для настройки коннектора на стороне IdP.
Рис. 4. Настройки SAML IdP приложения
Параметры, которые сгенерировало приложение, необходимо перенести в настройки коннектора, как показано на рис. 5. На этом все, настройка коннектора завершена!
Рис. 5. Настройка коннектора
Переходим на вкладку SSO. Копируем значения X.509 certificate, Issuer URL, SAML Endpoint и SLO Endpoint из настроек коннектора в настройки нашего приложения (рис. 6).
Рис. 6. Параметры SSO
Далее необходимо создать пользователя в IdP. Для этого идем в Users → All Users, как показано на рис. 7. Нажимаем кнопку New User.
Рис. 7. Создание пользователя на стороне IdP
Создаем нового пользователя, указываем email и пароль. Переходим на вкладку Applications и выбираем сконфигурированный нами коннектор (рис. 8).
Рис. 8. Привязка пользователя к коннектору
В нашем приложении создаем пользователя с таким же email, так как связка пользователей между IdP и нашим приложением осуществляется по email. На этом настройка SAML SSO завершена.
Когда мы пытаемся залогиниться в наше приложение, оно редиректит нас к IdP на страницу логина — SAML 2.0 endpoint (см. конфигурацию коннектора в OneLogin). После успешного логина пользователя на стороне IdP происходит редирект в наше приложение на ACS URL. В параметре SAML Response передается закодированное в Base64 сообщение Response (рис. 9).
Рис. 9. Передача SAML Response в приложение
Мы можем декодировать Response. Для этого используем эту утилиту (рис. 10):
Рис. 10. URL decoding
А затем, используя эту утилиту, мы получим XML Response, которым подписан IdP (рис. 11).
Рис. 11. Base64 decoding
Если SAML Response был сжат на стороне IdP, то для декодирования тебе нужно использовать Base64 Decode + Inflate вместо Base64 Decode.
Все, на этом процесс настройки и отладки SAML SSO завершен. Переходим к самому интересному — багам!
Арсенал для тестирования SAML SSO
На данном этапе у тебя есть тестируемое приложение с работоспособным SAML SSO. Разберемся, какие инструменты использовать для тестирования безопасности.
Конечно, в первую очередь утилиты с сайта, которые ранее упоминались:
Если ты занимаешься веб-безопасностью, то, скорее всего, в твоем хакерском арсенале есть Burp Suite. Я представлю два плагина, которые предназначены для тестирования SAML. Ты можешь использовать эти плагины даже с бесплатной версией Burp Suite.
Первый плагин — это SAML Editor, написан на Python. Для того чтобы он заработал, придется установить Jython standalone и указать в настройках Burp Extender путь к Jython. Плагин очень простой, он добавляет дополнительную табу с именем SAML, которая позволяет редактировать SAML-сообщения на лету (рис. 12). Больше он ничего не умеет, его удобно использовать, чтобы быстро отредактировать сообщение.
Рис. 12. Плагин SAML Editor
Второй плагин — это SAML Raider. Плагин написан на Java, можно его собрать, используя Maven, либо скачать готовый jar-файл.
Плагин добавляет новую табу с именем SAML Raider, которая позволяет работать с подписями: удалять подписи, подписывать assertions и/или сообщение SAML, используя импортированный или сгенерированный приватный ключ и сертификат.
Самое замечательное, что умеет плагин SAML Raider, — это тестировать приложение на уязвимости XML Signature Wrapping (XSW). Поддерживаются восемь типов XSW-атак (см. рис. 13).
Рис. 13. SAML Raider tab
Дополнительно плагин добавляет табу SAML Raider Certificates, которая позволяет импортировать приватный ключ и сертификат, который затем можно использовать для подписи assertions и SAML-сообщения. У плагина есть очень полезная возможность — сгенерировать приватный ключ и сертификат, при этом полностью скопировать поля из сертификата IdP в сгенерированный сертификат. Для этого, находясь на табе SAML Raider, необходимо нажать кнопку Send Certificate to SAML Raider Certs, затем перейти на вкладку SAML Raider Certificates и нажать кнопку Clone, выбрав сертификат IdP (рис. 14).
Рис. 14. SAML Raider Certificates tab
Рассмотренных инструментов будет достаточно для того, чтобы протестировать безопасность реализации SAML SSO в интересующем приложении.
Ищем уязвимости в SAML SSO
Самая интересная часть статьи — это какие уязвимости в реализации SAML SSO ты можешь найти на стороне приложения. Поехали.
XXE повсюду
SAML-сообщения представляют собой XML. Это означает, что тестируемое приложение потенциально подвержено уязвимостям, связанным с парсингом XML. Сюда можно отнести уязвимости XML External Entities (XXE), Server-Side Request Forgery (SSRF) и XML Entity Expansion (XEE, в массах более известна как Billion Laughs attack).
Эти уязвимости очень распространены, когда речь идет о парсинге XML. На страницах Хакера про эти уязвимости не раз писали, поэтому я не буду подробно на них останавливаться. Только порекомендую хорошую «методичку» по данным уязвимостям. Эти уязвимости работают, несмотря на то что SAML-сообщение подписано, так как проверка подписи происходит уже после парсинга XML.
Первым делом при тестировании безопасности SAML SSO нужно перехватить сообщение Response и заменить его на следующее:
Хостнейм attacker.com нужно заменить на твой хостнейм, который доступен тестируемому приложению. Если у тебя нет публичного сервера, ты можешь воспользоваться этим отличным сервисом. Он логирует все поступившие HTTP/HTTPS-запросы.
Если на attacker.com пришел GET-запрос, это означает, что приложение уязвимо.
Преобразования и цифровая подпись
Возможны следующие преобразования:
SAML IdP при формировании подписи проводит последовательность трансформаций. Проверяющая подпись сторона — наше приложение должно осуществить ту же самую последовательность преобразований в процессе проверки валидности подписи.
Преобразования enveloped signature, С14N либо С14N11 являются обязательными, преобразования XPath и XSLT — опциональными. То есть проверяющая подпись сторона может не поддерживать опциональные преобразования.
Если код, осуществляющий проверку подписи в нашем приложении, поддерживает XSLT-преобразование, это означает, что наше приложение, скорее всего, уязвимо к различным атакам: исполнению кода (RCE), SSRF, доступу к локальным файлам, DoS, разглашению конфигурационной информации. Серьезность уязвимости зависит от используемой XSLT-библиотеки. Не буду вдаваться в детали атак с использованием XSLT. Ограничусь ссылкой на выступление про практическую эксплуатацию XSLT-преобразований с конференции OWASP Switzerland 2015.
Если на attacker.com пришел GET-запрос, это означает, что приложение поддерживает XSLT.
Надо отметить, что не все XSLT-библиотеки поддерживают обращение к внешним ресурсам по протоколу HTTP/HTTPS. В этом случае можно использовать следующее XSLT-преобразование:
Если приложение долго не отвечает, то оно поддерживает XSLT и уязвимо к DoS-атакам.
Когда приложение не поддерживает XSLT, но поддерживает XPath-преобразование, оно уязвимо к DoS-атакам. Для того чтобы это проверить, можно использовать следующее XPath-преобразование.
Если приложение отвечает дольше обычного, то оно поддерживает XPath.
XPath-инъекции
Если приложение не производит проверку значения URI на наличие XPath-конструкций при составлении выражения, то такая реализация уязвима к XPath-инъекциям.
Свежая XPath-инъекция найдена в конце 2015 года в ruby-saml. Ниже представлена строка из xml_security.rb, которая стала причиной инъекции:
В случае с Ruby эта уязвимость приводит к RCE. Во всем виновата особенность реализации XPath в Ruby, которая выполняет shell команды внутри обратных кавычек. Если приложение использует ruby-saml, то для определения наличия уязвимости необходимо в атрибут URI элемента подставить следующее значение:
Если на хост attacker.com придет GET-запрос, то приложение уязвимо.
Атаки через сжатие сообщений SAML
IdP может сжимать сообщение SAML Response и затем его преобразовывать в Base64. Поэтому тестируемое приложение может ожидать, что сообщение придется распаковывать.
Используя Python, мы можем получить закодированный SAML Response (Deflate + Base64) следующим образом:
Если приложение поддерживает сжатие SAML-сообщения, то, скорее всего, оно подвержено DoS-атакам.
Сценарий атаки следующий. Атакующий декодирует SAML Response. Далее в элемент вставляет много «мусорных символов» и кодирует сообщение — сжимает и преобразует в Base64.
Выбором «мусорных символов» можно добиться хорошей степени сжатия — порядка 1000:1. Таким образом, мы можем сконструировать SAML Response размером 10 Гбайт, который будет сжат в 10 Мбайт. Это, конечно, зависит от настроек веб-сервера, но, как правило, веб-сервер приложения должен пропускать запрос с телом
Распаковка и парсинг XML размером 10 Гбайт — занятие не из легких.
Ошибки при проверке подписи
При валидации подписи SAML Response потенциально существует много мест, где приложение может «фатально» ошибиться, и в результате атакующий сможет залогиниться под другим пользователем в приложение.
Разработчик может заложить fail open логику в проверку подписи. То есть если подписи нет, то приложение ее не проверяет и доверяет assertions, которые содержатся в сообщении Response. Мы можем имперсонироваться любым пользователем.
Другой фейл, когда приложение берет сертификат IdP из элемента в сообщении Response для проверки подписи. Атакующий может сгенерировать свой приватный ключ и сертификат и затем подписать сообщение приватным ключом, и сообщение пройдет валидацию подписи.
При проверке подписи приложение должно брать сертификат из конфигурации SAML и использовать его для валидации подписи, только так.
Другая проблема — каким образом приложение проверяет валидность сертификата IdP после установки. Сертификат IdP может закончиться или стать скомпрометированным.
В сообщении Response присутствуют несколько подписей — это подписи отдельных assertions и подпись самого сообщения. Некоторые реализации проверяют только подпись assertions и не проверяют подпись сообщения. Это приводит к Reply-атакам. Дело в том, что assertion валиден некоторое время (варьируется для каждого IdP), это задается значением атрибута NotOnOrAfter, также сообщение Response имеет уникальный идентификатор. Это нужно для того, чтобы юзер смог воспользоваться ответом IdP только один раз. Допустим, что атакующий провел MITM-атаку или получил доступ к истории браузера жертвы и в результате смог получить SAML Response, с которым пользователь логинился в приложение. Если приложение не проверяет подпись самого сообщения, то атакующий сможет поменять уникальный ID сообщения и использовать SAML Response (конечно, если срок SAML assertion не истек) для того, чтобы залогиниться в приложение от имени пользователя.
Отдельного внимания требуют XML Signature wrapping (XSW) атаки. О них более подробно будет рассказано в следующем разделе.
Уязвимости, связанные с проверкой подписи, удобно тестировать при помощи плагина SAML Raider.
Атаки XSW
XSW — это атака на процедуру проверки подписи, она заключается в том, что приложение проверяет подпись одних данных, а при обработке использует другие. В контексте SAML данная атака позволяет атакующему, имеющему учетную запись в приложении, аутентифицироваться как любой другой пользователь.
Рис. 15. Оригинальный SAML Response
Рис. 16. Модифицированный SAML Response
Атаки на зашифрованные assertions
Для шифрования симметричного ключа шифрования используется алгоритм RSAES-PKCS1-v1_5. Для шифрования данных обычно используется блочный шифр (AES) в режиме CBC.
Если при расшифровывании assertion приложение выступает в качестве Оракула (Oracle), то после расшифровки оно сообщает о том, что padding неверный или расшифрованное сообщение не является валидным XML. Приложение может сообщать это в виде явного сообщения об ошибке либо в виде различного тайминга. Время расшифровывания assertion различается и когда padding корректный, и когда он некорректный. В этом случае атакующий, перехвативший зашифрованный assertion, сможет его расшифровать даже без знания ключа шифрования.
Есть еще одно условие для проведения атаки на XML-шифрование: атакующий должен иметь возможность изменять зашифрованные данные. Подпись сообщения проверяется раньше, чем расшифровываются данных. Поэтому приложение должно быть уязвимо к ошибкам проверки подписи, которые были рассмотрены ранее.
Юрай Соморовски (Juraj Somorovsky) опубликовал работу, посвященную атакам на XML-шифрование. В работе описан алгоритм, который позволит атакующему расшифровать при выполнении двух условий: приложение уязвимо к ошибкам проверки подписи и приложение выступает в качестве Оракула. В среднем для расшифровки одного блока (в случае AES блок составляет 16 байт) шифротекста в среднем потребуется 162 запроса.
Также в 2015 году Юрай Соморовски на конференции Black Hat EU представил утилиту WS-Attacker, которая реализует алгоритм из его работы про атаки на XML-шифрование. Ссылка на презентацию тут. Я же опишу основные идеи алгоритма.
Рис. 17. Операция расшифровывания assertion при помощи блочного шифра в режиме СВС
Рис. 18. Находим модифицированное значение Ci-1
Заключение
Итак, ты получил представление о том, каким уязвимостям подвержены приложения с поддержкой SAML SSO. Ты узнал, каким образом настроить SSO с помощью SAML в приложении, какие инструменты использовать для тестирования безопасности SAML SSO.
Надеюсь, что теперь, если ты столкнешься с SAML SSO, будешь знать, куда копать. Успешного багхантинга!