Поделиться через

Раскрытие информации

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

Безопасность сообщений и HTTP

Если вы используете безопасность на уровне сообщений на уровне транспорта HTTP, помните, что безопасность на уровне сообщений не защищает заголовки HTTP. Единственным способом защиты заголовков HTTP является использование транспорта HTTPS вместо HTTP. Транспорт HTTPS приводит к тому, что все сообщение, включая заголовки HTTP, будет зашифровано с помощью протокола SSL.

Сведения о политике

Поддержание безопасности политики важно, особенно в случае сценариев федерации, когда в политике предоставляются конфиденциальные требования к выданным токенам или информация об издателе токенов. В таких случаях рекомендуется защитить конечную точку политики федеративной службы, чтобы запретить злоумышленникам получать сведения о службе, например тип утверждений, которые следует поместить в выданный маркер, или перенаправлять клиентов на вредоносных издателей токенов. Например, злоумышленник может обнаружить пары имени пользователя и пароля, перенастроив федеративную цепочку доверия, чтобы завершить работу в издателе, который выполнил атаку "человек в середине". Также рекомендуется, чтобы федеративные клиенты, получающие свои привязки с помощью извлечения политики, проверяли, что они доверяют издателям в полученной федеративной цепочке доверия. Дополнительные сведения о сценариях федерации см. в разделе "Федерация".

Дампы памяти могут раскрыть сведения о заявлении

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

Адреса конечных точек

Адрес конечной точки содержит сведения, необходимые для взаимодействия с конечной точкой. Безопасность SOAP должна полностью включать адрес в сообщения безопасности, обмениваемые для согласования симметричного ключа между клиентом и сервером. Поскольку переговоры по безопасности представляют собой процесс начальной загрузки, заголовки адресов нельзя зашифровать на этом этапе. Поэтому адрес не должен содержать конфиденциальные данные; в противном случае это приводит к атакам раскрытия информации.

Сертификаты, передаваемые без шифрования

При использовании сертификата X.509 для проверки подлинности клиента сертификат передается в виде ясного заголовка SOAP. Помните о возможности раскрытия персонально идентифицируемой информации (PII). Это не является проблемой в режиме TransportWithMessageCredential, где всё сообщение шифруется с помощью безопасности транспортного уровня.

Ссылки на службы

Ссылка на службу — это ссылка на другую службу. Например, служба может передать ссылку на службу клиенту в ходе операции. Ссылка на службу также используется с проверяющим удостоверением доверия, внутренним компонентом, обеспечивающим удостоверение целевого субъекта перед раскрытием таких данных, как данные приложения или учетные данные для целевого объекта. Если удостоверение удаленной доверенной стороны не может быть проверено или неправильно, отправитель должен убедиться, что никакие данные не были раскрыты, что могло бы привести к компрометации отправителя, приложения или пользователя.

К устранению рисков относятся следующие:

  • Предполагается, что ссылки на службы являются надежными. При передаче экземпляров ссылок на службу необходимо убедиться, что они не были изменены.

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

NTLM

По умолчанию в среде домена Windows проверка подлинности Windows использует протокол Kerberos для проверки подлинности и авторизации пользователей. Если протокол Kerberos не может использоваться по какой-то причине, функция NT LAN Manager (NTLM) используется в качестве резервной версии. Вы можете отключить это поведение, установив для свойства AllowNtlm значение false. Проблемы, которые следует учитывать при разрешении NTLM, включают:

  • NTLM предоставляет имя пользователя клиента. Если имя пользователя должно храниться в конфиденциальности, задайте для свойства привязки значение AllowNTLM на false.

  • NTLM не предоставляет проверку подлинности сервера. Поэтому клиент не может убедиться, что он взаимодействует с правильной службой при использовании NTLM в качестве протокола проверки подлинности.

Указание учетных данных клиента или недействительного удостоверения вынуждает использование NTLM.

При создании клиента указание учетных данных клиента без доменного имени или указание недопустимого удостоверения сервера приводит к тому, что NTLM будет использоваться вместо протокола Kerberos (если AllowNtlm для свойства задано значение true). Так как NTLM не выполняет проверку подлинности сервера, информация может быть раскрыта.

Например, можно указать учетные данные клиента Windows без доменного имени, как показано в следующем коде Visual C#.

MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");

Код не указывает доменное имя, поэтому будет использоваться NTLM.

Если домен указан, но недопустимое имя принципала службы указывается с помощью функции идентификации точки доступа, используется NTLM. Дополнительные сведения о том, как указано удостоверение конечной точки, см. в разделе Удостоверение и аутентификация службы.

См. также