CWE Glossary
CWE GlossaryDocument version: 0.5 Date: 2011-09-13 This is a draft document. It is intended to support maintenance of CWE, and to
educate and solicit feedback from a specific technical audience. This document does
not reflect any official position of the MITRE Corporation or its sponsors.
Copyright © 2011, The
MITRE Corporation. All rights reserved. Permission is granted to redistribute this
document if this paragraph is not removed. This document is subject to change
without notice. Author: CWE Team
URL: http://cwe.mitre.org/documents/glossary/index.html Table of Contents Table of Contents
a vulnerability theory term for the location in code at an attacker's
"payload" can be executed, i.e. when the attacker has caused the code to violate the
intended security policy. For example, in SQL injection, the code reads an input
from a parameter (interaction point), incorrectly checks the input for dangerous
characters (crossover point), inserts the input into a dynamically generated query
string, then sends the query string to the database server (trigger point), then the
query is processed by the server (activation point). See the Vulnerability Theory
paper for more details.
a vulnerability theory term that describes an entity that interacts
with the software or with other entities, such as a User, Service, Monitor (e.g.
IDS), Intermediary, and others.
an actor who attempts to gain access to behaviors or resources that are
outside of the software's intended control sphere for that actor.
the process of verifying that an actor has a specific real-world
identity, typically by checking for information that the software assumes can only
be produced by that actor. This is different than authorization, because
authentication focuses on verifying the identity of the actor, not what resources
the actor can access.
the process of determining whether an actor with a given identity is
allowed to have access to a resource, then granting access to that resource, as
defined by the implicit and explicit security policies for the system. This is
different than authentication, because authorization focuses on whether a given
actor can access a given resource, not in proving what the real-world identity of
the actor is.
a weakness that is described in an abstract fashion, but with
sufficient details to infer specific methods for detection and prevention. More
general than a Variant weakness, but more specific than a Class
weakness.
an action that the software takes, typically as implemented in code or
as represented by an algorithm. Could also refer to actions by other actors that are
not the system.
acronym for "Create, Read, Update, Delete," a model for persistent
storage of data that is similar to the resource model in vulnerability
theory.
a behavior that converts or reduces an input/output to a single fixed
form that cannot be converted or reduced any further. In cases in which the
input/output is used as an identifier, canonicalization refers to the act of
converting that identifier. For example, when the current working directory is
"/users/cwe," the filename "../xyz" can be canonicalized to
"/users/xyz."
to perform Canonicalization.
a CWE entry that contains a set of other entries that share a common
characteristic.
a Compound Element that is a sequence of two or more separate
weaknesses that can be closely linked together within software. One weakness, X, can
directly create the conditions that are necessary to cause another weakness, Y, to
enter a vulnerable condition. When this happens, CWE refers to X as "primary" to Y,
and Y is "resultant" from X. For example, in the named chain CWE-691, an integer
overflow (CWE-190) can lead to a buffer overflow (CWE-120) if an integer overflow
occurs while calculating the amount of memory to allocate. In this case, the integer
overflow would be primary to the buffer overflow. Chains can involve more than two
weaknesses, and in some cases, they might have a tree-like
structure.
in the vulnerability theory model of error handling, to examine a
resource, its properties, or the system state to determine if they align with the
expectations of the software.
a weakness that is described in a very abstract fashion, typically
independent of any specific language or technology. More general than a Base
weakness.
Use of this term is discouraged in names and descriptions for CWE
weaknesses, since it has too many different meanings in the industry and may cause
mapping errors. It is not precise enough for CWE's purpose. This decision was made
in CWE 1.9. Some entries may still use this term, but they will be modified in
future versions.
This term is discouraged for use in CWE.
a Compound Element that consists of two or more distinct weaknesses, in
which all weaknesses must be present at the same time in order for a potential
vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces
the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z.
For example, Symlink Following (CWE-61) is only possible through a combination of
several component weaknesses, including predictability (CWE-340), inadequate
permissions (CWE-275), and race conditions (CWE-362). By eliminating any single
component, a developer can prevent the composite from becoming exploitable. There
can be cases in which one weakness might not be essential to a composite, but
changes the nature of the composite when it becomes a vulnerability; for example,
NUL byte interaction errors (CWE-626) can widen the scope of path traversal
weaknesses (CWE-22), which often limit which files could be accessed due to
idiosyncrasies in filename generation.
an Entry that closely associates two or more CWE entries. The CWE
team's research has shown that vulnerabilities often can be described in terms of
the interaction or co-occurrence of two or more weaknesses. In CWE 1.0, the only
types of compound elements are Chains and Composites, although other types might be
defined in later versions.
a fault - a behavior that is always incorrect if executed, i.e.,
conflicts with the intended security policy.
a vulnerability theory term for a set of resources and behaviors that
are accessible to a single actor, or a group of actors that all share the same
security restrictions. This set can be empty. A product's security model will
typically define multiple spheres, although this model might not be explicitly
stated. For example, a server might define one sphere for "administrators" who can
create new user accounts with subdirectories under /home/server/, and a second
sphere might cover the set of users who can create or delete files within their own
subdirectories. A third sphere might be "users who are authenticated to the
operating system on which the product is installed." Each sphere has different sets
of actors and allowable behaviors. Vulnerabilities can arise when the boundaries of
a control sphere are not properly enforced, or when a control sphere is defined in a
way that allows more actors or resources than the developer or system operator
intends. For example, an application might intend to allow guest users to access
files that are only within a given directory, but a path traversal attack could
allow access to files that are outside of that directory, which are thus outside of
the intended sphere of control.
a vulnerability theory term for the location in code after which an
expected property is violated. This is likely to lead to incorrect actions at a
later point. For example, a programmer might use a regular expression to restrict an
input string to contain only digits, such as for a telephone number. After applying
the regular expression, the string is expected to have the property "only contains
digits." If the regular expression is incorrectly specified (e.g. only testing for
the presence of a digit anywhere in the string), then after its application, the
code reaches a crossover point because the string does not necessarily have the
property of "only contains digits." For example, in SQL injection, the code reads an
input from a parameter (interaction point), incorrectly checks the input for
dangerous characters (crossover point), inserts the input into a dynamically
generated query string, then sends the query string to the database server (trigger
point), then the query is processed by the server (activation point). See the
Vulnerability Theory paper for more details.
a general term, meaning to check or manipulate a resource so that it
has a property that is required by the security policy. For example, the filtering
of all non-alphanumeric characters from an input is one mechanism to enforce that
"all characters are alphanumeric." An alternate method of enforcement would be to
reject the input entirely if it contains anything that's
non-alphanumeric.
any type of item in the CWE list that has been assigned a unique
identifier.
a security property in which two identifiers, inputs, resources, or
behaviors have syntactically different representations, but are ultimately treated
as being the same. For example, in Windows systems, the filenames "MyFile.txt" and
"MYFILE.TXT" are equivalent because they refer to the same underlying file object.
The inability to recognize equivalence is often a factor in
vulnerabilities.
a Slice whose membership is determined by some external criterion that
is represented using HasMember relationships between the view and those entries, but
not between entries themselves. An example is CWE-635, which lists the CWE
identifiers that being used by NVD.
to perform Filtering.
the removal of elements from input or output based on some criteria.
This term may apply to removal of elements regardless of security
implications.
a View that specifies relationships between entries, typically of a
hierarchical nature. The root level nodes of the view are specified using HasMember
relationships. Children are specified using ChildOf or other
relationships.
in the vulnerability theory model of error handling, to modify the
execution of the software based on the results of a check for an error or
exceptional condition.
Interaction/Crossover/Trigger/Activation, an acronym for the
vulnerability theory terms for important locations in code
artifacts.
a Slice that defines its membership based on common characteristics of
entries, such as weaknesses that can appear in C programs
(CWE-658).
used as a catch-all term to cover security behaviors that are either
"Missing" or "Insufficient/Incorrect." Note: this term is being used inconsistently
in CWE, although it has been more clearly defined since CWE 1.2.
a general term, used to describe when a behavior attempts to do a task
but does not do it correctly. This is distinct from "Missing," in which the
developer does not even attempt to perform the behavior. This is similar to
"Insufficient." Note: this term is being used inconsistently in CWE, although it has
been more clearly defined since CWE 1.2.
the intentional or unintentional disclosure of information to an actor
that is not explicitly authorized to have access to that
information.
Use of this term is discouraged in names and descriptions for CWE
weaknesses, since it does not provide any hint about the actual error that was
introduced by the developer. Some unreviewed entries may still use this term,
although it will be corrected in future versions of CWE. This is a general term used
to describe a behavior that is incorrect and has security implications.
a general term used to describe when a security property or behavior
can vary in strength on a continuous or sliding scale, instead of a discrete scale.
The continuous scale may vary depending on the context and risk tolerance. For
example, the requirements for randomness may vary between a random selection for a
greeting message versus the generation of a military-strength key. On the other
hand, a weakness that allows a buffer overflow is always incorrect - there is not a
sliding scale that varies across contexts. Note: this this term has been used
inconsistently in CWE, although it was more clearly defined beginning in CWE
1.4.
a vulnerability theory term for the point in code from which input is
obtained from the external environment. For example, in SQL injection, the code
reads an input from a parameter (interaction point), incorrectly checks the input
for dangerous characters (crossover point), inserts the input into a dynamically
generated query string, then sends the query string to the database server (trigger
point), then the query is processed by the server (activation point). See the
Vulnerability Theory paper for more details.
used to describe a manipulation that occurs within an identifier or
input, and not at the beginning or the end. This term is often used in conjunction
with special elements. For example, the string "/etc//passwd" has multiple internal
"/" characters, or "<SCRI.PT>" has an internal "."
character.
1) used to describe a manipulation that occurs at the beginning of an
identifier or input. This term is often used in conjunction with special elements.
For example, the string "//etc/passwd" has multiple leading "/" characters. 2) used
to describe the transition from a primary to resultant weakness in a
chain
an informal term for describing a CWE entry that the general public
thinks of as an individual weakness, but is actually a disjoint list of multiple
distinct weaknesses - i.e., a narrowly-defined category. This is not well-handled
within CWE 1.0, although it might be regarded as another kind of Compound Element.
An example of a loose composite is "insecure temporary file" - the temporary file
could have permissions problems, be used as a semaphore, be part of a race
condition, etc.
the modification of a resource by an actor, typically to change its
properties. Usually used in the context of software as it manipulates inputs and
system resources to ensure that security properties are enforced.
used to describe a behavior that the developer has not attempted to
perform. This is distinct from "incorrect," which describes when the developer
attempts to perform the behavior, but does not do it correctly. Note: this term is
being used inconsistently in CWE, although it has been more clearly defined since
CWE 1.2.
a Chain that appears so frequently in software that a CWE ID has been
assigned to it, such as CWE-680 (Integer Overflow to Buffer
Overflow).
the term used in Draft 9 for the Research Concepts View
(CWE-1000).
a general term to describe the process of ensuring that input or output
has certain security properties before it is used. This is independent of the
specific protection mechanism that performs the neutralization. The term could refer
to one or more of the following: filtering/cleansing, canonicalization/resolution,
encoding/decoding, escaping/unescaping, quoting/unquoting, validation, or other
mechanisms.
to perform Neutralization.
another term for a CWE entry, especially used before CWE
1.0.
the explicit specifications for a resource, or a set of resources, that
defines which actors are allowed to access that resource, and which actions may be
performed by those actors. Permissions can contribute to the definition of one or
more intended control spheres.
a top-level entry in the Research Concepts View (CWE-1000). Equivalent
to "kingdoms" in Seven Pernicious Kingdoms.
a weakness that is an initial, critical error (root cause) that can
expose other weaknesses later in execution of the software.
a vulnerability theory term for the security-relevant characteristic of
an individual resource or behavior that is important to the system's intended
security model, which might change over time. For example, user input is initially
untrusted; after the system neutralizes the input, when the input is finally
processed, it must be treated as trusted. This illustrates the Trustability
property.
a vulnerability theory term for a set of behaviors that helps to
enforce an implicit or explicit security policy for the software, such as an input
validation routine.
a security-relevant assumption that a resource has a given property,
which can lead to weaknesses if that property cannot be guaranteed. For example, an
access control protection mechanism might use reverse DNS lookups (CWE-247) in an
attempt to limit access to systems in a particular domain; however, this reliance on
DNS introduces a weakness because DNS results can be spoofed.
the process of converting a resource identifier to a single, canonical
form. For example, code that converts "/tmp/abc/../def.xyz" to "/tmp/def.xyz" is
performing resolution on an identifier that is being used for a file
resource.
to perform Resolution.
a vulnerability theory term for an object or entity that is accessed or
modified within the operation of the software, such as memory, CPU, files, or
sockets. Resources can be system-level (memory or CPU), code-level (function or
variable), or application-level (cookie or message).
a weakness that is only exposed to attack after another weakness has
been exploited; an early link in a chain.
Software Development Lifecycle.
Use of this term is discouraged in names and descriptions for CWE
weaknesses, since it has too many different meanings in the industry and may cause
mapping errors. It is not precise enough for CWE's purpose. This decision was made
in CWE 1.8.1. Some entries may still use this term, but they will be modified in
future versions. Similar terms in use in CWE may include "Neutralization,"
"Validation," "Encoding," and "Filtering."
This term is discouraged for use in CWE.
in vulnerability theory, a set of valid behaviors, properties, and
resources within the context of operation of a software system. The policy is
generally implicit (as reflected in the code, or the programmer's assumptions), but
it can be explicit.
a view that is a flat list of CWE entries that does not specify any
relationships between those entries.
a general term for a sequence of bytes, characters, or words that is
used to separate different portions of data within a particular representation or
language. The most commonly understood usage of special elements is in single
characters, such as the "<" in HTML, which marks the beginning of a tag. As
another example, the CRLF (carriage return / line feed) character is used as a
separator between headers in MIME messages, so CRLF is a special element. When
multi-part MIME messages are constructed, the boundary string becomes a special
element. Special elements are often important in weaknesses that can be exploited by
injection attacks. A special element in one representation might not be special in
another. For example, whitespace is a special element when executing a command in a
shell (since it acts as an argument separator), but it has no special meaning in the
body of HTML or e-mail messages.
See Control Sphere
used to describe a manipulation that occurs at the end of an identifier
or input. This term is often used in conjunction with special elements. For example,
the string "example.com." has a trailing "." character.
a vulnerability theory term for the location in code after which the
software can no longer prevent itself from violating the intended security policy.
For example, in SQL injection, the code reads an input from a parameter (interaction
point), incorrectly checks the input for dangerous characters (crossover point),
inserts the input into a dynamically generated query string, then sends the query
string to the database server (trigger point), then the query is processed by the
server (activation point). See the Vulnerability Theory paper for more
details.
violating the assumptions of the developer or operator of the software.
This is typically used to describe the state of the software, a behavior that was
not intended, or a property of a resource that was not assumed to be present. For
example, if an e-commerce program allows a user to specify the quantity of items to
purchase, and the program assumes that the quantity will be a number, then the
string "abcde" is unexpected. A program crash is usually unexpected behavior.
Similarly, when a programmer dereferences a pointer, it is usually unexpected if
that pointer can be NULL. Attacks often leverage unexpected properties and
behaviors, since the developer has not necessarily provided a sufficient
defense.
a weakness that is described at a very low level of detail, typically
limited to a specific language or technology. More specific than a Base
weakness.
a subset of CWE entries that provides a way of examining CWE content.
The two main view structures are Slices (flat lists) and Graphs (containing
relationships between entries).
an occurrence of a weakness (or multiple weaknesses) within software,
in which the weakness can be used by a party to cause the software to modify or
access unintended data, interrupt proper execution, or perform incorrect actions
that were not specifically granted to the party who uses the
weakness.
a type of mistake in software that, in proper conditions, could
contribute to the introduction of vulnerabilities within that software. This term
applies to mistakes regardless of whether they occur in implementation, design, or
other phases of the SDLC.
|
