Delen via

Aanbevolen procedures voor beveiliging in WCF

In de volgende secties vindt u de aanbevolen procedures om rekening mee te houden bij het maken van beveiligde toepassingen met behulp van WCF (Windows Communication Foundation). Zie Beveiligingsoverwegingen, beveiligingsoverwegingen voor gegevens en beveiligingsoverwegingen met metagegevens voor meer informatie over beveiliging.

Services identificeren die Windows-verificatie uitvoeren met SPN's

Services kunnen worden geïdentificeerd met UPNs (User Principal Names) of SPNs (Service Principal Names). Services die worden uitgevoerd onder computeraccounts, zoals de netwerkservice, hebben een SPN-identiteit die overeenkomt met de computer waarop ze worden uitgevoerd. Services die worden uitgevoerd onder gebruikersaccounts hebben een UPN-identiteit die overeenkomt met de gebruiker die ze uitvoeren, hoewel het setspn hulpprogramma kan worden gebruikt om een SPN toe te wijzen aan het gebruikersaccount. Het configureren van een service zodat deze kan worden geïdentificeerd via SPN en het configureren van de clients die verbinding maken met de service om die SPN te gebruiken, kan bepaalde aanvallen moeilijker maken. Deze richtlijnen zijn van toepassing op bindingen met behulp van Kerberos- of SSPI-onderhandeling. Clients moeten nog steeds een SPN opgeven in het geval dat SSPI terugvalt op NTLM.

Service-identiteiten verifiëren in WSDL

WS-SecurityPolicy stelt diensten in staat om informatie over hun eigen identiteiten in metagegevens te publiceren. Wanneer deze identiteitsgegevens worden opgehaald via svcutil of andere methoden zoals WsdlImporter, worden deze identiteitsgegevens omgezet in de identiteitseigenschappen van de adressen van het WCF-service-eindpunt. Clients die niet controleren of deze service-identiteiten juist en geldig zijn, omzeilen serviceverificatie. Een schadelijke dienst kan dergelijke clients misbruiken om referenties door te sturen en andere 'man-in-the-middle'-aanvallen uit te voeren door de geclaimde identiteit in zijn WSDL te wijzigen.

X509-certificaten gebruiken in plaats van NTLM

WCF biedt twee mechanismen voor peer-to-peer-verificatie: X509-certificaten (gebruikt door peerkanaal) en Windows-verificatie waarbij een SSPI-onderhandeling downgradet van Kerberos naar NTLM. Verificatie op basis van certificaten met sleutelgrootten van 1024 bits of meer heeft om verschillende redenen de voorkeur aan NTLM:

  • de beschikbaarheid van wederzijdse verificatie;

  • het gebruik van sterkere cryptografische algoritmen en

  • de grotere moeilijkheid van het gebruik van doorgestuurde X509-referenties.

Altijd terugkeren na imitatie

Wanneer u API's gebruikt die imitatie van een client mogelijk maken, moet u de oorspronkelijke identiteit herstellen. Als u bijvoorbeeld de WindowsIdentity- en WindowsImpersonationContext-elementen gebruikt, gebruik dan de C#-instructie using of de Visual Basic-instructie Using, zoals in de volgende code wordt weergegeven. De WindowsImpersonationContext klasse implementeert de IDisposable interface en daarom keert de Common Language Runtime (CLR) automatisch terug naar de oorspronkelijke identiteit zodra de code het using blok verlaat.

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

Alleen imiteren als dat nodig is

Met behulp van de Impersonate methode van de WindowsIdentity klasse is het mogelijk om imitatie te gebruiken in een zeer gecontroleerd bereik. Dit staat in contrast met het gebruik van de Impersonation eigenschap van de OperationBehaviorAttribute, die identiteitsvervalsing toestaat voor de gehele bewerking. Beheer waar mogelijk het bereik van imitatie met behulp van de preciezere Impersonate methode.

Metagegevens ophalen van vertrouwde bronnen

Zorg ervoor dat u de bron van uw metagegevens vertrouwt en zorg ervoor dat niemand met de metagegevens heeft geknoeid. Metagegevens die worden opgehaald met behulp van het HTTP-protocol, worden in duidelijke tekst verzonden en kunnen worden gemanipuleerd. Als de service gebruikmaakt van de HttpsGetEnabled en HttpsGetUrl eigenschappen, gebruikt u de URL van de maker van de service om de gegevens te downloaden met behulp van het HTTPS-protocol.

Metagegevens publiceren met behulp van beveiliging

Om manipulatie met gepubliceerde metagegevens van een service te voorkomen, beveiligt u het eindpunt voor het uitwisselen van metagegevens met transport- of berichtniveaubeveiliging. Zie Metagegevenseindpunten publiceren en metagegevens publiceren voor een service met behulp van code voor meer informatie.

Gebruik van lokale verlener garanderen

Als een verleneradres en binding zijn opgegeven voor een bepaalde binding, wordt de lokale verlener niet gebruikt voor eindpunten die die binding gebruiken. Clients die verwachten altijd de lokale verlener te gebruiken, moeten ervoor zorgen dat ze geen dergelijke binding gebruiken of dat ze de binding zodanig wijzigen dat het adres van de uitgever null is.

Quota voor SAML-tokengrootte

Wanneer SAML-tokens (Security Assertions Markup Language) worden geserialiseerd in berichten, ofwel wanneer ze worden uitgegeven door een Security Token Service (STS) of wanneer clients deze aan services presenteren als onderdeel van verificatie, moet het maximale quotum voor berichtgrootte voldoende groot zijn om het SAML-token en de andere berichtonderdelen te kunnen verwerken. In normale gevallen zijn de standaard quota voor berichtgrootte voldoende. Echter, in gevallen waarin een SAML-token groot is omdat het honderden claims omvat, moeten de quota worden verhoogd om het geserialiseerde token te accommoderen. Zie Beveiligingsoverwegingen voor gegevens voor meer informatie over quota.

Stel SecurityBindingElement.IncludeTimestamp in op True voor aangepaste bindingen

Wanneer u een aangepaste binding maakt, moet u deze instellen op IncludeTimestamptrue. Anders, als IncludeTimestamp is ingesteld op false, en de client een asymmetrisch sleuteltoken zoals een X509-certificaat gebruikt, wordt het bericht niet ondertekend.

Zie ook