FAQ

Foire aux questions

Informations générales

Quelles sont les plateformes Kubernetes prises en charge par AppScan 360°?

AppScan 360° n'utilise aucune fonctionnalité spécifique à la plateforme et doit fonctionner sur toutes les plateformes, mais toutes ne sont pas vérifiées pour fonctionner. AppScan 360°est vérifié pour fonctionner sur les plateformes Kubernetes suivantes :

  • K0s
  • K3s
  • K8s
  • OpenShift
  • VMware
  • Tanzu

Si vous disposez de mesures de sécurité supplémentaires, vous devrez peut-être effectuer des vérifications et des modifications supplémentaires dans la configuration. Par exemple, OpenShift nécessite certaines conditions préalables pour fonctionner avec AppScan 360°. Pour plus d'informations, reportez-vous à la section Quelles sont les conditions préalables à l'utilisation d'OpenShift avec AppScan 360°?

Qu'est-ce que Harbor et comment l'utiliser ?

HCL Harbor est le registre de conteneurs de HCL Software. Depuis Harbor, vous pouvez télécharger des images Docker (un modèle en lecture seule contenant le code d'application, les bibliothèques, les outils et les dépendances nécessaires à l'exécution d'AppScan 360°) et des graphiques Helm (packages de ressources Kubernetes préconfigurées qui simplifient le déploiement et la gestion d'AppScan 360° dans un cluster Kubernetes).

Pour vous connecter à HCL Harbor :
  1. Accédez à https://hclcr.io.
  2. Cliquez sur CONNEXION VIA UN FOURNISSEUR OIDC.
  3. Connectez-vous à l'aide de vos informations d'identification HCL.
  4. Sélectionnez Projets > AppScan 360°.

    L'onglet Référentiels contient les dernières images Docker et cartes Helm pour AppScan 360° à télécharger.

Si vous utilisez Kubernetes, vous devrez peut-être ajouter un secret CLI à votre configuration Kubernetes. Exécutez l'une des opérations suivantes :
  • Utilisez docker login hclcr.io avec votre nom d'utilisateur et votre mot de passe.
  • Définissez les variables d'environnement pour le fichier docker/config.json :
    export HCLCR_USERNAME= 
    export HCLCR_PASSWORD=
  • Définissez une variable d'environnement pour le codage base64 :
    export AS360_KNI_JSON_CONFIG_AS_BASE64=""
Contactez l'assistance HCL si vous rencontrez des problèmes de connexion.

Où se trouve le référentiel Helm d'AppScan 360° ?

Le référentiel Helm d'AppScan 360° est hébergé sur un serveur GitHub public à l'adresse https://github.com/HCL-TECH-SOFTWARE. Vous pouvez cloner le référentiel approprié à partir de cet emplacement.

Pourquoi mon examen a-t-il échoué ?

Raisons possibles justifiant l'échec ou l'analyse de votre examen :
  • Fichier d'application non valide
  • La stratégie de test que vous avez sélectionnée n'est pas adaptée à votre site/application
  • La Plateforme centrale AppScan ne fonctionne pas correctement ou pas du tout

Si vous parvenez à éviter ces problèmes, votre examen s'effectuera probablement automatiquement et rapidement. Il est particulièrement important si vous intégrez l'examen AppScan 360° dans un processus automatisé. La durée de l'examen sera donc aussi courte que possible.

Combien de temps dure un examen ?

Selon la complexité et la taille d'une application, la durée peut être de quelques minutes, mais elle peut être beaucoup plus longue. Vous pouvez choisir de recevoir un e-mail lorsque l'examen est terminé.

Quels sont les problèmes de sécurité que AppScan 360° recherche ?

  • AppDOS
  • Informations sensibles de mise en cache du navigateur
  • Commentaires révélant des informations sensibles
  • Problème de configuration
  • Attaque par script intersite (XSS)
  • Manipulation de chaîne de connexion de base de données
  • Hameçonnage d'e-mail
  • Falsification d'e-mail
  • Codage requis
  • Service Web exposé
  • Falsification de fichier
  • Téléchargement de fichier
  • Fractionnement de demande HTTP
  • Fractionnement de réponse HTTP
  • Injection LDAP
  • Redirection ouverte
  • Injection de commandes du système d'exploitation
  • Problème de logique professionnelle potentielle de la traversée de répertoires (couvre aussi la référence non sécurisée à un objet direct)
  • Escalade des droits d'accès
  • Injection de RegEx
  • Supprimer le code de test
  • Injection de second ordre
  • Exposition des données sensibles
  • Données sensibles stockées dans des journaux
  • Informations sensibles révélées dans un message d'erreur
  • Valeur de délai de gestion de la session trop long
  • Injection SQL
  • Communications non chiffrées
  • Falsification d'URL
  • Utilisation d'un générateur de chiffre aléatoire non sécurisé au niveau cryptographique
  • Utilisation de zones masquées
  • Utilisation d'un algorithme de cryptographie non sécurisé
  • Utilisation de code natif non sécurisé
  • Contrôle d'accès faible
  • Authentification faible
  • Injection XML
  • Injection XPath
  • Injection XSLT

Pourquoi l'évaluation des risques de mon application est-elle « Inconnue » ?

L'évaluation des risques est calculée pour une application en fonction de deux facteurs :
  • Problèmes trouvés (par AppScan 360°)
  • Impact sur l'activité (affecté par l'utilisateur)
Si aucun problème n'a encore été trouvé ou si l'impact sur l'activité est « Non spécifié » (valeur par défaut), l'évaluation des risques sera « Inconnue ». Pour modifier l'impact sur l'activité, voir Evaluation des risques.

DAST

Pourquoi ne puis-je plus indiquer que l'environnement doit être Transfert ou Production ?

Jusqu'à récemment, la configuration des examens DAST comprenait un choix d'environnements de transfert ou de production. L'objectif était de réduire le risque d'impact de l'examen sur la stabilité de votre site. Ce paramètre a été supprimé, car les nouvelles options de configuration désormais disponibles dans l'assistant l'ont rendu redondant. Si vous examinez un site de production, vous pouvez envisager plutôt d'apporter les modifications suivantes à la configuration :
  • Dans Explorer > Remplissage automatique de formulaires, désélectionnez la case pour désactiver cette option.
  • Dans Communication > Taux de requête maximal, la valeur par défaut doit être acceptable pour la plupart des sites de production, mais vous pouvez envisager de réduire le nombre maximal de requêtes autorisées par seconde pour réduire le trafic vers votre site.

Pour plus de détails et de suggestions, reportez-vous à la section suivante.

Quelles modifications dois-je apporter lors de l'examen d'un site de production opérationnel ?

Dans la mesure du possible, il est recommandé d'exécuter les examens DAST sur des sites de transfert plutôt que sur des sites de production. L'exécution d'un examen DAST sur un site de production opérationnel peut avoir un impact sur la stabilité du site. Le cas échéant, les points suivants peuvent vous aider à configurer efficacement votre examen de site de production.

Il se peut que la base de données soit remplie d'informations inutiles envoyées pendant l'examen.

Vous pouvez en réduire l'impact en prenant les précautions suivantes :
  1. Dans Explorer > Remplissage automatique de formulaires, désélectionnez la case.

    Ceci empêche AppScan 360° de remplir les formulaires automatiquement en soumettant des données pouvant saturer une base de données, un tableau d'affichage ou un forum en ligne, ou en envoyant des courriers électroniques indésirables à un compte d'administrateur ou de modérateur. Sachez cependant que cette action neutralise la capacité d'AppScan 360° Standard à atteindre des zones du site accessibles via une soumission de formulaires. Dans ce mode de fonctionnement, AppScan 360° examine uniquement les zones du site accessibles en suivant des liens (avec ou sans paramètres).

  2. Dans Communication > Taux de requête maximal, pensez à réduire le nombre maximal de requêtes autorisées par seconde.
  3. Créez un compte de test.
    L'utilisation d'un compte de test facilite le suivi des modifications de la base de données (par exemple, pour s'assurer que des services ne sont pas commandés), ainsi que le nettoyage du site par les administrateurs une fois l'examen terminé. Lors de la création du compte, envisagez d'effectuer tout ou partie des actions suivantes :
    • Limiter l'accès à la base de données aux seuls enregistrements de test, de sorte que les enregistrements modifiés puissent être restaurés.
    • Vérifier que les nouveaux enregistrements créés par le compte de test seront supprimés.
    • Vérifier que les bons de commande (ou autres transactions) issus du compte de test seront ignorés.
    • Donner l'accès au compte pour les enregistrements de test uniquement si les transactions ont un impact (par exemple, s'il s'agit d'actions).
    • Donner l'accès au compte de test uniquement pour tester les forums, si le site comporte des forums, afin que les clients réels ne voient pas les tests créés pendant l'étape de test.
    • Si le site dispose de différents privilèges pour différents comptes, créez plusieurs comptes de test, avec différents privilèges. Ceci garantit un examen plus exhaustif du site.
    • Ne pas créer de compte de test avec un accès de niveau administrateur.

Risque de saturation de la messagerie électronique

Lorsqu'il teste des pages utilisant la notification par courrier électronique, AppScan 360° génère un grand nombre de requêtes, ce qui peut surcharger le serveur de messagerie du site. Si vous le pouvez, modifiez temporairement les adresses e-mail pour les pages testées afin d'envoyer les e-mails vers des adresses non valides.

Optimisation des tests : Si son examen est plus rapide, pourquoi ne puis-je pas l'utiliser ?

L'option Optimisation du test est parfaite lorsque vous avez besoin de résultats plus rapides, mais elle n'est pas aussi approfondie qu'un examen non optimisé. Nous vous recommandons les examens optimisés lorsque la vitesse est importante, mais que vous pouvez également les consolider avec des examens complets à intervalles réguliers.

Optimisation des tests : Puis-je m'attendre à ce que les résultats de deux examens optimisés effectués sur le même site soient identiques ?

Puisque notre équipe analyse et met à jour constamment les paramètres, chaque mise à jour d'AppScan a amélioré les paramètres d'optimisation. Par conséquent, même si le site reste inchangé, les résultats peuvent ne pas être identiques. Néanmoins, il est peu probable qu'un test qui a décelé un problème dans l'ancien examen soit exclu du nouvel examen avec le même niveau d'optimisation.

OTP : Comment identifier le paramètre HTTP OTP ?

Pour les examens DAST de sites qui utilisent l'OTP (mot de passe unique), AppScan doit connaître le nom du paramètre qui contient l'OTP (afin de pouvoir se connecter à l'application) et l'identifie généralement lors de la validation de la connexion enregistrée. S'il n'y parvient pas, ou si vous utilisez la connexion automatique (plutôt que la connexion enregistrée), vous devez ajouter le paramètre vous-même.

Pour identifier le paramètre :
  1. Accédez à la page de connexion de l'application.
  2. Cliquez sur F12 pour ouvrir le volet des outils de développement du navigateur (s'ouvre à droite ou au-dessous du volet principal du navigateur).
  3. Cliquez sur l'onglet Eléments pour afficher le code HTML.

    Lorsque vous sélectionnez une partie du code, l'élément est mis en évidence dans le volet principal du navigateur.

  4. Localisez l'élément qui met en évidence le champ OTP.
    Exemple :
    <input type="text" name="OTPvalue" value="">
  5. La valeur du paramètre name, sans guillemets, est le paramètre HTTP OTP dont vous avez besoin.
    Exemple :
    OTPvalue
  6. S'il existe plusieurs paramètres HTTP OTP, séparez-les par des virgules.

Quels protocoles sont pris en charge pour les examens DAST ?

AppScan 360° peut examiner des applications qui nécessitent TLS 1.0, 1.1 et 1.3.

Quel protocole TLS AppScan 360° prend-il en charge pour la connexion au service AppScan 360° ?

AppScan 360° prend en charge TLS 1.2 pour la connexion au service.

Pourquoi le nombre de problèmes de gravité moyenne a-t-il augmenté lors de mon nouvel examen ?

Lors de la nouvelle exécution d'un examen qui a été exécuté à l'origine à l'aide d'une version du moteur DAST antérieure à la version v10.2.0, les problèmes de gravité moyenne sont plus nombreux dans le nouvel examen par rapport à l'examen d'origine.

A partir de la version 10.2.0 du moteur DAST AppScan, la gravité du problème CWE et le score CVSS sont basés sur la version CVSS 3.1. Les examens s'exécutent à l'aide d'anciennes versions du moteur DAST qui utilisaient le score CVSS 2.0. Certains problèmes qui recevaient un niveau de gravité faible dans l'ancienne version ont reçu un niveau de gravité moyenne dans la version 10.2.0, ce qui a entraîné une augmentation des problèmes de gravité moyenne. Ce problème sera résolu dans une version future du moteur DAST.

SAST

Qu'est-ce qu'un fichier IRX d'analyse statique et que contient-il ?

IRX est un fichier zip chiffré contenant les informations nécessaires à l'exécution d'une analyse statique complète de votre programme. Il est chiffré au repos dès la création, ainsi que lors du transport vers le cloud (sur SSL).

En interne, une archive IRX contient les fichiers et artefacts suivants :

  • Une représentation propriétaire et masquée de vos artefacts de programme déployables, conçue à partir de votre code source déployé (par exemple bytecode Java ou .Net MSIL). (Pour savoir quels langages sont pris en charge pour les examens d'analyse statique, voir Configuration requise par le système pour l'analyse statique.)
  • Tous les fichiers de script d'exécution déployés avec votre programme qui peuvent être analysés pour détecter des vulnérabilités de sécurité (par exemple des fichiers .js (Javascript) ou .rb (Ruby)).
  • Fichiers de configuration Static Analyzer qui décrivent la hiérarchie de l'application ou du projet ainsi que les relations ou dépendances de votre programme. Cela permet de réaliser une analyse de sécurité précise et complète à travers les limites du projet au sein de votre application.
  • Fichiers journaux Static Analyzer générés lors de la création de l'archive (pour les diagnostics et le support).