Najlepsze rozwiązania dotyczące zabezpieczeń programu WCF
W poniższych sekcjach wymieniono najlepsze rozwiązania, które należy wziąć pod uwagę podczas tworzenia bezpiecznych aplikacji przy użyciu programu Windows Communication Foundation (WCF). Aby uzyskać więcej informacji na temat zabezpieczeń, zobacz Zagadnienia dotyczące zabezpieczeń, Zagadnienia dotyczące zabezpieczeń dotyczące danych i Zagadnienia dotyczące zabezpieczeń z metadanymi.
Identyfikowanie usług wykonujących uwierzytelnianie systemu Windows za pomocą nazw SPN
Usługi można zidentyfikować przy użyciu głównych nazw użytkowników (UPN) lub nazw głównych usług (SPN). Usługi działające na kontach maszyn, takich jak usługa sieciowa, mają tożsamość SPN odpowiadającą uruchomionej maszynie. Usługi uruchomione na kontach użytkowników mają tożsamość nazwy UPN odpowiadającą użytkownikowi, w którym są uruchomione, chociaż setspn narzędzie może służyć do przypisywania nazwy SPN do konta użytkownika. Skonfigurowanie usługi w celu zidentyfikowania jej za pośrednictwem nazwy SPN i skonfigurowanie klientów łączących się z usługą w celu korzystania z tej nazwy SPN może utrudnić pewne ataki. Te wskazówki dotyczą powiązań przy użyciu negocjacji protokołu Kerberos lub SSPI. Klienci powinni nadal określać nazwę SPN w przypadku, gdy interfejs SSPI powraca do NTLM.
Weryfikowanie tożsamości usługi w języku WSDL
WS-SecurityPolicy umożliwia usługom publikowanie informacji o ich własnych tożsamościach w metadanych. Po pobraniu za pośrednictwem svcutil lub innych metod, takich jak WsdlImporter, te informacje o tożsamości są tłumaczone na właściwości tożsamości adresów punktów końcowych usługi WCF. Klienci, którzy nie sprawdzają, czy te tożsamości usług są poprawne i prawidłowe skutecznie pomijają uwierzytelnianie usługi. Złośliwa usługa może wykorzystywać takich klientów do wykonywania przekazywania poświadczeń i innych ataków typu "man in the middle" przez zmianę tożsamości zgłoszonej w języku WSDL.
Używanie certyfikatów X509 zamiast NTLM
Program WCF oferuje dwa mechanizmy uwierzytelniania równorzędnego: certyfikaty X509 (używane przez kanał równorzędny) i uwierzytelnianie systemu Windows, w których negocjacje SSPI obniżają uwierzytelnianie z protokołu Kerberos do NTLM. Uwierzytelnianie oparte na certyfikatach przy użyciu rozmiarów kluczy 1024 bitów lub więcej jest preferowane do NTLM z kilku powodów:
dostępność wzajemnego uwierzytelniania,
stosowanie silniejszych algorytmów kryptograficznych i
większe trudności z użyciem przekazanych poświadczeń X509.
Zawsze przywracaj po personifikacji
W przypadku korzystania z interfejsów API, które umożliwiają personifikację klienta, pamiętaj, aby przywrócić oryginalną tożsamość. Na przykład w przypadku używania instrukcji WindowsIdentity i WindowsImpersonationContextużyj instrukcji języka C# using lub instrukcji Języka Visual Basic Using , jak pokazano w poniższym kodzie. Klasa WindowsImpersonationContext implementuje IDisposable interfejs, a zatem środowisko uruchomieniowe języka wspólnego (CLR) automatycznie przywraca oryginalną tożsamość po opuszczeniu using bloku przez kod.
WindowsIdentity identity = ServiceSecurityContext.Current.WindowsIdentity;
using (identity.Impersonate())
{
// Run code under the caller's identity.
}
Dim identity = ServiceSecurityContext.Current.WindowsIdentity
Using identity.Impersonate()
' Run code under the caller's identity.
End Using
Personifikuj tylko zgodnie z potrzebami
Impersonate Przy użyciu metody WindowsIdentity klasy można użyć personifikacji w bardzo kontrolowanym zakresie. Jest to w przeciwieństwie do używania Impersonation właściwości OperationBehaviorAttribute, która umożliwia personifikację zakresu całej operacji. Jeśli to możliwe, należy kontrolować zakres personifikacji przy użyciu bardziej precyzyjnej Impersonate metody.
Uzyskiwanie metadanych z zaufanych źródeł
Upewnij się, że źródło metadanych jest zaufane i upewnij się, że nikt nie manipulował metadanymi. Metadane pobierane przy użyciu protokołu HTTP są wysyłane w postaci zwykłego tekstu i mogą zostać naruszone. Jeśli usługa używa HttpsGetEnabled właściwości i HttpsGetUrl , użyj adresu URL dostarczonego przez twórcę usługi, aby pobrać dane przy użyciu protokołu HTTPS.
Publikowanie metadanych przy użyciu zabezpieczeń
Aby zapobiec manipulowaniu opublikowanymi metadanymi usługi, należy zabezpieczyć punkt końcowy wymiany metadanych przy użyciu zabezpieczeń na poziomie transportu lub komunikatów. Aby uzyskać więcej informacji, zobacz Publikowanie punktów końcowych metadanych i Instrukcje: publikowanie metadanych dla usługi przy użyciu kodu.
Upewnij się, że używasz wystawcy lokalnego
Jeśli dla danego powiązania określono adres wystawcy i powiązanie, lokalny wystawca nie jest używany dla punktów końcowych korzystających z tego powiązania. Klienci, którzy oczekują, że zawsze korzystają z wystawcy lokalnego, powinni upewnić się, że nie używają takiego powiązania lub że modyfikują powiązanie, tak aby adres wystawcy był zerowy.
Limity przydziału rozmiaru tokenu SAML
Gdy tokeny języka SAML (Security Assertions Markup Language) są serializowane w komunikatach, gdy są wystawiane przez usługę tokenu zabezpieczającego (STS) lub gdy klienci przedstawiają je usługom w ramach uwierzytelniania, maksymalny limit przydziału rozmiaru komunikatu musi być wystarczająco duży, aby uwzględnić token SAML i inne części komunikatów. W normalnych przypadkach domyślne limity przydziału rozmiaru komunikatu są wystarczające. Jednak w przypadkach, gdy token SAML jest duży, ponieważ zawiera setki oświadczeń, przydziały powinny zostać zwiększone w celu uwzględnienia serializowanego tokenu. Aby uzyskać więcej informacji na temat limitów przydziału, zobacz Zagadnienia dotyczące zabezpieczeń danych.
Ustaw wartość SecurityBindingElement.IncludeTimestamp na wartość True w powiązaniach niestandardowych
Podczas tworzenia powiązania niestandardowego należy ustawić wartość IncludeTimestamptrue. W przeciwnym razie, jeśli IncludeTimestamp ustawiono wartość false, a klient używa asymetrycznego tokenu opartego na kluczach, takiego jak certyfikat X509, komunikat nie zostanie podpisany.