Nouvelles règles de diagnostic dans PVS-Studio 4

La version PVS-Studio 7.34 a introduit un certain nombre de nouvelles règles de diagnostic dans l'analyseur : analyse de contamination pour Java, règles de diagnostic spécifiques à Unity pour C#, plongée approfondie dans OWASP, et bien plus encore ! Cet article les couvrira tous.

C

Dans cette version, l'équipe C s'est concentrée sur les règles de diagnostic d'analyse générale et la prise en charge de diverses normes de développement logiciel.

Mais accrochez votre chapeau, ce n'est que le début ! L'équipe prévoit de couvrir encore plus de règles de diagnostic standard MISRA, alors restez à l'écoute pour plus de nouvelles :)

Et pour l'instant, passons en revue les principales règles de la version 7.34.

V1116

La création d'un objet d'exception sans message explicatif peut entraîner une journalisation insuffisante.

Cette règle de diagnostic est conçue pour détecter les exceptions créées sans messages explicatifs.

L'absence de message peut gêner le processus de détection et de correction des erreurs, ainsi que la lisibilité globale du code.

Voici un exemple de code qui fait que l'analyseur PVS-Studio génère un avertissement :

void SomeCheck(const char *val)
{
  if (!val) throw std::runtime_error { "" };
  ....
}

void Foo()
{
  const char *val = ....;
  try
  {
    SomeCheck(val);              // <=
  }
  catch(std::runtime_error &err)
  {
    std::cerr << err.what() << std::endl;
  }
}

Si une erreur se produit, la fonction SomeCheck lève une exception avec un message vide, qui sera géré dans la fonction Foo. Pendant le traitement, std::cerr est censé contenir des informations sur la raison de l'exception, mais ce n'est pas le cas.

En écrivant du code de cette manière, un développeur envoie des vœux de « bon débogage » à ses collègues. Cela empêche de comprendre exactement la cause de l’échec.

La règle fonctionne pour une exception standard. Vous pouvez utiliser le mécanisme d'annotation personnalisé pour émettre des avertissements pour les exceptions personnalisées.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V1117 [Pour le langage C]

Le type de fonction déclaré est qualifié cv. Le comportement lors de l'utilisation de ce type n'est pas défini.

Cette règle de diagnostic s'applique uniquement au langage C.

Il vise à détecter les cas de définitions de types de fonctions qui utilisent des qualificatifs const ou volatiles.

Selon la norme C23 (10ème point du paragraphe 6.7.4.1), l'utilisation de ces types conduit à un comportement indéfini.

Un exemple de code qui fait que l'analyseur PVS-Studio génère un avertissement :

typedef int fun_t(void);

typedef const fun_t const_qual_fun_t;          // <=

typedef const fun_t * ptr_to_const_qual_fun_t; // <=

void foo()
{
  const fun_t c_fun_t;       // <=
  const fun_t * ptr_c_fun_t; // <=
}

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V2022 [Pour le langage C]

Conversion de type implicite du type entier au type enum.

Une autre règle de diagnostic pour le langage C qui peut aider lors du refactoring et du débogage.

Cette règle permet à l'analyseur de détecter les conversions implicites de types entiers en types énumérations.

Un exemple de code avec l'avertissement PVS-Studio :

void SomeCheck(const char *val)
{
  if (!val) throw std::runtime_error { "" };
  ....
}

void Foo()
{
  const char *val = ....;
  try
  {
    SomeCheck(val);              // <=
  }
  catch(std::runtime_error &err)
  {
    std::cerr << err.what() << std::endl;
  }
}

Ce code utilise l'opérateur conditionnel (?:) pour choisir entre deux variables entières posOne et posTwo, ce qui entraîne une conversion implicite.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V5014 [Norme OWASP]

OWASP. La fonction cryptographique est obsolète. Son utilisation peut entraîner des problèmes de sécurité. Pensez à passer à une fonction équivalente plus récente.

Voici une nouvelle règle de diagnostic axée sur la sécurité, alignée sur les principes SAST.

Cette règle a été conçue selon la norme de vérification de sécurité OWASP.

Il vise à détecter les appels de fonctions cryptographiques obsolètes. Leur utilisation peut entraîner des problèmes critiques de sécurité logicielle.

Un exemple de code avec l'avertissement PVS-Studio :

typedef int fun_t(void);

typedef const fun_t const_qual_fun_t;          // <=

typedef const fun_t * ptr_to_const_qual_fun_t; // <=

void foo()
{
  const fun_t c_fun_t;       // <=
  const fun_t * ptr_c_fun_t; // <=
}

Selon la documentation Microsoft, les fonctions CryptoImportKey et CryptoDestroyKey sont obsolètes. Ceux-ci doivent être remplacés par des homologues sécurisés de Cryptography Next Generation (BCryptoImportKey et BCryptoDestroyKey).

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

Mais ce n'est qu'un échauffement ! L'équipe C&C prévoit de couvrir encore plus de règles de diagnostic sur diverses normes de développement logiciel. Une attention particulière sera portée à la norme MISRA. Alors attendez les nouvelles :)

C

Dans la nouvelle version PVS-Studio 7.34, l'équipe C# s'est concentrée sur la création de règles de diagnostic spécifiques à Unity mais n'a pas non plus oublié les règles d'analyse générale.

Commençons par ce dernier.

V3207

Le modèle logique « pas A ni B » peut ne pas fonctionner comme prévu. Le modèle « non » correspond uniquement à la première expression du modèle « ou ».

Cette nouvelle règle de diagnostic a pour objectif de détecter les utilisations incorrectes du motif non A ou B. Le problème vient de la confusion des développeurs sur la priorité des opérations.

Un exemple de code avec l'avertissement PVS-Studio :

Orientation GetOrientation (bool b)
{
  int posOne = 1;
  int posTwo = 2;
  return b ? posOne : posTwo;    // V2022
}

Au début de la méthode, la clé du paramètre d'entrée est vérifiée pour une chaîne vide ou nulle.

Mais il y a une erreur dans la logique de l'expression conditionnelle. La priorité de l'opérateur not est supérieure à celle de l'opérateur or. Par conséquent, la négation ne s’applique pas au côté droit de l’expression. De plus, si la clé est définie sur null, la condition sera vraie.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V3208 [Moteur Unity]

Moteur Unity. L'utilisation de « WeakReference » avec « UnityEngine.Object » n'est pas prise en charge. GC ne récupérera pas la mémoire de l'objet car il est lié à un objet natif.

Il s'agit de la première règle de diagnostic d'une nouvelle série de règles spécifiques à Unity.

Il vise à détecter les utilisations de UnityEngine.Object (ou d'autres objets hérités de celui-ci) avec System.WeakReference.

En raison de l'utilisation implicite de l'instance par le moteur lui-même, le comportement d'une référence faible peut différer de ce qui est attendu.

Un exemple de code avec l'avertissement PVS-Studio :

void SomeCheck(const char *val)
{
  if (!val) throw std::runtime_error { "" };
  ....
}

void Foo()
{
  const char *val = ....;
  try
  {
    SomeCheck(val);              // <=
  }
  catch(std::runtime_error &err)
  {
    std::cerr << err.what() << std::endl;
  }
}

Dans l'exemple, on peut voir une référence faible à un objet de la classe GameObject. Même si un auteur n'a pas créé de références fortes à cet objet, le ramasse-miettes ne pourra pas le nettoyer.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V3209 [Moteur Unity]

Moteur Unity. Utiliser wait sur un objet « Awaitable » plusieurs fois peut entraîner une exception ou un blocage, car ces objets sont renvoyés dans le pool après avoir été attendus.

Dans une autre règle de diagnostic pour Unity, l'analyseur recherche des emplacements ayant plusieurs utilisations du même objet UnityEngine.Awaitable avec l'opérateur wait.

Les objets sont stockés dans un pool d'objets à des fins d'optimisation.

Lors de l'appel en attente, l'objet Awaitable est renvoyé dans le pool. Après cela, si wait est à nouveau appliqué au même objet, nous obtenons une exception. Dans certains cas, une impasse est également possible.

Un exemple de code avec l'avertissement PVS-Studio :

typedef int fun_t(void);

typedef const fun_t const_qual_fun_t;          // <=

typedef const fun_t * ptr_to_const_qual_fun_t; // <=

void foo()
{
  const fun_t c_fun_t;       // <=
  const fun_t * ptr_c_fun_t; // <=
}

Dans ce code, nous obtenons une exception ou un blocage. Laissez-moi vous expliquer pourquoi. Nous obtenons une valeur en utilisant l'appel wait de waitable. Ensuite, nous initialisons la variable résultat avec cette valeur. L'impasse se produit, car wait a déjà été appliqué à waitable dans une construction conditionnelle.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V3210 [Moteur Unity]

Moteur Unity. Unity ne permet pas de supprimer le composant « Transform » à l'aide des méthodes « Destroy » ou « DestroyImmediate ». L'appel de méthode sera ignoré.

Cette règle de diagnostic vise à détecter les anomalies liées aux appels des méthodes Destroy ou DestroyImmediate de la classe UnityEngine.Object.

Le problème se produit dans une situation où un argument de type UnityEngine.Transform est utilisé. Cela provoque une erreur lors de l'appel de la méthode. La suppression du composant Transform d'un objet de jeu n'est pas autorisée dans Unity.

Un exemple de code avec l'avertissement PVS-Studio :

Orientation GetOrientation (bool b)
{
  int posOne = 1;
  int posTwo = 2;
  return b ? posOne : posTwo;    // V2022
}

La propriété transform de la classe de base MonoBehaviour renvoie une instance de la classe Transform, qui est passée en argument à la méthode Destroy.

Lors de l'appel de la méthode de cette manière, Unity donnera un message d'erreur, mais le composant lui-même ne sera pas détruit.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V4007 [Moteur Unity]

Moteur Unity. Évitez de créer et de détruire des objets UnityEngine dans un contexte sensible aux performances. Pensez plutôt à les activer et les désactiver.

Cette règle de diagnostic cible une gamme différente d'erreurs : les problèmes de performances.

Si vous êtes intéressé par la façon dont l'analyse statique peut aider à optimiser les projets Unity, je vous invite à lire cet article.

Le but de cette règle est d'aider l'analyseur à détecter la création d'objets Unity dans une méthode fréquemment exécutée.

La création/destruction régulière d'objets de jeu charge non seulement le processeur, mais entraîne également une fréquence accrue d'appels au garbage collector. Cela affecte les performances.

Un exemple de code avec l'avertissement PVS-Studio :

void SomeCheck(const char *val)
{
  if (!val) throw std::runtime_error { "" };
  ....
}

void Foo()
{
  const char *val = ....;
  try
  {
    SomeCheck(val);              // <=
  }
  catch(std::runtime_error &err)
  {
    std::cerr << err.what() << std::endl;
  }
}

Ici, dans la méthode Update, une _instance d'objet de jeu est créée et détruite. Étant donné que Update est exécuté à chaque fois que les trames sont mises à jour, il est recommandé d'éviter ces opérations si possible.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

D'ailleurs, d'autres diagnostics Unity sont encore à venir ! Préparez-vous à de bonnes nouvelles de notre équipe :)

Encore une chose...

Nous ne pouvons que vous parler d'une amélioration importante de l'analyseur C# : le suivi des modifications de la valeur de retour de la méthode entre les appels. Qu'est-ce que ça change ? Décomposons-le.

Découvrez cet exemple :

typedef int fun_t(void);

typedef const fun_t const_qual_fun_t;          // <=

typedef const fun_t * ptr_to_const_qual_fun_t; // <=

void foo()
{
  const fun_t c_fun_t;       // <=
  const fun_t * ptr_c_fun_t; // <=
}

La méthode Sample() vérifie la valeur de retour de Foo() pour null. La méthode Foo() est ensuite rappelée dans le corps de la condition, et sa valeur de retour est déréférencée.

Auparavant, l'analyseur générait un avertissement dans ce cas car il ne considérait pas le contexte d'une invocation, se concentrant uniquement sur le code de sa déclaration. L'analyseur laissait entendre que null pouvait être renvoyé.

Maintenant, l'analyseur comprend que Foo() renvoie la même valeur dans les deux cas et il n'y aura aucun avertissement.

Mais regardons un exemple avec du code légèrement modifié...

Orientation GetOrientation (bool b)
{
  int posOne = 1;
  int posTwo = 2;
  return b ? posOne : posTwo;    // V2022
}

À partir de la déclaration de la méthode Foo(), nous pouvons obtenir que lorsque _condition == true, la méthode renvoie non null.

L'analyseur verra le champ _condition changer avant le deuxième appel et fera une hypothèse : si le champ utilisé dans Foo() a changé, la valeur de retour de Foo() pourrait également avoir changé.

En conséquence, les avertissements d'un déréférencement potentiel resteront.

L'analyseur C# prend désormais en charge l'analyse des projets .NET 9 ! Apprenez-en plus sur ces fonctionnalités et sur d’autres nouvelles fonctionnalités de PVS-Studio 7.34 ici.

Java

Avec la sortie de PVS-Studio 7.34, l'analyseur Java dispose désormais d'un mécanisme d'analyse des contaminations !

Ce mécanisme est devenu la base de la première règle de diagnostic : la recherche d'injections SQL. Les futures mises à jour de l'analyseur Java se concentreront sur SAST, la liste OWASP Top-10 des vulnérabilités potentielles les plus courantes et d'autres règles de diagnostic liées aux failles.

Tout de suite, commençons par quelques nouvelles règles d'analyse générale, car elles valent également la peine.

V6123

La valeur modifiée de l'opérande n'est pas utilisée après l'opération d'incrémentation/décrémentation.

Cette nouvelle règle de diagnostic met en évidence les zones du code où les valeurs des opérations postfix ne sont pas utilisées.

Le problème est que soit une opération est redondante, soit, plus sérieusement, les opérations se sont mélangées et un développeur a voulu utiliser le préfixe.

Un exemple de code avec l'avertissement PVS-Studio :

void SomeCheck(const char *val)
{
  if (!val) throw std::runtime_error { "" };
  ....
}

void Foo()
{
  const char *val = ....;
  try
  {
    SomeCheck(val);              // <=
  }
  catch(std::runtime_error &err)
  {
    std::cerr << err.what() << std::endl;
  }
}

L'opérateur n'affectera pas la valeur que la méthode calculateSomething renverra.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V6124

La conversion d'un littéral entier en type avec une plage de valeurs plus petite entraînera un débordement.

Comme vous pouvez le voir d'après le nom de cette règle de diagnostic, elle détecte un éventuel débordement.

Un exemple de code avec l'avertissement PVS-Studio :

typedef int fun_t(void);

typedef const fun_t const_qual_fun_t;          // <=

typedef const fun_t * ptr_to_const_qual_fun_t; // <=

void foo()
{
  const fun_t c_fun_t;       // <=
  const fun_t * ptr_c_fun_t; // <=
}

Une variable de type entier s'est vu attribuer une valeur hors de la plage valide, ce qui provoquera un débordement.

Les variables stockeront évidemment des valeurs différentes de celles que le développeur a essayé d'attribuer.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V6125

L’appel des méthodes « wait », « notify » et « notifyAll » en dehors d’un contexte synchronisé entraînera « IllegalMonitorStateException ».

Ce diagnostic permet d'identifier les problèmes de synchronisation.

Un exemple de code avec l'avertissement PVS-Studio :

Orientation GetOrientation (bool b)
{
  int posOne = 1;
  int posTwo = 2;
  return b ? posOne : posTwo;    // V2022
}

L'analyseur repère les méthodes wait, notify et notifyAll, car elles peuvent être appelées dans un contexte non synchronisé. Ils fonctionnent avec le moniteur de l'objet par lequel la synchronisation s'effectue. Autrement dit, leur invocation n'est correcte que dans le contexte synchronisé et uniquement sur l'objet par lequel la synchronisation se produit.

Si les méthodes wait, notify ou notifyAll sont appelées dans un contexte non synchronisé ou sur le mauvais objet, nous obtenons l'exception IllegalMonitorStateException.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

V5309 [norme OWASP]

OWASP. Possibilité d'injection SQL. Des données potentiellement corrompues sont utilisées pour créer une commande SQL.

La première règle de diagnostic liée aux souillures de l'analyseur Java ! Plus précisément, l'analyseur peut désormais détecter d'éventuelles injections SQL.

L'injection SQL est une vulnérabilité qui permet à un attaquant d'injecter son code dans une requête SQL. Si la requête utilise des données externes, sans les valider correctement, on risque l'intégrité et la confidentialité des informations stockées dans une base de données.

void SomeCheck(const char *val)
{
  if (!val) throw std::runtime_error { "" };
  ....
}

void Foo()
{
  const char *val = ....;
  try
  {
    SomeCheck(val);              // <=
  }
  catch(std::runtime_error &err)
  {
    std::cerr << err.what() << std::endl;
  }
}

Dans le cas où l'utilisateur s'avère malveillant et que la valeur du paramètre est approximativement la suivante : - "111' ou 1=1 ; supprimez les utilisateurs de la table ; sélectionnez ' ",—vous pouvez dire au revoir à la table des utilisateurs. Il est donc important de vérifier les données externes.

Consultez la documentation pour plus de détails sur cette règle de diagnostic.

Merci d'avoir lu !

Si vous avez des demandes d'articles ou des questions, n'hésitez pas à les envoyer via le formulaire de feedback. Enfin et surtout, nous aimerions connaître votre avis dans les commentaires :)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!