FAQ

Foire aux questions

Informations générales

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.)
  • Tout fichier de script d'exécution déployé avec votre programme pouvant être analysé en vue de rechercher les vulnérabilités de sécurité, tels les 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).