Questa traduzione è incompleta. Collabora alla traduzione di questo articolo dall’originale in lingua inglese.

This page is not complete.

Questo articolo tratta le vulnerabilità, spiegando cosa sono e come si presentano in tutti i sistemi.

Prerequisiti: Devi prima conoscere i principali obiettivi della sicurezza.
Obiettivo: Imparerai che cos'è una vulnerabilità e come possono colpire dati e sitemi.


Una vulnerabilità è una debolezza in un sistema che più essere sfruttata per compromettere riservatezza, integrità e/o disponibilità. Le vulnerabilità possono essere catalogate in molti modi diversi. Questo articolo usa tre categorie di vulnerabilità di alto-livello: difetto software, problemi di configurazione di sicurezza e cattivo impiego di funzioni software. Tali categorie vengono descritte di seguito.

Apprendimento Attivo

Non sono ancora presenti attività di apprendimento attivo. Prendi in considerazione di contribuire, per favore.


Categorie di Vulnerabilità

Una vulnerabilità di difetto software è causata da un errore non voluto in fase di progettazione o di programmazione del software. Un esempio può essere un errore nell'inserimento condizionato, come un input a disposizione dell'utente che non viene opportunamente controllato per stringhe di caratteri malevole e per volori troppo lunghi associati ad attacchi noti. Un altro esempio è un errore su una condizione di esecuzione che permette all'aggressore di eseguire un'azione specifica con privilegi elevati.

Una configurazione di sicurezza è un elemento di sicurezza del software che può essere modificata tramite lo stesso software. Esempi di configurazioni sono un sistema operativo che offre l'accesso alle liste di controllo che impostano i privilegi che gli utenti hanno sui file, e una applicazione offre un'impostazione per abilitare o disabilitare la codifica di dati sensibili salvati dall'applicazione stessa. Una vulnerabilità di configurazione di sicurezza include una uso di tali configurazioni che interessa negativamente la sicurezza del software.

A software feature is a functional capability provided by software. A software feature misuse vulnerability is a vulnerability in which the feature also provides an avenue to compromise the security of a system. These vulnerabilities are caused by the software designer making trust assumptions that permit the software to provide beneficial features, while also introducing the possibility of someone violating the trust assumptions to compromise security. For example, email client software may contain a feature that renders HTML content in email messages. An attacker could craft a fraudulent email message that contains hyperlinks that, when rendered in HTML, appear to the recipient to be benign but actually take the recipient to a malicious web site when they are clicked on. One of the trust assumptions in the design of the HTML content rendering feature was that users would not receive malicious hyperlinks and click on them.

Software feature misuse vulnerabilities are introduced during the design of the software or a component of the software (e.g., a protocol that the software implements). Trust assumptions may have been explicit—for example, a designer being aware of a security weakness and determining that a separate security control would compensate for it. However, trust assumptions are often implicit, such as creating a feature without first evaluating the risks it would introduce. Threats may also change over the lifetime of software or a protocol used in software. For example, the Address Resolution Protocol (ARP) trusts that an ARP reply contains the correct mapping between Media Access Control (MAC) and Internet Protocol (IP) addresses. The ARP cache uses that information to provide a useful service—to enable sending data between devices within a local network. However, an attacker could generate false ARP messages to poison a system’s ARP table and thereby launch a denial-of-service or a man-in-the-middle attack. The ARP protocol was standardized over 25 years ago, and threats have changed a great deal since then, so the trust assumptions inherent in its design then are unlikely to still be reasonable today.

It may be hard to differentiate software feature misuse vulnerabilities from the other two categories. For example, both software flaws and misuse vulnerabilities may be caused by deficiencies in software design processes. However, software flaws are purely negative—they provide no positive benefit to security or functionality—while software feature misuse vulnerabilities occur as a result of providing additional features.

There may also be confusion regarding misuse vulnerabilities for features that can be enabled or disabled—in a way, configured—versus security configuration issues. The key difference is that for a misuse vulnerability, the configuration setting enables or disables the entire feature and does not specifically alter just its security; for a security configuration issue vulnerability, the configuration setting alters only the software’s security. For example, a setting that disables all use of HTML in emails has a significant impact on both security and functionality, so a vulnerability related to this setting would be a misuse vulnerability. A setting that disables the use of an antiphishing feature in an email client has a significant impact on only security, so a vulnerability with that setting would be considered a security configuration issue vulnerability.

The Presence of Vulnerabilities

No system is 100% secure: every system has vulnerabilities. At any given time, a system may not have any known software flaws, but security configuration issues and software feature misuse vulnerabilities are always present. Misuse vulnerabilities are inherent in software features because each feature must be based on trust assumptions—and those assumptions can be broken, albeit involving significant cost and effort in some cases. Security configuration issues are also unavoidable for two reasons. First, many configuration settings increase security at the expense of reducing functionality, so using the most secure settings could make the software useless or unusable. Second, many security settings have both positive and negative consequences for security. An example is the number of consecutive failed authentication attempts to permit before locking out a user account. Setting this to 1 would be the most secure setting against password guessing attacks, but it would also cause legitimate users to be locked out after mistyping a password once, and it would also permit attackers to perform denial-of-service attacks against users more easily by generating a single failed login attempt for each user account.

Because of the number of vulnerabilities inherent in security configuration settings and software feature misuse possibilities, plus the number of software flaw vulnerabilities on a system at any given time, there may be dozens or hundreds of vulnerabilities on a single system. These vulnerabilities are likely to have a wide variety of characteristics. Some will be very easy to exploit, while others will only be exploitable under a combination of highly unlikely conditions. One vulnerability might provide root-level access to a system, while another vulnerability might only permit read access to an insignificant file. Ultimately, organizations need to know how difficult it is for someone to exploit each vulnerability and, if a vulnerability is exploited, what the possible impact would be.

Original Document Information

  • Author(s): Elizabeth LeMay, Karen Scarfone, and Peter Mell
  • Title: National Institute of Standards and Technology (NIST) Interagency Report 7864, The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities
  • Last Updated Date: July 2012
  • Copyright Information: This document is not subject to copyright.

Tag del documento e collaboratori

 Hanno collaborato alla realizzazione di questa pagina: mozzy91
 Ultima modifica di: mozzy91,