Menu

SANS Top 20 des vulnérabilités de sécurité dans les applications logicielles

  • Principal
  • Autre
  • SANS Top 20 des vulnérabilités de sécurité dans les applications logicielles

sans top 20 security vulnerabilities software applications

Essayez Notre Instrument Pour Éliminer Les Problèmes

Apprenez et comprenez les 20 principales vulnérabilités de sécurité critiques de SANS dans les applications logicielles avec des exemples dans ce didacticiel:

Le mot SANS n'est pas simplement un mot ordinaire du dictionnaire, il représente SysAdmin , Audit , Réseau , et Sécurité .

Dans ce didacticiel, nous découvrirons les 20 principales faiblesses de sécurité de SANS que nous pouvons trouver dans les logiciels et ce que nous pouvons faire pour les atténuer.

Vulnérabilités de sécurité SANS

Ce que vous apprendrez:

Impact des SAN sur la communauté de cybersécurité

Selon SANS , le SANS L'Institut a été créé en tant qu'organisation de recherche et d'éducation. Ses différents programmes de sécurité sont très complets et ont un effet positif sur plus de 165 000 professionnels de la sécurité dans le monde.

Nous pouvons dire à juste titre qu'avec ce type de couverture provenant de SANS et d'autres critiques positives qu'ils obtiennent, ils sont l'organisation la plus fiable et de loin la plus grande pour la formation InfoSec et diverses certifications de sécurité au monde.

Cet article se concentrera sur les 20 principales erreurs SANS qui peuvent rendre votre logiciel vulnérable aux attaques et sur certains des contrôles de sécurité que vous pouvez mettre en œuvre pour atténuer ces erreurs. Bien que nous puissions en trouver plus de 20, mais nous discuterons des 20 principales vulnérabilités.

Liste des 20 principales vulnérabilités critiques du logiciel SANS

  1. CWE-119 : Erreur de mémoire tampon
  2. CWE-79 : Script intersite
  3. CWE-20 : Erreur d'entrée non validée
  4. CWE-200 : Erreur d'exposition aux informations sensibles
  5. CWE-125 : Erreur de lecture hors limites
  6. CWE-89 : Injection SQL
  7. CWE-416 : Erreur de mémoire libre
  8. CWE-190 : Erreur de dépassement d'entier
  9. CWE-352 : Falsification de requêtes intersites
  10. CWE-22 : Traversée d'annuaire
  11. CWE-78 : Injection de commande du système d'exploitation
  12. CWE-787 : Erreur d'écriture hors limites
  13. CWE-287 : Erreur d'authentification incorrecte
  14. CWE-476 : Déréférencement du pointeur NULL
  15. CWE-732 : Attribution d'autorisation incorrecte
  16. CWE-434 : Téléchargement de fichiers sans restriction
  17. CWE-611 : Exposition d'informations via des entités XML
  18. CWE-94 : Injection de code
  19. CWE-798 : Clé d'accès codée en dur
  20. CWE-400 : Consommation de ressources incontrôlée

Que signifie le terme CWE?

Le Énumération commune des faiblesses (CWE) est une liste acceptée par la communauté de vulnérabilités logicielles et matérielles avec un code d'identification attribué à chaque faiblesse. L'objectif est d'identifier diverses failles logicielles et matérielles afin de pouvoir corriger et atténuer toutes ces failles.

# 1) CWE-119: Erreur de mémoire tampon

Cette faille est généralement introduite lors des étapes d'architecture et de conception, de mise en œuvre et d'exploitation du SDLC.

Ce débordement de tampon se produit lorsqu'un processus d'application tente de stocker plus de données qu'il ne peut en contenir dans la mémoire. Étant donné que les tampons ne peuvent stocker qu'un certain niveau de données et lorsque ce niveau est atteint et dépassé, les données circulent vers un autre emplacement de mémoire, ce qui peut corrompre les données déjà contenues dans ce tampon.

Cet incident se produit parfois accidentellement à cause d'une erreur de programmation, mais les conséquences peuvent être désastreuses, car cela peut effacer des données, voler des informations confidentielles, et même toute l'application pourrait planter à cause de ce débordement de tampon.

L'exemple ci-dessous montre un tampon alloué avec 8 octets de stockage. Mais il a débordé de 2 octets car plus de données ont été envoyées pour exécution.

Erreur de mémoire tampon

(image la source )

# 2) CWE-79: Script intersite

Le Cross-site Scripting (XSS) est une attaque par injection qui se produit généralement lorsqu'un acteur malveillant ou un attaquant injecte un script malveillant ou nuisible dans une application Web qui peut être exécutée via les navigateurs Web. Une fois que le script malveillant trouve son chemin dans le système compromis, il peut être utilisé pour effectuer différentes activités malveillantes.

Certaines des activités malveillantes peuvent prendre la forme de transfert d’informations privées telles que les cookies contenant les informations de session de l’ordinateur de la victime vers l’ordinateur de l’attaquant.

Occurrence de script intersite:

  • Lorsque des données non validées et non fiables sont entrées dans une application Web via la demande de formulaire Web.
  • Lorsque l'application Web génère instantanément une page Web contenant ces données malveillantes.
  • Pendant le processus de génération d'une page, le logiciel ne parvient pas à valider par rapport aux données, qui hébergent le contenu qui peut être exécuté par un navigateur Web, comme HTML et JavaScript.
  • La victime visite à son insu la page qui a été générée via un navigateur Web, qui héberge le script malveillant qui a été injecté via l'utilisation de données non fiables.
  • Le script malveillant provient d'une page qui a été envoyée par le serveur Web de l'attaquant, le navigateur Web du système compromis poursuit alors le traitement du script malveillant.
  • Cette action enfreint la politique du navigateur Web concernant la même origine, qui stipule que les scripts provenant d'un domaine ne doivent pas avoir accès aux ressources ou exécuter du code dans un autre domaine, à l'exception de son propre domaine.

Occurrence de script intersite

(image la source )

# 3) CWE-20: Erreur d'entrée non validée

L'application reçoit l'entrée, mais ne parvient pas à valider l'entrée, si elle dispose de tous les détails nécessaires pour qu'elle soit acceptée dans le système pour traitement.

Lorsqu'il y a un nettoyage des entrées, cela peut être utilisé pour vérifier toutes les entrées potentiellement dangereuses afin de garantir que les entrées peuvent être traitées en toute sécurité avec le code source ou lorsqu'il s'agit d'une entrée nécessaire pour communiquer avec d'autres composants.

Lorsque ces entrées ne sont pas correctement nettoyées ou validées, cela ouvrira la voie à un attaquant pour envoyer une entrée malveillante que l'application principale traitera généreusement, ce qui entraînera des changements dans le flux de contrôle, un contrôle arbitraire d'une ressource ou du code arbitraire. exécution.

Les images ci-dessous montrent qu'une bonne application ne doit pas accepter de script ou de commande comme entrée. Si ces entrées ne sont pas correctement nettoyées, l'application la traitera en pensant qu'il s'agit d'une demande valide.

contribution

Erreur d

(image la source )

# 4) CWE-200: Erreur d'exposition aux informations sensibles

Cela se produit lorsque l'application expose sciemment et sans le savoir des informations confidentielles et sensibles à un attaquant qui n'a pas l'autorisation d'accéder à ces informations.

Différentes erreurs conduisent à exposer ces informations à un attaquant. La gravité de cette erreur varie en fonction du contexte dans lequel l'application fonctionne, du type d'informations sensibles révélées et de ce que l'acteur peut tirer des informations exposées.

Voici quelques informations sensibles qui pourraient être exposées:

  • Informations personnelles comme les messages personnels, les données financières, les dossiers sur l'état de santé, l'emplacement géographique ou les coordonnées
  • Détails de la configuration du système et environnement, par exemple, le système d'exploitation et les packages installés
  • Dossier commercial et propriété intellectuelle
  • Détails de la configuration du réseau
  • État de l'application interne
  • Métadonnées comme les en-têtes de message

Parfois, il peut y avoir des démangeaisons techniques telles qu'une erreur de connectivité de la base de données, une erreur d'exécution et une erreur réseau sur nos applications ou sites Web.

Si de telles erreurs ne sont pas correctement gérées pendant le développement, c'est-à-dire lorsque l'application affiche le message d'erreur, elle pourrait afficher des informations au public qu'un attaquant pourrait être en mesure d'utiliser à des fins malveillantes comme l'image ci-dessous.

erreur du serveur

# 5) CWE-125: Erreur de lecture hors limites

Cela se produit généralement lorsque l'application lit les données au-delà du niveau normal, soit jusqu'à la fin, soit avant le début de la mémoire tampon. Cela donne un accès non privilégié à un attaquant pour lire des informations sensibles à partir d'autres emplacements de mémoire, ce qui peut également entraîner un blocage du système ou de l'application.

Un plantage se produira certainement lorsque le code lit des données et pense qu'il y a un indicateur en place qui arrête l'opération de lecture comme un NULL appliqué à une chaîne

Dans le code suivant, la fonction récupère une valeur à partir d'un emplacement d'index de tableau, qui à son tour est le paramètre d'entrée de la fonction.

Erreur de lecture hors limites

(image la source )

À partir du code ci-dessus, nous pouvons voir que la fonction vérifie que l'index de tableau donné est inférieur à la longueur maximale du tableau, mais ne parvient pas à valider la valeur minimale.

Cette non-validation conduira à l'acceptation d'une valeur négative comme index de tableau d'entrée, provoquant une lecture hors limites, qui à son tour donne accès à la mémoire sensible.

Il est nécessaire de vérifier l'index du tableau d'entrée s'il se situe dans la plage maximale et minimale requise pour le tableau.

Si vous vérifiez maintenant l'exemple ci-dessous, vous verrez que l'instruction IF doit être modifiée pour inclure une validation de plage minimale.

validation de la plage minimale

# 6) CWE-89: injection SQL

Injection SQL est une forme de vulnérabilité de sécurité par laquelle l'attaquant injecte un code SQL (Structured Query Language) dans la zone de saisie Webform afin d'accéder à des ressources ou de modifier des données auxquelles l'accès n'est pas autorisé.

Cette vulnérabilité peut être introduite dans l'application au cours des étapes de conception, de mise en œuvre et d'exploitation.

Ce que fait cette requête SQL est de faire une demande non autorisée à la base de données pour certaines informations. Dans une opération de saisie normale, un formulaire Web est utilisé pour l'authentification de l'utilisateur. Lorsqu'un utilisateur entre son nom et son mot de passe dans les zones de texte, ces valeurs sont insérées dans une requête SELECT.

qu'est-ce que le test de la boîte noire avec l'exemple

Si les valeurs d'entrée sont correctes, l'utilisateur a accès à l'application ou à la demande, mais si les valeurs sont incorrectes, l'accès sera refusé.

Aujourd'hui, certains formulaires Web ne disposent pas de mécanismes pour bloquer les entrées malveillantes. Un attaquant peut utiliser les zones de saisie pour envoyer des requêtes malveillantes à la base de données. Cette requête unique peut leur donner accès à l'ensemble de la base de données pouvant contenir des informations sensibles.

SQLinjection

# 7) CWE-416: Mémoire précédemment libérée

Ce problème est causé par le référencement de la mémoire après sa libération, ce qui peut sérieusement entraîner un blocage du programme. Lorsque vous utilisez une mémoire précédemment libérée, cela peut avoir des conséquences néfastes, telles que la corruption de données valides, l'exécution de code arbitraire qui dépend du moment de la faille.

Deux causes courantes sont:

  • Conditions d'erreur dans le logiciel et dans certains autres cas exceptionnels.
  • Aucune explication quant à la partie du programme qui a causé la mémoire libre.

Dans ce cas, la mémoire est allouée à un autre pointeur immédiatement après sa libération. Le pointeur précédent vers la mémoire libérée est à nouveau utilisé et pointe maintenant vers quelque part autour de la nouvelle allocation. Au moment où les données sont modifiées, cela peut corrompre la mémoire utilisée et faire en sorte que l'application se comporte d'une manière non définie.

# 8) CWE-190: Erreur de dépassement d'entier

Lorsqu'un calcul est traité par une application et qu'il existe une hypothèse logique selon laquelle la valeur résultante sera supérieure à la valeur exacte, un débordement d'entier se produit. Ici, une valeur entière augmente jusqu'à une valeur qui ne peut pas être stockée dans un emplacement.

Lorsque cela se produit, la valeur sera généralement enveloppée pour devenir une valeur très petite ou négative. Si l’emballage est attendu, tout va bien, mais il peut y avoir des conséquences sur la sécurité si l’emballage est inattendu. Lorsque ce scénario se produit, il peut être qualifié de critique car le résultat est utilisé pour gérer le bouclage, la décision de sécurité, l'allocation de mémoire et bien d'autres.

Cette faiblesse conduira généralement à un comportement erratique et peut conduire à des plantages. Si la valeur est importante pour les données plutôt que pour le flux, une simple corruption des données peut se produire. Mais si le bouclage conduit à d'autres conditions telles que des débordements de tampon, une corruption de mémoire peut se produire.

Ce problème peut déclencher des dépassements de tampon, qui peuvent être utilisés pour exécuter du code arbitraire par un attaquant. Cette erreur de dépassement d'entier est généralement introduite dans le système pendant les étapes de conception et de mise en œuvre du SDLC.

IntegerOverflow

# 9) CWE-352: Falsification de requêtes intersites

C'est lorsqu'une application Web ne vérifie pas suffisamment la requête HTTP, que la requête provienne ou non du bon utilisateur. Les serveurs Web sont conçus pour accepter toutes les demandes et y répondre.

Supposons qu’un client envoie plusieurs requêtes HTTP au cours d’une ou plusieurs sessions. Il est très difficile pour un serveur Web de savoir si toutes les demandes étaient authentiques ou non, et elles sont généralement traitées. Un attaquant peut avoir sa manière de forcer un client à visiter une page Web spécialement conçue et maintenant être en mesure d'exécuter certaines requêtes comme le transfert de fonds, la modification de son adresse e-mail, et bien d'autres.

Immédiatement, un attaquant a accès et il pourra voler des données et même détruire des données. Ils peuvent toujours conserver leur accès et, lorsqu'ils ont terminé, peuvent compromettre le journal d'audit pour empêcher toute analyse légale future qui pourrait exposer leur exploit.

L'image ci-dessous montre un attaquant incitant un utilisateur à effectuer des actions qu'il n'a pas l'intention d'effectuer.

CrossSite

# 10) CWE-22: Traversée d'annuaire

La traversée de répertoire ou de chemin de fichier est une vulnérabilité de sécurité Web qui permet à un attaquant de lire des fichiers arbitraires sur le serveur qui exécute actuellement une application.

Ces fichiers peuvent être un code d'application, des informations d'identification pour les systèmes back-end et les fichiers du système d'exploitation. Dans un autre scénario, un attaquant pourrait être en mesure d'écrire dans ces fichiers arbitraires sur le serveur, ce qui pourrait leur permettre de modifier les données ou le comportement de l'application, ce qui leur donnera un contrôle total sur le serveur.

le meilleur téléchargeur vidéo gratuit sur youtube

Traversée

(image la source )

# 11) CWE-78: Injection de commande du système d'exploitation

Il s'agit de la désinfection incorrecte d'éléments spéciaux qui peuvent conduire à la modification de la commande du système d'exploitation prévue qui est envoyée à un composant en aval. Un attaquant peut exécuter ces commandes malveillantes sur un système d'exploitation cible et accéder à un environnement dans lequel il n'était pas censé lire ou modifier.

Cela permettrait invariablement à un attaquant d'exécuter des commandes dangereuses directement dans le système d'exploitation.

Chaque fois que cette vulnérabilité survient dans un programme privilégié, elle permet à l'attaquant d'utiliser des commandes qui sont autorisées dans l'environnement ou d'appeler d'autres commandes avec des privilèges que l'attaquant n'a pas, ce qui pourrait augmenter la quantité de dommages qui pourraient survenir.

CommandInjection

# 12) CWE-787: Erreur d'écriture hors limites

Cela se produit lorsque l'application écrit des données après la fin ou avant le début de la mémoire tampon désignée.

Lorsque cela se produit, le résultat final est généralement une corruption de données, un blocage du système ou de l'application. Ce que fait l'application est une sorte d'arithmétique de pointeur qui est utilisée pour référencer un emplacement mémoire en dehors des limites de la mémoire tampon.

# 13) CWE-287: Erreur d'authentification incorrecte

C'est quand un attaquant prétend avoir une identité valide mais que le logiciel n'a pas réussi à vérifier ou prouve que la réclamation est correcte.

Un logiciel valide les informations de connexion d'un utilisateur de manière incorrecte et, par conséquent, un attaquant pourrait obtenir certains privilèges au sein de l'application ou divulguer des informations sensibles qui lui permettent d'accéder à des données sensibles et d'exécuter du code arbitraire.

# 14) CWE-476: Déréférencer un pointeur NULL

Le déréférencement d'un pointeur nul se produit lorsque l'application déréférence un pointeur censé renvoyer un résultat valide à la place renvoie NULL, ce qui entraîne un blocage. Le déréférencement d'un pointeur nul peut se produire à travers de nombreuses failles telles que des conditions de concurrence et des erreurs de programmation.

Les processus exécutés à l'aide du pointeur NULL entraînent généralement un échec et la possibilité d'exécuter le processus est très mince. Cela aide les attaquants à exécuter du code malveillant.

Pointeur nul

(image la source )

# 15) CWE-732: Attribution d'autorisation incorrecte

Cette vulnérabilité se produit lorsqu'une application attribue des autorisations à une ressource très importante et critique de manière à exposer la ressource à un utilisateur malveillant.

Lorsque vous donnez à de nombreuses personnes l'autorisation d'accéder à une ressource, cela peut entraîner la divulgation ou la modification d'informations sensibles par un attaquant. S'il n'y a pas de vérification en place contre ce type d'approche d'attribution des autorisations aux ressources, cela peut conduire à une fin très désastreuse si une configuration de programme ou certaines données sensibles tombent entre de mauvaises mains.

# 16) CWE-434: Téléchargement de fichiers sans restriction

Cette vulnérabilité se produit lorsque l'application ne valide pas les types de fichiers avant de télécharger des fichiers vers l'application. Cette vulnérabilité est indépendante du langage mais se produit généralement dans les applications écrites en langage ASP et PHP.

Un type de fichier dangereux est un fichier qui peut être traité automatiquement dans l'environnement d'application.

Le programme suivant montre un téléchargement d'un fichier PHP. Le type de fichier n'a pas été vérifié et validé avant le téléchargement dans le répertoire webroot. En raison de cette faiblesse, un attaquant peut télécharger un fichier PHP arbitraire et l'exécuter en accédant directement au fichier téléchargé.

téléchargement d

fichier PHP arbitraire

# 17) CWE-611: Exposition d'informations via des entités XML

Lorsqu'un document XML est téléchargé dans une application pour traitement et que ce document contient des entités XML avec un identificateur de ressource uniforme qui se résout en un autre document dans un autre emplacement différent de l'emplacement prévu. Cette anomalie peut amener l'application à joindre des documents incorrects dans sa sortie.

Les documents XML contiennent parfois une définition de type de document (DTD), qui est utilisée pour définir les entités XML et d'autres fonctionnalités. Grâce à la DTD, l'identificateur de ressource uniforme peut servir de chaîne de substitution. Ce que l'analyseur XML fera est d'accéder à ce qui est contenu dans l'identificateur de ressource uniforme et de rentrer ce contenu dans le document XML pour exécution.

InfoExposition

(image la source )

# 18) CWE-94: Injection de code

L’existence d’une syntaxe de code dans les données de l’utilisateur augmente la possibilité pour l’attaquant de modifier le comportement de contrôle planifié et d’exécuter du code arbitraire. Cette vulnérabilité est appelée «faiblesses d'injection» et cette faiblesse pourrait faire qu'un contrôle de données devienne contrôlé par l'utilisateur.

Cette vulnérabilité décrit un scénario dans lequel le logiciel autorise des données non fiables dans le code et n'effectue pas de validation des caractères spéciaux qui peuvent influencer négativement à la fois le comportement du segment de code et la syntaxe.

En bref, un attaquant serait en mesure d'injecter une sorte de code arbitraire et de les exécuter dans l'application. Le code PHP suivant montre l'utilisation de la fonction eval () dans des données non fiables. Dans le code ci-dessous un attaquant est capable de passer dans le code le code arbitraire du paramètre «param» qui sera ensuite exécuté dans le logiciel.

Injection de code

L'exemple ci-dessous explique l'appel au phpinfo () fonction. Cette vulnérabilité peut en outre être exploitée dans d'autres pour exécuter des commandes OS arbitraires sur le logiciel cible via l'appel system ().

appel à la fonction phpinfo ()

# 19) CWE-798: Clé d'accès codée en dur

C'est lorsque le mot de passe et la clé d'accès sont codés en dur dans l'application directement à des fins d'authentification entrante et de communication sortante vers certains composants externes et pour le cryptage des données internes. Les informations de connexion codées en dur provoquent généralement une vulnérabilité qui ouvre la voie à un attaquant pour contourner l'authentification qui a été configurée par l'administrateur du logiciel.

L'administrateur système aura toujours beaucoup de mal à détecter cette vulnérabilité et à la corriger.

Il y a deux courants principaux à cette faiblesse:

  • Entrant : L'application contient un système d'authentification qui valide les informations d'identification d'entrée par rapport aux détails codés en dur.
  • Sortant : L'application se connecte à un autre système et les détails de connexion à l'autre système sont codés en dur dans le système.

Dans le flux entrant, un compte d'administrateur par défaut est toujours créé et les informations d'identification pour y accéder seront codées en dur dans l'application et associées à ce compte d'administrateur par défaut.

Les détails codés en dur sont généralement la même chose à travers chaque installation de l'application, et cela ne peut être modifié ou désactivé par personne. Même les administrateurs système n'ont pas le droit, sauf qu'ils peuvent modifier manuellement l'application. Si le mot de passe est divulgué au public, un attaquant peut avoir accès à l'ensemble de l'application et peut la manipuler à son propre profit.

Étant donné que toutes les installations de l'application ont le même mot de passe, même lorsqu'elles sont installées dans des organisations distinctes, cela peut provoquer des attaques très massives à travers toutes les frontières de l'organisation, par exemple, injecter un ver dans l'application qui se répandra.

Le flux sortant s'applique uniquement aux systèmes frontaux qui s'authentifient avec un service principal. Le service back-end peut nécessiter un code en dur ou un mot de passe fixe qui peut être facilement découvert. Ce que le programmeur fait est simplement de coder en dur ces informations d'identification back-end dans le logiciel frontal. Tout utilisateur de cette application peut être en mesure d'extraire le mot de passe.

Tout logiciel côté client dans lequel le mot de passe et la clé d'accès sont codés en dur représente généralement plus de menaces que ceux qui ne le sont pas, car l'extraction d'un mot de passe à partir d'un binaire est généralement très facile à réaliser.

# 20) CWE-400: Consommation de ressources incontrôlée

Cette vulnérabilité survient lorsque l'application ne contrôle pas correctement l'allocation et la maintenance d'une ressource limitée, cela permet à un attaquant de pouvoir influencer la quantité de ressources consommée, ce qui conduira à terme à l'épuisement des ressources disponibles.

Une partie des ressources limitées comprend la mémoire, le stockage du système de fichiers, les entrées du pool de connexion à la base de données et le processeur.

Supposons qu'un attaquant puisse déclencher l'allocation de ces ressources limitées et que le nombre ou la taille des ressources ne soit pas contrôlé, alors l'attaquant pourrait provoquer le chaos par déni de service qui consomme toutes les ressources disponibles.

Lorsque cela se produit, cela empêcherait les utilisateurs valides d'accéder à l'application, ce qui aura invariablement un impact négatif sur l'environnement. Par exemple, lorsque la mémoire de l'application subit une attaque d'épuisement, cela peut ralentir l'ensemble de l'application ainsi que le système d'exploitation hôte.

Les trois instances différentes qui peuvent conduire à l'épuisement des ressources sont:

  • Manque de limitation pour le nombre de ressources allouées
  • Perte de toutes les références à une ressource avant d'atteindre l'étape d'arrêt
  • Échec de la fermeture / du retour d'une ressource après le traitement

Le problème de l'épuisement des ressources résulte généralement d'une implémentation incorrecte des scénarios suivants:

  • Conditions d'erreur et autres circonstances exceptionnelles.
  • Il y a des réactions mitigées sur la partie du programme qui libère la ressource.

L'exemple suivant aide à démontrer la nature de cette vulnérabilité et à décrire les méthodes qui peuvent être utilisées pour atténuer le risque.

L'exemple suivant explique la vulnérabilité:

Consommation de ressources incontrôlée

(image la source )

Ce programme ne suit pas le nombre de connexions établies et ne limite pas le nombre de connexions disponibles. Le fork n'est que l'un des moyens utilisés par un attaquant pour amener le système à manquer de CPU, de processus ou de mémoire en établissant un grand nombre de connexions.

Ce que fait un attaquant, c'est de consommer toutes les connexions disponibles, empêchant les autres d'accéder au système à distance.

Questions fréquemment posées

Q # 1) Que signifie SANS?

Répondre: SANS signifie SysAdmin, Audit, Network et Security.

Q # 2) Demandez quelques exemples de vulnérabilités.

Réponse: Les exemples sont les suivants:

  • Vulnérabilités logicielles
  • Vulnérabilités du pare-feu
  • Vulnérabilités du réseau
  • Vulnérabilités du système d'exploitation
  • Vulnérabilités du serveur Web
  • Vulnérabilités de la base de données

Q # 3) Quelle est la différence entre les menaces et les vulnérabilités?

Répondre: Menace est la possibilité de commettre un acte malveillant ou indésirable dans une tentative d'endommager un système informatique ou une application par des vulnérabilités existantes dans le système. Exemple: ransomware.

Vulnérabilités sont des faiblesses qui existent dans un système et qui auraient pu permettre à un attaquant d'accéder non désirés ou non autorisés à infiltrer des dommages à une organisation. Exemple: Mauvaise configuration du pare-feu.

Q # 4) Quelles sont les vulnérabilités les plus courantes?

Réponse: Ce sont les suivants:

  • Injection SQL
  • Script intersite
  • Mauvaise configuration de la sécurité
  • Exposition des données sensibles
  • Authentification cassée
  • Gestion de session

Conclusion

Cette liste des 20 principales vulnérabilités SANS n'est pas une règle ou une politique, mais un guide pour nous aider à éviter les vulnérabilités logicielles. Que nous soyons développeur ou expert en sécurité, il nous appartient désormais de suivre ce guide sur ce qui peut être fait pour éviter toute erreur pouvant conduire à des vulnérabilités dans notre application pouvant créer une porte dérobée permettant à un acteur d'exécuter un acte malveillant.

lecture recommandée

^