La plupart des API de sécurité d’accès du code sont obsolètes

La plupart des types liés à la sécurité d’accès du code (CAS) dans .NET sont désormais obsolètes en tant qu’avertissement. Cela inclut les attributs CAS, comme SecurityPermissionAttribute, les objets d’autorisation CAS, comme SocketPermission, les types dérivés de EvidenceBase et d’autres API de prise en charge.

Description de la modification

Dans .NET Framework 2.x - 4.x, les attributs et API CAS peuvent influencer le cours d’exécution du code, notamment en s’assurant que les étapes de la pile à la demande CAS réussissent ou échouent.

// In .NET Framework, the attribute causes CAS stack walks
// to terminate successfully when this permission is demanded.
[SocketPermission(SecurityAction.Assert, Host = "contoso.com", Port = "443")]
public void DoSomething()
{
    // open a socket to contoso.com:443
}

Dans .NET Core 2.x - 3.x, le runtime ne respecte pas les attributs CAS ou les API CAS. Le runtime ignore les attributs lors de l’entrée de méthode, et la plupart des API programmatiques n’ont aucun effet.

// The .NET Core runtime ignores the following attribute.
[SocketPermission(SecurityAction.Assert, Host = "contoso.com", Port = "443")]
public void DoSomething()
{
    // open a socket to contoso.com:443
}

En outre, les appels programmatiques à des API étendues (Assert) réussissent toujours, tandis que les appels programmatiques aux API restrictives (Deny, PermitOnly) lèvent toujours une exception au moment de l’exécution. (PrincipalPermission est une exception à cette règle. Consultez la section Action recommandée ci-dessous.)

public void DoAssert()
{
    // The line below has no effect at run time.
    new SocketPermission(PermissionState.Unrestricted).Assert();
}

public void DoDeny()
{
    // The line below throws PlatformNotSupportedException at run time.
    new SocketPermission(PermissionState.Unrestricted).Deny();
}

Dans .NET 5 et versions ultérieures, la plupart des API liées à CAS sont obsolètes et produisent un avertissement SYSLIB0003 au moment de la compilation.

[SocketPermission(SecurityAction.Assert, Host = "contoso.com", Port = "443")] // warning SYSLIB0003
public void DoSomething()
{
    new SocketPermission(PermissionState.Unrestricted).Assert(); // warning SYSLIB0003
    new SocketPermission(PermissionState.Unrestricted).Deny(); // warning SYSLIB0003
}

Il s’agit d’une modification au moment de la compilation uniquement. Il n’y a aucune modification au moment de l’exécution par rapport aux versions précédentes de .NET Core. Les méthodes qui n’effectuent aucune opération dans .NET Core 2.x - 3.x continueront à n’effectuer aucune opération au moment de l’exécution dans .NET 5 et versions ultérieures. Les méthodes qui lèvent PlatformNotSupportedException dans .NET Core 2.x - 3.x continueront à lever PlatformNotSupportedException au moment de l’exécution dans .NET 5 et versions ultérieures.

Raison du changement

La sécurité d’accès du code (CAS) est une technologie héritée non prise en charge. L’infrastructure permettant d’activer CAS existe uniquement dans .NET Framework 2.x - 4.x, mais elle est déconseillée et ne reçoit pas de correctifs de maintenance ou de sécurité.

En raison de la dépréciation de CAS, l’infrastructure de prise en charge n’a pas été transférée à .NET Core ou .NET 5+. Toutefois, les API ont été introduites afin que les applications puissent effectuer une compilation croisée sur .NET Framework et .NET Core. Cela a conduit à des scénarios d’« échec de l’ouverture », où certaines API liées à l’environnement d’administration centrale existent et peuvent être appelées, mais n’effectuent aucune action au moment de l’exécution. Cela peut entraîner des problèmes de sécurité pour les composants qui s’attendent à ce que le runtime honore les attributs liés à CAS ou les appels d’API programmatiques. Pour mieux communiquer que le runtime ne respecte pas ces attributs ou API, nous avons rendu la majorité d’entre eux obsolètes dans .NET 5.0.

Version introduite

5,0

  • Si vous affirmez une autorisation de sécurité, supprimez l’attribut ou l’appel qui affirme l’autorisation.

    // REMOVE the attribute below.
    [SecurityPermission(SecurityAction.Assert, ControlThread = true)]
    public void DoSomething()
    {
    }
    
    public void DoAssert()
    {
        // REMOVE the line below.
        new SecurityPermission(SecurityPermissionFlag.ControlThread).Assert();
    }
    
  • Si vous refusez ou limitez une autorisation (via PermitOnly), contactez votre conseiller en sécurité. Étant donné que les attributs CAS ne sont pas respectés par le runtime .NET 5+, votre application peut avoir une faille de sécurité si elle s’appuie incorrectement sur l’infrastructure CAS pour restreindre l’accès à ces méthodes.

    // REVIEW the attribute below; could indicate security vulnerability.
    [SecurityPermission(SecurityAction.Deny, ControlThread = true)]
    public void DoSomething()
    {
    }
    
    public void DoPermitOnly()
    {
        // REVIEW the line below; could indicate security vulnerability.
        new SecurityPermission(SecurityPermissionFlag.ControlThread).PermitOnly();
    }
    
  • Si vous demandez une autorisation (sauf PrincipalPermission), supprimez la demande. Toutes les demandes réussissent au moment de l’exécution.

    // REMOVE the attribute below; it will always succeed.
    [SecurityPermission(SecurityAction.Demand, ControlThread = true)]
    public void DoSomething()
    {
    }
    
    public void DoDemand()
    {
        // REMOVE the line below; it will always succeed.
        new SecurityPermission(SecurityPermissionFlag.ControlThread).Demand();
    }
    
  • Si vous exigez PrincipalPermission, consultez les conseils pour PrincipalPermissionAttribute est obsolète en tant qu’erreur. Cette aide s’applique à la fois à PrincipalPermission et PrincipalPermissionAttribute.

  • Si vous devez absolument désactiver ces avertissements (ce qui n’est pas recommandé), vous pouvez supprimer l’avertissement SYSLIB0003 dans le code.

    #pragma warning disable SYSLIB0003 // disable the warning
    [SecurityPermission(SecurityAction.Demand, ControlThread = true)]
    #pragma warning restore SYSLIB0003 // re-enable the warning
    public void DoSomething()
    {
    }
    
    public void DoDemand()
    {
    #pragma warning disable SYSLIB0003 // disable the warning
        new SecurityPermission(SecurityPermissionFlag.ControlThread).Demand();
    #pragma warning restore SYSLIB0003 // re-enable the warning
    }
    

    Vous pouvez également supprimer l’avertissement dans votre fichier projet. Cela désactive l’avertissement pour tous les fichiers sources au sein du projet.

    <Project Sdk="Microsoft.NET.Sdk">
      <PropertyGroup>
        <TargetFramework>net5.0</TargetFramework>
        <!-- NoWarn below suppresses SYSLIB0003 project-wide -->
        <NoWarn>$(NoWarn);SYSLIB0003</NoWarn>
      </PropertyGroup>
    </Project>
    

    Notes

    La suppression de SYSLIB0003 désactive uniquement les avertissements d’obsolescence liés à CAS. Cela ne désactive pas les autres avertissements ni ne modifie le comportement du runtime .NET 5+.

  • Sécurité

API affectées