Syftessträngar i ASP.NET Core

Komponenter som förbrukar IDataProtectionProvider måste skicka en unik syften parameter till CreateProtector metoden. Parametern purposes är inbyggd i dataskyddssystemets säkerhet, eftersom den ger isolering mellan kryptografiska konsumenter, även om rotkrypteringsnycklarna är desamma.

När en konsument anger ett syfte används syftessträngen tillsammans med de kryptografiska rotnycklarna för att härleda kryptografiska undernycklar som är unika för konsumenten. Detta isolerar konsumenten från alla andra kryptografiska konsumenter i programmet: ingen annan komponent kan läsa nyttolasten och den kan inte läsa någon annan komponents nyttolaster. Den här isoleringen gör hela kategorier av attacker mot komponenten ogenomförbara.

Exempel på syftesdiagram

I diagrammet ovan IDataProtector kan instanserna A och B inte läsa varandras nyttolaster, bara deras egna.

Syftessträngen behöver inte vara hemlig. Det bör helt enkelt vara unikt i den meningen att ingen annan korrekt fungerande komponent någonsin kommer att tillhandahålla samma ändamålssträng.

Tips/Råd

Att använda namnområdet och typnamnet för komponenten som använder DATASKYDDS-API:erna är en bra tumregel, eftersom den här informationen i praktiken aldrig kommer att vara i konflikt.

En Contoso-skapad komponent som ansvarar för att mynta bärartoken kan använda Contoso.Security.BearerToken som syftessträng. Eller – ännu bättre – den kan använda Contoso.Security.BearerToken.v1 som sin syftessträng. Om du lägger till versionsnumret kan en framtida version använda Contoso.Security.BearerToken.v2 som syfte, och de olika versionerna skulle vara helt isolerade från varandra när det gäller nyttolaster.

Eftersom parametern purposes till CreateProtector är en strängmatris kunde ovanstående i stället ha angetts som [ "Contoso.Security.BearerToken", "v1" ]. Detta gör det möjligt att upprätta en hierarki av syften och öppnar upp möjligheten till scenarier med flera innehavare med dataskyddssystemet.

Varning

Komponenter bör inte tillåta att ej betrodda användarindata är den enda källan till indata i syfteskedjan.

Överväg till exempel en komponent Contoso.Messaging.SecureMessage som ansvarar för att lagra säkra meddelanden. Om komponenten för säker meddelandehantering anropar CreateProtector([ username ])kan en obehörig användare skapa ett konto med användarnamnet "Contoso.Security.BearerToken" i ett försök att få komponenten att anropa CreateProtector([ "Contoso.Security.BearerToken" ]), vilket oavsiktligt gör att det säkra meddelandesystemet får nyttolaster som kan uppfattas som autentiseringstoken.

En bättre syfteskedja för meddelandekomponenten skulle vara CreateProtector([ "Contoso.Messaging.SecureMessage", $"User: {username}" ]), vilket ger korrekt isolering.

Isoleringen som tillhandahålls av IDataProtectionProvider och IDataProtector, samt deras beteende och syften, är följande:

  • För ett visst IDataProtectionProvider objekt CreateProtector skapar metoden ett IDataProtector objekt som är unikt kopplat till både IDataProtectionProvider det objekt som skapade det och den parameter för ändamål som skickades till metoden.

  • Syftesparametern får inte vara null. (Om syftet anges som en matris innebär det att matrisen inte får vara av noll längd och att alla element i matrisen måste vara icke-null.) Ett tomt strängsyfte är tekniskt tillåtet men rekommenderas inte.

  • Två arguments syften är likvärdiga om och endast om de innehåller samma strängar (med hjälp av en ordinal jämförare) i samma ordning. Ett argument med ett enda syfte motsvarar motsvarande matris för enelementsändamål.

  • Två IDataProtector objekt är likvärdiga om och endast om de skapas från motsvarande IDataProtectionProvider objekt med motsvarande syftesparametrar.

  • För ett visst IDataProtector objekt returnerar ett anrop till Unprotect(protectedData) originalet unprotectedData om och endast om protectedData := Protect(unprotectedData) det gäller ett motsvarande IDataProtector objekt.

Anmärkning

Vi överväger inte fallet där någon komponent avsiktligt väljer en syftessträng som är känd för att vara i konflikt med en annan komponent. En sådan komponent skulle i princip betraktas som skadlig och det här systemet är inte avsett att ge säkerhetsgarantier om skadlig kod redan körs i arbetsprocessen.