Aller au contenu

Règles génériques Semgrep

rules_lgpl_oc_other_rule-ios-self-signed-ssl

Résumé :

Utilisation d'une fonction potentiellement dangereuse

Gravité : Critique

CWE : CWE-676

Description :

L'application autorise des certificats SSL auto-signés ou invalides en utilisant des modèles tels que continueWithoutCredentialForAuthenticationChallenge, kCFStreamSSLAllowsAnyRoot, kCFStreamSSLAllowsExpiredCertificates, ou validatesSecureCertificate = NO. Cela rend l'application vulnérable aux attaques MITM où un attaquant pourrait usurper l'identité du serveur et intercepter des données sensibles.

Mesures correctives :

Envisagez de mettre en œuvre une validation appropriée des certificats SSL dans votre application iOS. Il est recommandé d'utiliser NSURLSession avec les paramètres de sécurité par défaut et d'éviter de désactiver la validation des certificats. Supprimez toute utilisation de continueWithoutCredentialForAuthenticationChallenge, kCFStreamSSLAllowsAnyRoot, ou des modèles similaires qui contournent les vérifications de certificats. Définissez configuration.TLSMinimumSupportedProtocol = kTLSProtocol12 pour imposer des versions TLS modernes.

OWASP :

  • A9:2017 - Utilisation de composants avec des vulnérabilités connues
  • A06:2021 - Composants vulnérables et obsolètes

rules_lgpl_oc_other_rule-ios-webview-ignore-ssl

Résumé :

Validation de certificat inappropriée

Gravité : Critique

CWE : CWE-295

Description :

UIWebView dans l'application ignore les erreurs SSL et accepte tout certificat SSL en utilisant des patterns tels que allowsAnyHTTPSCertificateForHost, loadingUnvalidatedHTTPSPage = YES, ou allowsAnyHTTPSCertificate = YES. Cela rend l'application vulnérable aux attaques MITM où un attaquant pourrait usurper l'identité du serveur et intercepter des données sensibles.

Remédiation :

Envisagez de mettre en œuvre une validation appropriée des certificats SSL pour les composants WebView. Il est recommandé d'utiliser WKWebView avec les paramètres de sécurité par défaut au lieu de l'obsolète UIWebView. Supprimez toute utilisation des paramètres allowsAnyHTTPSCertificateForHost, loadingUnvalidatedHTTPSPage, ou allowsAnyHTTPSCertificate. Utilisez NSURLSession avec TLSMinimumSupportedProtocol = kTLSProtocol12 pour des communications réseau sécurisées.

OWASP :

  • A6:2017-Misconfiguration de Sécurité
  • A05:2021-Misconfiguration de Sécurité

html_django_rule_reflected_xss

Résumé :

Neutralisation incorrecte des entrées utilisateur rendues dans HTML ('XSS')

Gravité : Élevée

CWE : CWE-79

Description :

Le modèle HTML désactive l’échappement automatique HTML de Django en utilisant {% autoescape off %} ou {% autoescape None %}, ou contourne l’échappement pour des variables spécifiques en utilisant les filtres | safe ou | escapejs. Cela crée des vulnérabilités de Cross-Site Scripting (XSS) lorsque les données contrôlées par l'utilisateur sont rendues dans ces contextes non échappés. Le filtre | safe marque les chaînes comme HTML sûr qui ne seront pas échappées, tandis que | escapejs est conçu pour les contextes de chaînes JavaScript mais ne fournit pas de protection HTML. De plus, la règle détecte des variables de modèle non citées dans les attributs HTML comme {{ variable }} qui peuvent sortir du contexte d'attribut même avec l'échappement automatique activé. L’échappement automatique par défaut de Django protège contre le XSS, et ces motifs contournent cette protection critique.

Remédiation :

Envisagez de garder l'échappement automatique par défaut de Django activé en supprimant les blocs {% autoescape off %} ou en utilisant explicitement {% autoescape on %}. Évitez d'utiliser le filtre | safe sur des données fournies par l'utilisateur - réservez-le uniquement pour du HTML approuvé de votre code applicatif. Le filtre | escapejs est destiné aux contextes de chaînes JavaScript et ne doit pas être utilisé comme protection générale contre le XSS. Quotez toujours les variables de modèle dans les attributs HTML en utilisant des guillemets simples ou doubles comme <div class="{{ css_class }}"> pour prévenir les attaques de rupture d'attribut. Pour le contenu riche généré par les utilisateurs qui nécessite du HTML, utilisez un assainisseur basé sur une liste blanche comme bleach ou nh3 pour nettoyer le HTML avant de le marquer comme sûr. Mettez en œuvre des en-têtes de Politique de Sécurité du Contenu (CSP) dans vos paramètres Django comme protection en profondeur contre les attaques XSS même si l'échappement est accidentellement contourné.

OWASP :

  • A7:2017-Cross-Site Scripting (XSS)
  • A03:2021-Injection