Verhoging van bevoegdheden
Uitbreiding van bevoegdheden leidt tot het verlenen van machtigingsmachtigingen van een aanvaller buiten de machtigingen die in eerste instantie zijn verleend. Een aanvaller met een machtigingsset 'alleen-lezen'-machtigingen verhoogt de set bijvoorbeeld om 'lezen en schrijven' op te nemen.
Vertrouwde STS moet SAML-tokenclaims ondertekenen
Een SAML-token (Security Assertions Markup Language) is een algemeen XML-token dat het standaardtype is voor uitgegeven tokens. Een SAML-token kan worden samengesteld door een SECURITY Token Service (STS) die de eindwebservice vertrouwt in een typische uitwisseling. SAML-tokens bevatten claims in instructies. Een aanvaller kan de claims kopiëren van een geldig token, een nieuw SAML-token maken en deze ondertekenen met een andere verlener. De bedoeling is om te bepalen of de server verleners valideert en, zo niet, de zwakheid gebruikt om SAML-tokens te maken die bevoegdheden toestaan buiten de bevoegdheden die zijn bedoeld door een vertrouwde STS.
De SamlAssertion klasse verifieert de digitale handtekening in een SAML-token en de standaardinstelling SamlSecurityTokenAuthenticator vereist dat SAML-tokens worden ondertekend door een X.509-certificaat dat geldig is wanneer de CertificateValidationModeIssuedTokenServiceCredential klasse is ingesteld op ChainTrust. ChainTrust alleen de modus is onvoldoende om te bepalen of de uitgever van het SAML-token wordt vertrouwd. Services waarvoor een gedetailleerder vertrouwensmodel is vereist, kunnen autorisatie- en afdwingingsbeleid gebruiken om de uitgever van de claimsets te controleren die worden geproduceerd door uitgegeven tokenverificatie of de X.509-validatie-instellingen IssuedTokenServiceCredential gebruiken om de set toegestane handtekeningcertificaten te beperken. Zie Claims en autorisatie beheren met het identiteitsmodel en federatie en uitgegeven tokens voor meer informatie.
Schakelen tussen identiteiten zonder een beveiligingscontext
Het volgende geldt alleen voor WinFX.
Wanneer er een verbinding tot stand wordt gebracht tussen een client en server, verandert de identiteit van de client niet, behalve in één situatie: nadat de WCF-client is geopend, als aan alle volgende voorwaarden wordt voldaan:
De procedures voor het tot stand brengen van een beveiligingscontext (met behulp van een transportbeveiligingssessie of berichtbeveiligingssessie) is uitgeschakeld (EstablishSecurityContext eigenschap is ingesteld
falseop het geval van berichtbeveiliging of transport dat niet in staat is om beveiligingssessies tot stand te brengen, wordt gebruikt in transportbeveiligingscases. HTTPS is één voorbeeld van dergelijk transport).U gebruikt Windows-verificatie.
U stelt de referentie niet expliciet in.
U roept de service aan onder de geïmiteerde beveiligingscontext.
Als aan deze voorwaarden wordt voldaan, kan de identiteit die wordt gebruikt om de client te verifiëren bij de service veranderen (dit is mogelijk niet de geïmiteerde identiteit, maar in plaats daarvan de procesidentiteit) nadat de WCF-client is geopend. Dit komt doordat de Windows-referentie die wordt gebruikt voor het verifiëren van de client bij de service, wordt verzonden met elk bericht en de referentie die wordt gebruikt voor verificatie wordt verkregen via de Windows-identiteit van de huidige thread. Als de Windows-identiteit van de huidige thread verandert (bijvoorbeeld door een andere aanroeper te imiteren), kan de referentie die is gekoppeld aan het bericht en wordt gebruikt om de client bij de service te verifiëren, ook worden gewijzigd.
Als u deterministisch gedrag wilt hebben wanneer u Windows-verificatie samen met imitatie gebruikt, moet u expliciet de Windows-referentie instellen of moet u een beveiligingscontext met de service tot stand brengen. Gebruik hiervoor een berichtbeveiligingssessie of een transportbeveiligingssessie. Het net.tcp-transport kan bijvoorbeeld een transportbeveiligingssessie bieden. Daarnaast moet u alleen een synchrone versie van clientbewerkingen gebruiken bij het aanroepen van de service. Als u een beveiligingscontext voor berichten tot stand brengt, moet u de verbinding met de service niet langer openen dan de geconfigureerde periode voor sessievernieuwing, omdat de identiteit ook kan worden gewijzigd tijdens het sessievernieuwingsproces.
Capture van referenties
Het volgende is van toepassing op .NET Framework 3.5 en volgende versies.
Referenties die door de client of de service worden gebruikt, zijn gebaseerd op de huidige contextthread. De referenties worden verkregen wanneer de Open methode (of BeginOpenvoor asynchrone aanroepen) van de client of service wordt aangeroepen. Voor zowel de als ClientBase<TChannel> de ServiceHost klassen nemen de Open en BeginOpen methoden over van de Open en BeginOpen methoden van de CommunicationObject klasse.
Notitie
Wanneer u de BeginOpen methode gebruikt, kunnen de vastgelegde referenties niet worden gegarandeerd als de referenties van het proces dat de methode aanroept.
Tokencaches toestaan dat opnieuw afspelen met verouderde gegevens wordt gebruikt
WCF gebruikt de functie lokale beveiligingsinstantie (LSA) LogonUser om gebruikers te verifiëren op gebruikersnaam en wachtwoord. Omdat de aanmeldingsfunctie een kostbare bewerking is, kunt u met WCF tokens opslaan die geverifieerde gebruikers vertegenwoordigen om de prestaties te verbeteren. Met het cachingmechanisme worden de resultaten voor LogonUser volgend gebruik opgeslagen. Dit mechanisme is standaard uitgeschakeld; als u deze wilt inschakelen, stelt u de CacheLogonTokens eigenschap in op of gebruikt u het cacheLogonTokens kenmerk van de <userNameAuthentication>.true
U kunt een TTL (Time to Live) instellen voor de tokens in de cache door de CachedLogonTokenLifetime eigenschap in te stellen op een TimeSpanof het cachedLogonTokenLifetime kenmerk van het userNameAuthentication element te gebruiken. De standaardwaarde is 15 minuten. Houd er rekening mee dat hoewel een token in de cache is opgeslagen, elke client met dezelfde gebruikersnaam en hetzelfde wachtwoord het token kan gebruiken, zelfs als het gebruikersaccount wordt verwijderd uit Windows of als het wachtwoord is gewijzigd. Totdat de TTL verloopt en het token uit de cache wordt verwijderd, staat WCF toe dat de (mogelijk kwaadwillende) gebruiker zich kan verifiëren.
Om dit te verhelpen: verklein het aanvalsvenster door de waarde in cachedLogonTokenLifetime te stellen op de kortste tijd die uw gebruikers nodig hebben.
Uitgegeven tokenautorisatie: vervaldatum opnieuw instellen op grote waarde
Onder bepaalde voorwaarden kan de ExpirationTime eigenschap van de eigenschap AuthorizationContext worden ingesteld op een onverwacht grotere waarde (de MaxValue veldwaarde min één dag of 20 december 9999).
Dit gebeurt wanneer u de WSFederationHttpBinding en een van de door het systeem geleverde bindingen gebruikt die een uitgegeven token hebben als het clientreferentietype.
Dit gebeurt ook wanneer u aangepaste bindingen maakt met behulp van een van de volgende methoden:
Om dit te verhelpen, moet het autorisatiebeleid de actie en de verlooptijd van elk autorisatiebeleid controleren.
De service maakt gebruik van een ander certificaat dan de client die is bedoeld
Onder bepaalde voorwaarden kan een client een bericht digitaal ondertekenen met een X.509-certificaat en de service een ander certificaat laten ophalen dan het beoogde certificaat.
Dit kan gebeuren onder de volgende omstandigheden:
De client ondertekent een bericht digitaal met een X.509-certificaat en koppelt het X.509-certificaat niet aan het bericht, maar verwijst naar het certificaat met behulp van de onderwerpsleutel-id.
De computer van de service bevat twee of meer certificaten met dezelfde openbare sleutel, maar bevatten verschillende gegevens.
De service haalt een certificaat op dat overeenkomt met de onderwerpsleutel-id, maar het is niet het certificaat dat de client wilde gebruiken. Wanneer WCF het bericht ontvangt en de handtekening verifieert, wijst WCF de informatie in het onbedoelde X.509-certificaat toe aan een set claims die verschillen en mogelijk verhoogd zijn van wat de client verwacht.
Om dit te verhelpen, verwijst u op een andere manier naar het X.509-certificaat, zoals het gebruik ervan IssuerSerial.