Nous recommandons d’utiliser Visual Studio 2017

Fonctionnalités de sécurité dans le CRT

 

Pour obtenir la dernière documentation sur Visual Studio 2017, consultez Documentation Visual Studio 2017.

De nombreuses anciennes fonctions CRT ont de nouvelles moutures plus sécurisées. Si une fonction sécurisée existe, la version antérieure et moins sécurisée est marquée comme déconseillée et la nouvelle version a le suffixe _s (« sécurisée »).

Dans ce contexte, « est déconseillé » signifie que l'utilisation d'une fonction n'est pas recommandée ; il n'indique pas si la suppression de la fonction du CRT est plannifiée.

Les fonctions sécurisées n'empêchent pas ou ne corrige pas les erreurs de sécurité ; en revanche, elles décèlent des erreurs lorsqu'elles se produisent. Ils effectuent les contrôles supplémentaires pour des conditions d'erreur, et en cas d'erreur, ils appellent un gestionnaire d'erreurs (consultez Validation de paramètre).

Par exemple, la fonction strcpy n'a aucun moyen de déterminer si la chaîne qu'il copie est trop grande pour son tampon de destination. Toutefois, son équivalent sécurisé, strcpy_s, prend la taille de la mémoire tampon en tant que paramètre, ce qui peut déterminer si un dépassement de mémoire tampon se produira. Si vous utilisez strcpy_s pour copier onze caractères dans une mémoire tampon de dix- caractère, il s'agit d'une erreur de votre part ; strcpy_s ne peut pas corriger l'erreur, mais elle peut la détecter et vous en avertir en appelant le gestionnaire de paramètre non valide.

Il existe plusieurs façons d'éliminer les avertissements d'abandon des fonctions anciennes ou moins sécurisées. Le plus simple est simplement de définir _CRT_SECURE_NO_WARNINGS ou utilisez le pragma warning. L'option désactive les avertissements d'abandon, mais naturellement les problèmes de sécurité, qui provoquaient les avertissements existent toujours. Il est préférable de laisser les avertissements d'abandon activés et de tirer parti des nouvelles fonctionnalités de sécurité CRT.

En C++, la méthode la plus simple pour le faire et d'utiliser Sécuriser les surcharges de modèle, qui dans de nombreux cas élimine les avertissements d'abandon en remplaçant des appels aux fonctions déconseillées par des appels aux nouvelles versions sécurisées de ces fonctions. Par exemple, considérez l'appel déconseillé à strcpy:

char szBuf[10];   
strcpy(szBuf, "test"); // warning: deprecated   

Définir _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES comme 1 supprime l'avertissement en modifiant l'appel strcpy à strcpy_s, ce qui empêche les dépassements de mémoire tampon. Pour plus d'informations, consultez Sécuriser les surcharges de modèle.

Pour les fonctions déconseillées sans surcharges de modèle, vous devriez envisager de mettre à jour manuellement votre code pour utiliser les versions sécurisées.

Une autre source d'avertissements d'abandon, non liée à la sécurité, sont les fonctions de POSIX. Remplacez les noms des fonctions de POSIX par leurs équivalents standard (par exemple, remplacez accès par _access), ou désactivez les avertissements d'abandon POSIX en définissant _CRT_NONSTDC_NO_WARNINGS. Pour plus d'informations, consultez Deprecated CRT Functions.

Voici quelques-unes de ces fonctionnalités :

  • Parameter Validation. Les paramètres transmis aux fonctions CRT sont validés, dans aussi bien les fonctions sécurisées que dans de nombreuses versions preexistentes de ces fonctions. Ces validations incluent :

    • Vérifier si les valeurs NULL sont transmises aux fonctions.

    • Vérification des valeurs énumérées pour validation.

    • Vérifier que les valeurs intégrales sont dans des intervalles valides.

  • Pour plus d'informations, consultez Validation de paramètre.

  • Un gestionnaire pour les paramètres non valides est également disponible au développeur. Lors de la rencontre avec un paramètre non valide, au lieu de déclarer et de quitter l'application, le CRT fournit un moyen de vérifier ces problèmes avec la fonction_set_invalid_parameter_handler, _set_thread_local_invalid_parameter_handler .

  • Sized Buffers. Les fonctions sécurisées requièrent que la taille de mémoire tampon soit passée à n'importe quelle fonction qui écrit dans une mémoire tampon. Les versions sécurisées valide que la mémoire tampon soit assez large avant de l'écrire, ce qui aide à empecher des dangereuses erreurs de mémoire tampon, qui pourraient permettre à des codes de mauvaise intentions de s'executer. Ces fonctions retournent généralement un type de code erreurerrnoet appellent le gestionnaire de paramètre non valide si la taille de la mémoire tampon est trop petite. Les fonctions, qui sont lues depuit les mémoires tampons d'entrée, telles que gets, ont des versions sécurisées qui exigent que vous spécifiez une taille maximale.

  • Null termination. Certaines fonctions qui laissent des chaines potentiellement non terminées inchangées ont des versions sécurisées qui garantissent que les chaînes sont correctement terminées (avec le caractère NULL).

  • Enhanced error reporting. Ces fonctions sécurisées retournent des codes d'erreur avec plus d'information sur les erreurs, que ce qui était disponible avec les fonctions preexistentes. Les fonctions sécurisées et beaucoup de fonctions préexistentes définissent maintenant errnoet retournent souvent un type de code errno également, pour garantir un meilleur rapport d'erreurs.

  • Filesystem security. Les fichiers sécurisés I/O APIs permettent un accès sécurisé aux fichiers par défaut.

  • Windows security. Les API de traitement sécurisées appliquent les stratégies de sécurité et permettent aux listes de contrôle d'accès d'etre spécifiées.

  • Format string syntax checking. Les chaînes non valides sont détectées, par exemple, en utilisant les caractères de champs de type incorrect dans les chaines de format printf.

Validation de paramètre
Sécuriser les surcharges de modèle
Fonctions de bibliothèque CRT

Afficher: