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

  • Статья

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

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

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

Информация о политике

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

Дампы памяти, раскрывающие информацию об утверждениях

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

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

В адресе конечной точки содержится информация, необходимая для связи с конечной точкой. Безопасность 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 при задании учетных данных клиента или недействительной идентификации

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

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

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

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

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

См. также