Règles Semgrep Swift¶

rules_lgpl_swift_autre_regle-ios-acl-biometrique¶

Résumé :

Contournement de l'authentification par faiblesse primaire

Sévérité : Critique

Description :

L'application utilise des drapeaux ACL biométriques faibles comme .biometryAny, .userPresence ou .touchIDAny lors de l'appel à SecAccessControlCreateWithFlags() pour protéger les éléments du trousseau. Ces drapeaux permettent à n'importe quelle biométrie enregistrée sur l'appareil de s'authentifier, ce qui signifie qu'un attaquant ayant accès physique à l'appareil peut ajouter sa propre empreinte digitale ou son visage et s'authentifier en tant qu'utilisateur légitime, contournant ainsi les contrôles de sécurité prévus.

Remédiation :

Envisagez d'utiliser SecAccessControlCreateWithFlags() avec le drapeau .biometryCurrentSet au lieu de .biometryAny pour garantir que seules les biométries actuellement enregistrées peuvent s'authentifier. Cela empêche un attaquant qui obtient un accès physique à l'appareil d'ajouter ses propres biométries pour s'authentifier en tant qu'utilisateur légitime. De même, privilégiez .touchIDCurrentSet plutôt que .touchIDAny lors du travail spécifiquement avec Touch ID. En créant des objets de contrôle d'accès, combinez ces drapeaux avec des attributs d'accessibilité du trousseau appropriés comme kSecAttrAccessibleWhenUnlockedThisDeviceOnly pour une protection en profondeur. Il est également recommandé de mettre en œuvre des facteurs d'authentification supplémentaires pour des opérations à haute sécurité au-delà des seules biométries.

OWASP :

A2:2017-Authentification rompue
A07:2021-Échecs d'identification et d'authentification

rules_lgpl_swift_other_rule-ios-file-no-special¶

Résumé :

Stockage en clair d'informations sensibles

Gravité : Critique

CWE : CWE-312

Description :

L'application utilise .noFileProtection ou FileProtectionType.none lors de l'écriture de fichiers, ce qui désactive le chiffrement de protection des données iOS pour ces fichiers. Les fichiers créés avec ces options sont stockés sans chiffrement sur le disque et restent accessibles même lorsque l'appareil est verrouillé, les rendant vulnérables à un accès non autorisé si l'appareil est physiquement compromis, lors d'une extraction judiciaire, ou à travers des vulnérabilités du système de fichiers. Cela viole les meilleures pratiques de sécurité iOS pour la protection des données sensibles des utilisateurs au repos.

Remédiation :

Envisagez d'utiliser FileProtectionType.complete lors de l'écriture de fichiers via Data.write(to:options:) pour garantir que les fichiers soient chiffrés et uniquement accessibles lorsque l'appareil est déverrouillé. Pour les fichiers qui doivent être accessibles pendant des tâches en arrière-plan alors que l'appareil est verrouillé, utilisez FileProtectionType.completeUnlessOpen, qui protège les fichiers sauf lorsqu'ils sont déjà ouverts. Pour les fichiers qui doivent être accessibles après le premier déverrouillage mais qui n'ont pas besoin de la protection maximale, utilisez FileProtectionType.completeUntilFirstUserAuthentication. Il est recommandé d'utiliser FileProtectionType.complete comme valeur par défaut pour les données sensibles telles que les informations d'identification utilisateur, les informations personnelles ou les données financières. Notez que les API Core Data et trousseau possèdent des mécanismes de protection séparés et doivent être utilisés pour des données hautement sensibles plutôt que pour un stockage basé sur des fichiers.

OWASP :

A3:2017-Exposition de données sensibles
A02:2021-Failles cryptographiques

rules_lgpl_swift_other_rule-ios-tls3-not-used¶

Résumé :

Sélection d'un algorithme moins sécurisé lors de la négociation ('downgrade d'algorithme')

Sévérité : Critique

CWE : CWE-757

Description :

L'application définit TLSMinimumSupportedProtocolVersion à .TLSv1_0, .TLSv1_1 ou .TLSv1_2, qui sont des versions de protocole TLS obsolètes. TLS 1.0 et 1.1 ont été officiellement dépréciés par l'IETF en mars 2021 en raison de vulnérabilités connues, y compris la susceptibilité aux attaques BEAST, POODLE, et d'autres attaques de downgrade. Bien que TLS 1.2 soit encore largement pris en charge, il lui manque les améliorations de sécurité modernes de TLS 1.3, y compris la confidentialité parfaite par défaut, un handshake simplifié réduisant la surface d'attaque, et la suppression des algorithmes cryptographiques obsolètes. L'utilisation de versions TLS plus anciennes expose l'application à des attaques de type homme du milieu et à des vulnérabilités au niveau du protocole.

Remédiation :

Envisagez de passer à TLS 1.3 en définissant TLSMinimumSupportedProtocolVersion à .TLSv13 dans URLSessionConfiguration ou lors de la configuration de NWParameters pour les connexions réseau. TLS 1.3 offre des améliorations de sécurité significatives, y compris la confidentialité parfaite obligatoire, des métadonnées de handshake chiffrées et la suppression des suites cryptographiques vulnérables. Lorsque vous utilisez URLSession, configurez la session avec une configuration .default ou .ephemeral et définissez explicitement la version minimale du protocole. Il est recommandé de tester soigneusement, car certains serveurs légendaires peuvent ne pas prendre en charge TLS 1.3, auquel cas TLS 1.2 peut être utilisé comme solution de secours avec des suites cryptographiques robustes imposées. Envisagez de mettre en œuvre le pinning de certificats en parallèle avec TLS 1.3 pour une protection supplémentaire contre les compromissions de l'autorité de certification.

OWASP :

A6:2017-Mauvaise configuration de la sécurité
A05:2021-Mauvaise configuration de la sécurité

rules_lgpl_swift_other_rule-ios-dtls1-used¶

Résumé :

Sélection d'un algorithme moins sécurisé lors de la négociation (« rétrogradation d'algorithme »)

Sévérité : Moyenne

CWE : CWE-757

Description :

L'application configure TLSMinimumSupportedProtocolVersion pour utiliser DTLSv10 (DTLS 1.0), qui est une version de protocole obsolète et peu sécurisée. DTLS 1.0 hérite des vulnérabilités de TLS 1.0, y compris la susceptibilité aux attaques BEAST, aux suites de chiffrement faibles, et l'absence de protections cryptographiques modernes. DTLS est utilisé pour sécuriser les protocoles basés sur des datagrammes comme UDP, et l'utilisation de la version 1.0 expose l'application à des faiblesses de sécurité connues qui peuvent compromettre la confidentialité et l'intégrité des données transmises.

Remédiation :

Envisagez de passer à DTLS 1.2 en configurant TLSMinimumSupportedProtocolVersion sur .DTLSv12 lors de la configuration des connexions réseau utilisant le framework Network ou des API similaires. DTLS 1.2 fournit des suites de chiffrement plus solides, une sécurité de poignée de main améliorée, et des protections contre des attaques connues sur les versions antérieures. Lors de l'utilisation de NWParameters pour des connexions UDP, configurez les options de sécurité pour exiger explicitement DTLS 1.2 ou supérieur. Il est recommandé de revoir et d'imposer une sélection de suites de chiffrement solides pour prévenir les attaques de rétrogradation. Notez que le support de DTLS 1.3 peut être disponible dans les versions iOS plus récentes et doit être préféré lorsque la compatibilité avec les anciens systèmes n'est pas requise.

OWASP :

A6:2017-Mauvaise configuration de la sécurité
A05:2021-Mauvaise configuration de la sécurité

rules_lgpl_swift_other_rule-ios-keychain-weak-accessibility-value¶

Résumé :

Contournement d'authentification par une faiblesse primaire

Gravité : Moyenne

CWE : CWE-305

Description :

L'application utilise des attributs d'accessibilité de trousseau faibles kSecAttrAccessibleAlways ou kSecAttrAccessibleAfterFirstUnlock lors de l'enregistrement d'éléments via SecItemAdd() ou des API de trousseau connexes. kSecAttrAccessibleAlways permet d'accéder aux éléments de la trousseau même lorsque l'appareil est verrouillé, n'offrant aucune protection contre le compromis physique de l'appareil. kSecAttrAccessibleAfterFirstUnlock rend les éléments accessibles après le premier déverrouillage suivant un redémarrage, ce qui signifie qu'ils restent accessibles pendant toute la durée de fonctionnement de l'appareil, quel que soit l'état de verrouillage. Les deux options ne parviennent pas à tirer parti de la protection des données iOS pour sécuriser des données sensibles lorsque l'appareil est verrouillé.

Remédiation :

Envisagez d'utiliser kSecAttrAccessibleWhenUnlocked comme valeur pour kSecAttrAccessible dans les requêtes de trousseau afin de garantir que les éléments ne soient accessibles que lorsque l'appareil est déverrouillé. Pour les éléments qui ne doivent pas se synchroniser entre les appareils, utilisez kSecAttrAccessibleWhenUnlockedThisDeviceOnly, qui offre à la fois un chiffrement lorsqu'il est verrouillé et empêche la synchronisation avec le trousseau iCloud. Pour des données extrêmement sensibles comme les jetons d'authentification ou les clés de chiffrement, envisagez de combiner le stockage dans le trousseau avec une authentification biométrique ou par code d'accès supplémentaire utilisant SecAccessControl avec les drapeaux .userPresence ou .biometryCurrentSet. Il est recommandé d'auditer tous les éléments du trousseau et de migrer l'utilisation héritée de kSecAttrAccessibleAlways vers des classes de protection plus fortes appropriées au niveau de sensibilité de chaque type de donnée.

OWASP :

A2:2017-Authentification Brisée
A07:2021-Échecs d'Identification et d'Authentification