Sdílet prostřednictvím


Doporučené postupy pro zabezpečení ve WCF

Následující části obsahují seznam osvědčených postupů, které je potřeba vzít v úvahu při vytváření zabezpečených aplikací pomocí wcf (Windows Communication Foundation). Další informace o zabezpečení najdete v tématu Důležité informace o zabezpečení, aspekty zabezpečení pro data a aspekty zabezpečení s metadaty.

Identifikace služeb provádějících ověřování systému Windows pomocí hlavních názvů služeb (SPN)

Služby je možné identifikovat buď hlavními názvy uživatelů (UPN), nebo hlavními názvy služeb (SPN). Služby spuštěné v účtech počítačů, jako je síťová služba, mají identitu SPN odpovídající počítači, na kterém běží. Služby spuštěné v uživatelských účtech mají identitu hlavního názvu uživatele (UPN) odpovídající uživateli, který používá, i když setspn nástroj lze použít k přiřazení hlavního názvu služby k uživatelskému účtu. Konfigurace služby, aby ji bylo možné identifikovat prostřednictvím hlavního názvu služby (SPN) a nakonfigurovat klienty připojující se ke službě, aby používaly tento hlavní název služby (SPN), můžou být určité útoky obtížnější. Tyto pokyny platí pro vazby využívající protokol Kerberos nebo vyjednávání SSPI. Klienti by stále měli zadat hlavní název služby (SPN) v případě, že se SSPI vrátí zpět do protokolu NTLM.

Ověření identit služeb ve WSDL

WS-SecurityPolicy umožňuje službám publikovat informace o vlastních identitách v metadatech. Při načítání prostřednictvím svcutil nebo jiných metod, jako WsdlImporterje například , se tyto informace o identitě překládají na vlastnosti identity adres koncového bodu služby WCF. Klienti, kteří neověřují, že jsou tyto identity služeb správné a platné, efektivně obejít ověřování služby. Škodlivá služba může takové klienty zneužít ke spouštění útoků na předávání přihlašovacích údajů a k dalším útokům "man in the middle" změnou identity deklarované v jejím WSDL.

Použití certifikátů X509 místo NTLM

WCF nabízí dva mechanismy pro ověřování mezi dvěma účastníky: certifikáty X509 (používané partnerským kanálem) a ověřování systému Windows, kde se vyjednávání SSPI z Kerberos na NTLM snižuje. Ověřování založené na certifikátech s použitím velikosti klíčů 1024 bitů nebo více je upřednostňované pro NTLM z několika důvodů:

  • dostupnost vzájemného ověřování,

  • použití silnějších kryptografických algoritmů a

  • větší potíže s využitím předávaných přihlašovacích údajů X509.

Vždy vrátit zpět po zosobnění

Pokud používáte rozhraní API, která umožňují zosobnění klienta, nezapomeňte se vrátit k původní identitě. Například při použití WindowsIdentity příkazu a WindowsImpersonationContextpoužijte příkaz jazyka C# using nebo příkaz Jazyka Visual Basic Using , jak je znázorněno v následujícím kódu. Třída WindowsImpersonationContext implementuje IDisposable rozhraní, a proto modul CLR (Common Language Runtime) se po opuštění using bloku automaticky vrátí k původní identitě.

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

Zosobnit pouze podle potřeby

Impersonate Pomocí metody WindowsIdentity třídy je možné použít zosobnění v velmi řízeném oboru. To je na rozdíl od použití Impersonation vlastnosti OperationBehaviorAttribute, která umožňuje zosobnění pro rozsah celé operace. Kdykoli je to možné, použijte přesnější Impersonate metodu řízení rozsahu zosobnění.

Získání metadat z důvěryhodných zdrojů

Ujistěte se, že důvěřujete zdroji metadat a ujistěte se, že s metadaty nikdo manipuloval. Metadata načtená pomocí protokolu HTTP se odesílají v prostém textu a dají se s ním manipulovat. Pokud služba používá a HttpsGetEnabledHttpsGetUrl vlastnosti, použijte adresu URL zadanou tvůrcem služby ke stažení dat pomocí protokolu HTTPS.

Publikování metadat pomocí zabezpečení

Pokud chcete zabránit manipulaci s publikovanými metadaty služby, zabezpečte koncový bod výměny metadat s přenosem nebo zabezpečením na úrovni zpráv. Další informace najdete v tématu Publikování koncových bodů metadat a postupy: Publikování metadat pro službu pomocí kódu.

Zajištění použití místního vystavitele

Pokud je pro danou vazbu zadána adresa vystavitele a vazba, místní vystavitel se nepoužívá pro koncové body, které tuto vazbu používají. Klienti, kteří očekávají, že budou vždy používat místního vystavitele, by měli zajistit, aby takové vazby nepoužívali nebo aby upravili vazbu tak, aby adresa vystavitele měla hodnotu null.

Kvóty velikosti tokenu SAML

Pokud jsou tokeny SAML (Security Assertions Markup Language) serializovány ve zprávách, a to buď v případě, že jsou vydány službou tokenů zabezpečení (STS) nebo když je klienti prezentují službám jako součást ověřování, musí být kvóta maximální velikosti zpráv dostatečně velká, aby vyhovovala tokenu SAML a dalším částem zpráv. V normálních případech jsou výchozí kvóty velikosti zpráv dostatečné. V případech, kdy je token SAML velký, protože obsahuje stovky deklarací identity, by se kvóty měly zvýšit tak, aby vyhovovaly serializovanému tokenu. Další informace o kvótách najdete v tématu Důležité informace o zabezpečení dat.

Nastavení SecurityBindingElement.IncludeTimestamp na hodnotu True u vlastních vazeb

Při vytváření vlastní vazby musíte nastavit IncludeTimestamp na truehodnotu . V opačném případě platí, že pokud IncludeTimestamp je nastavená hodnota falsea klient používá asymetrický token založený na klíči, například certifikát X509, zpráva se nepodepíše.

Viz také