CWE Glossary
CWE Glossary
Document version:
0.4.1 Date: July 27, 2009
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 © 2009, 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: Steve Christey
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.
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. In CWE 1.0, the only types of compound elements are Chains
and Composites, although other types might be
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 dangerous or otherwise invalid elements
from input or output.
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.
a general term used to describe a behavior that is
incorrect and has security implications. 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.
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.
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.
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).
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
sanitizes 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.
a general term to describe the process of ensuring that
input or output has certain security properties before it is used.
When used, the term could be referring to one or more of the
following: filtering/cleansing, canonicalization/resolution,
encoding/decoding, escaping/unescaping, quoting/unquoting, or
validation.
to perform Sanitization.
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.
|
