Рекомендации по безопасности для ACS

Обновлено: 19 июня 2015 г.

Область применения: Azure

Применяется к

• Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS)

• Windows Identity Foundation

Сводка

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

Задачи

• Устранение проблем безопасности, связанных с кодом и конфигурацией приложения в контексте ACS.

• Устранение проблем безопасности, связанных с конфигурациями ACS.

• Устранение проблем безопасности, связанных с развертываниями Azure в контексте ACS.

Проблемы безопасности в приложениях

Далее приведены рекомендации по защите кода и конфигурации приложений.

• Рекомендуется включить функцию выявления воспроизведения (DetectReplayedTokens).

• Включите атрибут requireHttps у wsFederation.

• Включите атрибут requireSsl у cookieHandler.

• Задайте агрессивное значение атрибута времени существования sessionTokenRequirement.

• Перечислите доверенные STS (издатели маркеров) в issuerNameRegistry.

• Ограничьте набор принимаемых приложением маркеров с помощью audienceUri.

Рекомендуется включить функцию выявления воспроизведения (DetectReplayedTokens).

В WIF имеется кэш выявления воспроизведения, предназначенный для несущих маркеров службы маркеров безопасности (STS), — это просто кэш ранее использованных маркеров STS. Когда клиент впервые проходит проверку подлинности для проверяющей стороны с помощью маркера STS, он получает маркер безопасности сеанса, используемый для проверки подлинности у проверяющей стороны при дополнительных запросах. При этом используется SSL, чтобы маркер безопасности сеанса нельзя было украсть. Если клиент или злоумышленник пытается пройти проверку у третьей стороны, применяя уже использованный клиентом маркер STS, то проверяющая сторона может найти маркер STS в кэше воспроизведения и отклонить запрос.

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

Пример.

<securityTokenHandlers>
  <securityTokenHandlerConfiguration>
    <tokenReplayDetection enabled="true" capacity="1000" expirationPeriod="500"/>
  </securityTokenHandlerConfiguration>
</securityTokenHandlers>

<system.identityModel>
  <identityConfiguration>
    <tokenReplayDetection>
      <replayCache type='FQTN of your type' />
    </tokenReplayDetection>
  </identityConfiguration>
</system.identityModel>

Включите атрибут requireHttps у wsFederation

Атрибут requireHttps указывает, использует ли модуль для перенаправления только безопасные URL-адреса в STS. По умолчанию он включен. Это гарантирует безопасность связи с STS через HTTPS/SSL, устраняя возможность отслеживания учетных данных и маркеров.

Пример.

<federatedAuthentication>
  <wsFederation
        passiveRedirectEnabled="true"
        issuer="http://STS URL GOES HERE/"
        realm="http://RP REALM GOES HERE/"
        requireHttps="ture" />
  <cookieHandler requireSsl="true" />
</federatedAuthentication>

Включите атрибут requireSsl у cookieHandler

Это логическое значение, по умолчанию равное false. Атрибут requireSsl указывает, создается ли флаг Secure для записываемых файлов cookie. Если это значение включено, файлы cookie входа в сеанс будут доступны только по HTTPS. Это предотвращает отправку файлов cookie сеанса через незашифрованный канал, что предотвращает отслеживание маркеров.

Пример.

<federatedAuthentication>
  <wsFederation
        passiveRedirectEnabled="true"
        issuer="http://STS URL GOES HERE/"
        realm="http://RP REALM GOES HERE/"
        requireHttps="ture" />
  <cookieHandler requireSsl="true" />
</federatedAuthentication>

Задайте агрессивное значение атрибута времени существования sessionTokenRequirement

Рекомендуется настроить выпуск маркеров с агрессивными ограничениями времени существования. Это позволит ограничить время, имеющееся у злоумышленника на воспроизведение украденного маркера.

Пример.

<add type="Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler, Microsoft.IdentityModel">
  <sessionTokenRequirement securityTokenCacheType="Microsoft.IdentityModel.MruSecurityTokenCache, Microsoft.IdentityModel"
                           saveBootstrapTokens="true"
                           securityTokenCacheSize="500"
                           useWindowsTokenService="false"
                           lifetime="10:00" />
</add>

Перечислите доверенные STS (издатели маркеров) в issuerNameRegistry

Все маркеры издателей проверяются с помощью IssuerNameRegistry. Назначение IssuerNameRegistry состоит в сопоставлении маркера издателя со строковым именем. При ошибке проверки маркер не принимается. Это устраняет опасность принятия ненадежных маркеров. Любой настраиваемый тип можно зарегистрировать с помощью атрибута <типа элемента issuerNameRegistry>. IssuerNameRegistry <> может иметь один дочерний элемент, который будет служить пользовательской конфигурацией для IssuerNameRegistry. Один тип IssuerNameRegistry предоставляется в готовом виде — ConfigurationBasedIssuerNameRegistry. Его можно использовать для настройки доверенных сертификатов издателей в конфигурации. Для этого типа требуется дочерний элемент <конфигурацииtrustedIssuers> , для которого настроены доверенные сертификаты издателя. <Конфигурация trustedIssuers> добавляет доверенные сертификаты с помощью закодированной формы отпечатка сертификата в кодировке ASN.1.

Пример.

<issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel">
  <trustedIssuers>
    <add thumbprint="97249e1a5fa6bee5e515b82111ef524a4c9158de" name="contoso.com" />
    <remove thumbprint="97249e1a5fa6bee5e515b82111ef524a4c9158de" />
    <clear/>
  </trustedIssuers>
</issuerNameRegistry>

Ограничьте набор принимаемых приложением маркеров с помощью audienceUri

<AudienceUris> указывает набор URI, допустимый для идентификации этой проверяющей стороны. Маркеры не будут приниматься, если они не относятся к одному из разрешенных URI аудитории. Это устраняет риск воспроизведения действительных маркеров, выданных для других проверяющих сторон. По умолчанию в наборе нет URI. SecurityTokenHandler для форматов SAML 1.1 и SAML 2.0 использует значения из этой коллекции для настройки разрешенных URI аудитории в объектах SamlSecurityTokenRequirement.

Пример.

<audienceUris>
  <clear/>
  <add value="http://www.example.com/myapp/" />
  <remove value="http://www.example.com/myapp/" />
</audienceUris>

Проблемы безопасности в ACS

Ниже приведены рекомендации по безопасности, связанные с конфигурацией портала управления ACS.

• Задавайте агрессивный срок действия для маркеров STS.

• Обеспечьте адекватную проверку данных при использовании URL-адреса ошибки.

• Шифруйте маркеры в конфиденциальных сценариях.

Задавайте агрессивный срок действия для маркеров STS.

Атрибут времени существования маркера определяет срок его действия. Он указывается при создании или настройке проверяющей стороны с помощью портала ACS или службы управления. Вы можете использовать свойство "Время существования токена", чтобы указать время для маркера безопасности, выданного ACS приложению проверяющей стороны, чтобы оставаться действительным. По умолчанию в ACS это значение равно 10 минутам (600 секунд). В ACS это значение должно быть больше нуля, но меньше или равно 24 часам (86400 секунд).

Обеспечьте адекватную проверку данных при использовании URL-адреса ошибки.

Url-адрес ошибки можно использовать для указания URL-адреса, на который ACS перенаправляет пользователей, если во время входа произошла ошибка. Это может быть пользовательская страница, размещенная в приложении проверяющей стороны, например http://www.fabrikam.com/billing/error.aspx. В рамках перенаправления ACS предоставляет сведения об ошибке приложению проверяющей стороны в качестве параметра URL-адреса HTTP в кодировке JSON. Страница ошибки может принимать эти данные, чтобы отображать фактическое сообщение об ошибке наряду со статическим справочным текстом. Если страница требует авторизации, результатом будет бесконечный цикл перенаправления в случае, когда ACS попытается получить к нему доступ и отправить ошибку в кодировке JSON. Поэтому следует включить анонимный доступ. Поскольку страница ошибки доступна анонимно и может включать код, отображающий HTML или заносящий данные в базу данных, следует предотвратить возможность атаки с использованием межсайтовых сценариев и внедрения SQL-команд.

Шифруйте маркеры в конфиденциальных сценариях.

В конфиденциальных сценариях с пассивной федерацией следует шифровать маркеры. Дополнительные сведения о шифровании и расшифровке маркеров см. в разделе "Сертификаты и ключи ".

Проблемы безопасности в развертывании Azure

Ниже приведены рекомендации по безопасности, связанные с приложениями, использующими ACS и развернутыми в Azure.

• Шифрование файлов cookie с помощью RSA

Шифрование файлов cookie с помощью RSA

Используемый в Windows Azure по умолчанию механизм шифрования файлов cookie (основанный на DPAPI) не подходит, так как у каждого экземпляра свой ключ. Это значит, что файл cookie, созданный одним экземпляром веб-роли, не будет читаться другим. Это может вызывать сбои службы и отказ в ее работе. Далее приведено сообщение об ошибке при использовании механизма шифрования cookie по умолчанию:

[CryptographicException: Key not valid for use in specified state.
]
System.Security.Cryptography.ProtectedData.Unprotect(Byte[] encryptedData, Byte[] optionalEntropy, DataProtectionScope scope) +577
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[] encoded) +80
[InvalidOperationException: ID1073: A CryptographicException occurred when attempting to decrypt the cookie using the ProtectedData API (see inner exception for details). If you are using IIS 7.5, this could be due to the loadUserProfile setting on the Application Pool being set to false. ]
Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Decode(Byte[] encoded) +433
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +189
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver) +862
Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver) +109
Microsoft.IdentityModel.Web.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte[] sessionCookie) +356
Microsoft.IdentityModel.Web.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken& sessionToken) +123
Microsoft.IdentityModel.Web.SessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs) +61
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +270

Чтобы устранить проблему, используйте механизм шифрования файлов cookie, в котором применяется общий для всех экземпляров веб-роли ключ. В следующем коде показано, как заменить объект SessionSecurityHandler по умолчанию на класс RsaEncryptionCookieTransform.

private void OnServiceConfigurationCreated(object sender, 
    ServiceConfigurationCreatedEventArgs e)
{
    List<CookieTransform> sessionTransforms =
        new List<CookieTransform>(
            new CookieTransform[] 
            {
                new DeflateCookieTransform(), 
                new RsaEncryptionCookieTransform(
                    e.ServiceConfiguration.ServiceCertificate),
                new RsaSignatureCookieTransform(
                    e.ServiceConfiguration.ServiceCertificate)  
            });
   SessionSecurityTokenHandler sessionHandler = 
    new
     SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

    e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(
        sessionHandler);
}

void Application_Start(object sender, EventArgs e)
{
    FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
}

Дополнительные ресурсы

• Практическое руководство. Предотвращение междоменных сценариев в ASP.NET (https://go.microsoft.com/fwlink/?LinkID=178708).

• Практическое руководство. Защита от атак путем внедрения в ASP.NET (https://go.microsoft.com/fwlink/?LinkID=157572).

• Практическое руководство. Защита от внедрения SQL в ASP.NEThttps://go.microsoft.com/fwlink/?LinkID=212978.

Связанные элементы:

• Практическое руководство. Использование URL-адреса ошибки для пользовательской обработки ошибок

• Сертификаты и ключи

• Приложения проверяющей стороны