Sensitive Cookie Without 'HttpOnly' Flag

Summary: The product uses a cookie to store sensitive information, but the cookie is not marked with the HttpOnly flag.

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

If the HttpOnly flag is not set, then sensitive information stored in the cookie may be exposed to unintended parties.

If the cookie in question is an authentication cookie, then not setting the HttpOnly flag may allow an adversary to steal authentication data (e.g., a session ID) and assume the identity of the user.


Insufficient Visual Distinction of Homoglyphs Presented to User

Homograph Attack

"Homograph" is often used as a synonym of "homoglyph" by researchers, but according to Wikipedia, a homograph is a word that has multiple, distinct meanings.

Summary: The product displays information or identifiers to a user, but the display mechanism does not make it easy for the user to distinguish between visually similar or identical glyphs (homoglyphs), which may cause the user to misinterpret a glyph and perform an unintended, insecure action.

If utilizing user accounts, attempt to submit a username that contains homoglyphs. Similarly, check to see if links containing homoglyphs can be sent via email, web browsers, or other mechanisms.

An attacker may ultimately redirect a user to a malicious website, by deceiving the user into believing the URL they are accessing is a trusted domain. However, the attack can also be used to forge log entries by using homoglyphs in usernames. Homoglyph manipulations are often the first step towards executing advanced attacks such as stealing a user's credentials, Cross-Site Scripting (XSS), or log forgery. If an attacker redirects a user to a malicious site, the attacker can mimic a trusted domain to steal account credentials and perform actions on behalf of the user, without the user's knowledge. Similarly, an attacker could create a username for a website that contains homoglyph characters, making it difficult for an admin to review logs and determine which users performed which actions.


Struts: Duplicate Validation Forms

Summary: The product uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.


Improper Restriction of Rendered UI Layers or Frames

Tapjacking

"Tapjacking" is similar to clickjacking, except it is used for mobile applications in which the user "taps" the application instead of performing a mouse click.

Summary: The web application does not restrict or incorrectly restricts frame objects or UI layers that belong to another application or domain, which can lead to user confusion about which interface the user is interacting with.

An attacker can trick a user into performing actions that are masked and hidden from the user's view. The impact varies widely, depending on the functionality of the underlying application. For example, in a social media application, clickjacking could be used to trik the user into changing privacy settings.


Use of Web Link to Untrusted Target with window.opener Access

Summary: The web application produces links to untrusted external sites outside of its sphere of control, but it does not properly prevent the external site from modifying  security-critical properties of the window.opener object, such as the location property.

The user may be redirected to an untrusted page that contains undesired content or malicious script code.


Incomplete Comparison with Missing Factors

Summary: The product performs a comparison between entities that must consider multiple factors or characteristics of each entity, but the comparison does not include one or more of these factors.


Comparison of Incompatible Types

Summary: The product performs a comparison between two entities, but the entities are of different, incompatible types that cannot be guaranteed to provide correct results when they are directly compared.


Comparison Using Wrong Factors

Summary: The code performs a comparison between two entities, but the comparison examines the wrong factors or characteristics of the entities, which can lead to incorrect results and resultant weaknesses.


Struts: Incomplete validate() Method Definition

Summary: The product has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate().

This could introduce other weaknesses related to missing input validation.

The current description implies a loose composite of two separate weaknesses, so this node might need to be split or converted into a low-level category.

Disabling the validation framework for a form exposes the product to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection.

Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.


Processor Optimization Removal or Modification of Security-critical Code

Summary: The developer builds a security-critical protection mechanism into the software, but the processor optimizes the execution of the program such that the mechanism is removed or modified.

In theory this weakness can be detected through the use of white box testing techniques where specifically crafted test cases are used in conjunction with debuggers to verify the order of statements being executed.

As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. As a result, this entry might change significantly in CWE 4.10.

A successful exploitation of this weakness will change the order of an application's execution and will likely be used to bypass specific protection mechanisms. This bypass can be exploited further to potentially read data that should otherwise be unaccessible.


Insecure Automated Optimizations

Summary: The product uses a mechanism that automatically optimizes code, e.g. to improve a characteristic such as performance, but the optimizations can have an unintended side effect that might violate an intended security assumption.

The optimizations alter the order of execution resulting in side effects that were not intended by the original developer.


Automated Recognition Mechanism with Inadequate Detection or Handling of Adversarial Input Perturbations

Summary: The product uses an automated mechanism such as machine learning to recognize complex data inputs (e.g. image or audio) as a particular concept or category, but it does not properly detect or handle inputs that have been modified or constructed in a way that causes the mechanism to detect a different, incorrect concept.

Further investigation is needed to determine if better relationships exist or if additional organizational entries need to be created.  For example, this issue might be better related to "recognition of input as an incorrect type," which might place it as a sibling of CWE-704 (incorrect type conversion).

When the automated recognition is used in a protection mechanism, an attacker may be able to craft inputs that are misinterpreted in a way that grants excess privileges.


Struts: Form Bean Does Not Extend Validation Class

Summary: If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation.

Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is an important component of vulnerabilities like cross-site scripting, process control, and SQL injection.


Use of Redundant Code

Summary:
The product has multiple functions, methods, procedures, macros, etc. that
					contain the same code.


Static Member Data Element outside of a Singleton Class Element

Summary:
The code contains a member element that is declared as static (but not final), in which
					its parent class element
					is not a singleton class - that is, a class element that can be used only once in
					the 'to' association of a Create action.


Data Element Aggregating an Excessively Large Number of Non-Primitive Elements

Summary:
The product uses a data element that has an excessively large
					number of sub-elements with non-primitive data types such as structures or aggregated objects.


Architecture with Number of Horizontal Layers Outside of Expected Range

Summary:
The product's architecture contains too many - or too few -
					horizontal layers.


Parent Class with a Virtual Destructor and a Child Class without a Virtual Destructor

Summary: A parent class has a virtual destructor method, but the parent has a child class that does not have a virtual destructor.


Creation of Immutable Text Using String Concatenation

Summary: The product creates an immutable text string using string concatenation operations.


Modules with Circular Dependencies

Summary: The product contains modules in which one module has references that cycle back to itself, i.e., there are circular dependencies.


Invokable Control Element with Large Number of Outward Calls

Summary:
The code contains callable control elements that
         contain an excessively large number of references to other
         application objects external to the context of the callable,
         i.e. a Fan-Out value that is excessively large.


Excessive Data Query Operations in a Large Data Table

Summary:
The product performs a data query with a large number of joins
					and sub-queries on a large data table.


Struts: Form Field Without Validator

Summary: The product has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation.

If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form.


Excessive Platform Resource Consumption within a Loop

Summary:
The product has a loop body or loop condition that contains a control element that directly or
					indirectly consumes platform resources, e.g. messaging, sessions, locks, or file
					descriptors.


Initialization with Hard-Coded Network Resource Configuration Data

Summary: The product initializes data using hard-coded values that act as network resource identifiers.


Excessive Use of Hard-Coded Literals in Initialization

Summary:
The product initializes a data element using a hard-coded
					literal that is not a simple integer or static constant element.


Missing Documentation for Design

Summary: The product does not have documentation that represents how it is designed.


Invocation of a Control Element at an Unnecessarily Deep Horizontal Layer

Summary:
The code at one architectural layer invokes code that resides
					at a deeper layer than the adjacent layer, i.e., the invocation skips at least one
					layer, and the invoked code is not part of a vertical utility layer that can be referenced from any horizontal layer.


Multiple Inheritance from Concrete Classes

Summary:
The product contains a class with inheritance from more than
					one concrete class.


Invokable Control Element with Variadic Parameters

Summary:
A named-callable or method control element has a signature that
					supports a variable (variadic) number of parameters or arguments.


Data Access Operations Outside of Expected Data Manager Component

Summary: The product uses a dedicated, central data manager component as required by design, but it contains code that performs data-access operations that do not use this data manager.


Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element

Summary:
The code contains a function or method that
		 operates in a multi-threaded environment but owns an unsafe non-final
		                     static storable or member data element.


Insufficient Technical Documentation

Summary:
The product does not contain sufficient
         technical or engineering documentation (whether on paper or
         in electronic form) that contains descriptions of all the
         relevant software/hardware elements of the product, such as
         its usage, structure, architectural components, interfaces, design, implementation,
         configuration, operation, etc.

Without a method of verification, one cannot be sure that everything only functions as expected.


Struts: Plug-in Framework not in Use

Summary: When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation.


Excessive Number of Inefficient Server-Side Data Accesses

Summary: The product performs too many data queries without using efficient data processing functionality such as stored procedures.


Insufficient Encapsulation

Summary: The product does not sufficiently hide the internal representation and implementation details of data or methods, which might allow external components or modules to modify data unexpectedly, invoke unexpected functionality, or introduce dependencies that the programmer did not intend.


Parent Class with References to Child Class

Summary: The code has a parent class that contains references to a child class, its methods, or its members.


Creation of Class Instance within a Static Code Block

Summary: A static code block creates an instance of a class.


Invokable Control Element with Signature Containing an Excessive Number of Parameters

Summary:
The product contains a function, subroutine, or method whose signature has an unnecessarily large number of
					parameters/arguments.


Runtime Resource Management Control Element in a Component Built to Run on Application Servers

Summary: The product uses deployed components from application servers, but it also uses low-level functions/methods for management of resources, instead of the API provided by the application server.


Missing Serialization Control Element

Summary:
The product contains a serializable data element that does not
					have an associated serialization method.


Excessive Execution of Sequential Searches of Data Resource

Summary:
The product contains a data query against an SQL table or view
					that is configured in a way that does not utilize an index and may cause
					sequential searches to be performed.


Inconsistency Between Implementation and Documented Design

Summary:
The implementation of the product is not consistent with the
					design as described within the relevant documentation.


Empty Exception Block

Summary: An invokable code block contains an exception handling block that does not contain any code, i.e. is empty.


Struts: Unused Validation Form

Summary: An unused validation form indicates that validation logic is not up-to-date.


Serializable Data Element Containing non-Serializable Item Elements

Summary:
The product contains a serializable, storable data element such as a field or member,
					but the data element contains member elements that are not
					serializable.


Empty Code Block

Summary: The source code contains a block that does not contain any code, i.e., the block is empty.


Data Resource Access without Use of Connection Pooling

Summary:
The product accesses a data resource through a database without using a
					connection pooling capability.


Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses

Summary: The product contains a client with a function or method that contains a large number of data accesses/queries that are sent through a data manager, i.e., does not use efficient database capabilities.


Class with Excessively Deep Inheritance

Summary:
A class has an inheritance level that is too high, i.e., it
					has a large number of parent classes.


Unconditional Control Flow Transfer outside of Switch Block

Summary:
The product performs unconditional control transfer (such as a
					"goto") in code outside of a branching structure such as a switch
					block.


Insufficient Adherence to Expected Conventions

Summary:
The product's architecture, source code, design, documentation,
					or other artifact does not follow required conventions.


Floating Point Comparison with Incorrect Operator

Summary:
The code performs a comparison such as an
        equality test between two float (floating point) values, but
        it uses comparison operators that do not account for the
        possibility of loss of precision.


Inappropriate Source Code Style or Formatting

Summary:
The source code does not follow
				desired style or formatting for indentation, white
				space, comments, etc.


Parent Class without Virtual Destructor Method

Summary: A parent class contains one or more child classes, but the parent class does not have a virtual destructor method.


Struts: Unvalidated Action Form

Summary: Every Action Form must have a corresponding validation form.

If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation.


Source Code File with Excessive Number of Lines of Code

Summary:
A source code file has too many lines of
					code.


Class Instance Self Destruction Control Element

Summary: The code contains a class instance that calls the method or function to delete or destroy itself.


Data Access from Outside Expected Data Manager Component

Summary: The product is intended to manage data access through a particular data manager component such as a relational or non-SQL database, but it contains code that performs data access operations without using that component.


Invokable Control Element with Excessive File or Data Access Operations

Summary:
A function or method contains too many
					operations that utilize a data manager or file resource.


Invokable Control Element with Excessive Volume of Commented-out Code

Summary:
A function, method, procedure, etc. contains an excessive amount of code that has been
					commented out within its body.


Class with Excessive Number of Child Classes

Summary:
A class contains an unnecessarily large number of
					children.


Class with Virtual Method without a Virtual Destructor

Summary: A class contains a virtual method, but the method does not have an associated virtual destructor.


Synchronous Access of Remote Resource without Timeout

Summary: The code has a synchronous call to a remote resource, but there is no timeout for the call, or the timeout is set to infinite.


Large Data Table with Excessive Number of Indices

Summary:
The product uses a large data table that contains an excessively large number of
					indices.


Struts: Validator Turned Off

Summary: Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation.

The Action Form mapping in the demonstrative example disables the form's validate() method. The Struts bean: write tag automatically encodes special HTML characters, replacing a < with "<" and a > with ">". This action can be disabled by specifying filter="false" as an attribute of the tag to disable specified JSP pages. However, being disabled makes these pages susceptible to cross-site scripting attacks. An attacker may be able to insert malicious scripts as user input to write to these JSP pages.


Method Containing Access of a Member Element from Another Class

Summary:
A method for a class performs an operation that directly
					accesses a member element from another class.


Use of Object without Invoking Destructor Method

Summary:
The product contains a method that accesses an object but does not later invoke
					the element's associated finalize/destructor method.


Use of Same Invokable Control Element in Multiple Architectural Layers

Summary:
The product uses the same control element across multiple
					architectural layers.


Excessively Complex Data Representation

Summary: The product uses an unnecessarily complex internal representation for its data structures or interrelationships between those structures.


Excessive Index Range Scan for a Data Resource

Summary:
The product contains an index range scan for a large data table,
					but the scan can cover a large number of rows.


Loop Condition Value Update within the Loop

Summary:
The product uses a loop with a control flow condition based on
					a value that is updated within the body of the loop.


Singleton Class Instance Creation without Proper Locking or Synchronization

Summary: The product implements a Singleton design pattern but does not use appropriate locking or other synchronization mechanism to ensure that the singleton class is only instantiated once.


Persistent Storable Data Element without Associated Comparison Control Element

Summary:
The product uses a storable data element that does not have
					all of the associated functions or methods that are necessary to support
					comparison.


Data Element containing Pointer Item without Proper Copy Control Element

Summary: The code contains a data element with a pointer that does not have an associated copy or constructor method.


Inconsistent Naming Conventions for Identifiers

Summary:
The product's code, documentation, or other artifacts do not
					consistently use the same naming conventions for variables, callables, groups of
					related callables, I/O capabilities, data types, file names, or similar types of
					elements.


ASP.NET Misconfiguration: Creating Debug Binary

Summary: Debugging messages help attackers learn about the system and plan a form of attack.

Attackers can leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.


Struts: Validator Without Form Field

Summary: Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date.

To find the issue in the implementation, manual checks or automated static analysis could be applied to the XML configuration files.

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation.


Insufficient Isolation of System-Dependent Functions

Summary:
The product or code does not isolate system-dependent
					functionality into separate standalone modules.


Reliance on Runtime Component in Generated Code

Summary:
The product uses automatically-generated code that cannot be
					executed without a specific runtime support component.


Reliance on Machine-Dependent Data Representation

Summary:
The code uses a data representation that relies on low-level
					data representation or constructs that may vary across different processors,
					physical machines, OSes, or other physical components.


Use of Platform-Dependent Third Party Components

Summary:
The product relies on third-party components that do
					not provide equivalent functionality across all desirable
					platforms.


Use of Unmaintained Third Party Components

Summary:
The product relies on third-party components that are not
					actively supported or maintained by the original developer or a trusted proxy
					for the original developer.


Insufficient Encapsulation of Machine-Dependent Functionality

Summary:
The product or code uses machine-dependent functionality, but
					it does not sufficiently encapsulate or isolate this functionality from
					the rest of the code.


Insufficient Use of Symbolic Constants

Summary:
The source code uses literal constants that may need to change
					or evolve over time, instead of using symbolic constants.


Insufficient Isolation of Symbolic Constant Definitions

Summary:
The source code uses symbolic constants, but it does not
					sufficiently place the definitions of these constants into a more centralized or
					isolated location.


Excessive Reliance on Global Variables

Summary:
The code is structured in a way that relies too much on using
					or setting global variables throughout various points in the code, instead of
					preserving the associated information in a narrower, more local
					context.


Use of Same Variable for Multiple Purposes

Summary:
The code contains a callable, block, or other code element in
					which the same variable is used to control more than one unique task or store
					more than one instance of data.


Direct Use of Unsafe JNI

Summary: When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.


Incomplete Design Documentation

Summary:
The product's design documentation does not adequately describe
					control flow, data flow, system initialization, relationships between tasks,
					components, rationales, or other important aspects of the
					design.


Incomplete I/O Documentation

Summary:
The product's documentation does not adequately define inputs,
					outputs, or system/software interfaces.


Incomplete Documentation of Program Execution

Summary:
The document does not fully define all mechanisms that are used
					to control or influence how product-specific programs are
					executed.


Inappropriate Comment Style

Summary:
The source code uses comment styles or formats that are
					inconsistent or do not follow expected standards for the
					product.


Inappropriate Whitespace Style

Summary:
The source code contains whitespace that is inconsistent across
					the code or does not follow expected standards for the
					product.


Source Code Element without Standard Prologue

Summary:
The source code contains elements such as source files
					that do not consistently provide a prologue or header that has been
					standardized for the project.


Inaccurate Comments

Summary:
The source code contains comments that do not accurately
					describe or explain aspects of the portion of the code with which the comment is
					associated.


Callable with Insufficient Behavioral Summary

Summary:
The code contains a function or method whose signature and/or associated
					inline documentation does not sufficiently describe the callable's inputs, outputs,
					side effects, assumptions, or return codes.


Insufficient Documentation of Error Handling Techniques

Summary:
The documentation does not sufficiently describe the techniques
					that are used for error handling, exception processing, or similar
					mechanisms.


Excessive Use of Unconditional Branching

Summary:
The code uses too many unconditional branches (such as
					"goto").


Missing XML Validation

Summary: The product accepts XML from an untrusted source but does not validate the XML against the proper schema.


Excessive Code Complexity

Summary:
The code is too complex, as calculated using a well-defined,
					quantitative measure.


Excessive McCabe Cyclomatic Complexity

Summary:
The code contains McCabe cyclomatic complexity that exceeds a
	desirable maximum.


Excessive Halstead Complexity

Summary:
The code is structured in a way that a Halstead complexity
					measure exceeds a desirable maximum.


Excessive Use of Self-Modifying Code

Summary:
The product uses too much self-modifying
					code.


Excessively Deep Nesting

Summary:
The code contains a callable or other code grouping in which
					the nesting / branching is too deep.


Excessive Attack Surface

Summary:
The product has an attack surface whose quantitative
					measurement exceeds a desirable maximum.


Declaration of Variable with Unnecessarily Wide Scope

Summary:
The source code declares a variable in one scope, but the
					variable is only used within a narrower scope.


Compilation with Insufficient Warnings or Errors

Summary:
The code is compiled without sufficient warnings enabled, which
					may prevent the detection of subtle bugs or quality
					issues.


Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')

Summary: The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.

CR and LF characters in an HTTP header may give attackers control of the remaining headers and body of the message that the application intends to send/receive, as well as allowing them to create additional messages entirely under their control.


Process Control

Summary: Executing commands or loading libraries from an untrusted source or in an untrusted environment can cause an application to execute malicious commands (and payloads) on behalf of an attacker.

CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.

This entry seems to have close relationships with CWE-426/CWE-427. It seems more attack-oriented.


Misinterpretation of Input

Summary: The product misinterprets an input, whether from an attacker or another product, in a security-relevant fashion.

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

This concept needs further study. It is likely a factor in several weaknesses, possibly resultant as well. Overlaps Multiple Interpretation Errors (MIE).


Improper Encoding or Escaping of Output

Summary: The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

This weakness is primary to all weaknesses related to injection (CWE-74) since the inherent nature of injection involves the violation of structured messages.

The usage of the "encoding" and "escaping" terms varies widely. For example, in some programming languages, the terms are used interchangeably, while other languages provide APIs that use both terms for different tasks. This overlapping usage extends to the Web, such as the "escape" JavaScript function whose purpose is stated to be encoding. The concepts of encoding and escaping predate the Web by decades. Given such a context, it is difficult for CWE to adopt a consistent vocabulary that will not be misinterpreted by some constituency.

This is a data/directive boundary error in which data boundaries are not sufficiently enforced before it is sent to a different control sphere.

While many published vulnerabilities are related to insufficient output encoding, there is such an emphasis on input validation as a protection mechanism that the underlying causes are rarely described. Within CVE, the focus is primarily on well-understood issues like cross-site scripting and SQL injection. It is likely that this weakness frequently occurs in custom protocols that support multiple encodings, which are not necessarily detectable with automated techniques.

The communications between components can be modified in unexpected ways. Unexpected commands can be executed, bypassing other security mechanisms. Incoming data can be misinterpreted.


Irrelevant Code

Summary:
The product contains code that is not essential for execution,
	     i.e. makes no state changes and has no side effects that alter
	     data or control flow, such that removal of the code would have no impact
	     to functionality or correctness.


Improper Output Neutralization for Logs

Summary: The product does not neutralize or incorrectly neutralizes output that is written to logs.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. Forged or otherwise corrupted log files can be used to cover an attacker's tracks, possibly by skewing statistics, or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility.


Improper Use of Validation Framework

Summary: The product does not use, or incorrectly uses, an input validation framework that is provided by the source language or an independent library.

Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others.


ASP.NET Misconfiguration: Improper Model Validation

Summary: The ASP.NET application does not use, or incorrectly uses, the model validation framework.


Inefficient CPU Computation

Summary:
The product performs CPU computations using
         algorithms that are not as efficient as they could be for the
         needs of the developer, i.e., the computations can be
         optimized further.


Use of Prohibited Code

Summary:
The product uses a function, library, or third party component
	     that has been explicitly prohibited, whether by the developer or
	     the customer.


Incorrect Access of Indexable Resource ('Range Error')

Summary: The product does not restrict or incorrectly restricts operations within the boundaries of a resource that is accessed using an index or pointer, such as memory or files.


DEPRECATED: Use of Uninitialized Resource

Summary: This entry has been deprecated because it was a duplicate of CWE-908. All content has been transferred to CWE-908.


Initialization of a Resource with an Insecure Default

Summary: The product initializes or sets a resource with a default that is intended to be changed by the administrator, but the default is not secure.

This entry improves organization of concepts under initialization.  The typical CWE model is to cover "Missing" and "Incorrect" behaviors.  Arguably, this entry could be named as "Incorrect" instead of "Insecure."  This might be changed in the near future.


Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

Summary: The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.

If resources being used by a trusted user are shared with an untrusted user, the untrusted user may be able to modify the functionality of the shared resource of the trusted user.

The functionality of the shared resource may be intentionally degraded.


Improper Restriction of Operations within the Bounds of a Memory Buffer

Buffer Overflow

This term has many different meanings to different audiences.  From a CWE mapping perspective, this term should be avoided where possible. Some researchers, developers, and tools intend for it to mean "write past the end of a buffer," whereas others use the same term to mean "any read or write outside the boundaries of a buffer, whether before the beginning of the buffer or after the end of the buffer."  Others could mean "any action after the end of a buffer, whether it is a read or write." Since the term is commonly used for exploitation and for vulnerabilities, it further confuses things.

buffer overrun

Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow." See the alternate term for "buffer overflow" for context.

memory safety

Generally used for techniques that avoid weaknesses related to memory access, such as those identified by CWE-119 and its descendants. However, the term is not formal, and there is likely disagreement between practitioners as to which weaknesses are implicitly covered by the "memory safety" term.

Summary: The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

Automated Static Analysis - Binary or Bytecode

Manual Static Analysis - Binary or Bytecode

Dynamic Analysis with Automated Results Interpretation

Dynamic Analysis with Manual Results Interpretation

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can alter the intended control flow by redirecting a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

In the case of an out-of-bounds read, the attacker may have access to sensitive information. If the sensitive information contains system details, such as the current buffer's position in memory, this knowledge can be used to craft further attacks, possibly with more severe consequences.


DMA Device Enabled Too Early in Boot Phase

Summary: The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.

DMA devices have direct write access to main memory and
                 due to time of attack will be able to bypass OS or Bootloader
                 access control.


On-Chip Debug and Test Interface With Improper Access Control

Summary: The chip does not implement or does not correctly perform access control to check whether users are authorized to access internal registers and test modes through the physical debug/test interface.

Tests that fuzz Debug and Test Interfaces should ensure that no access without appropriate authentication and authorization is possible.

CWE-1191 and CWE-1244 both involve physical debug access,
	  but the weaknesses are different. CWE-1191 is effectively
	  about missing authorization for a debug interface,
	  i.e. JTAG.  CWE-1244 is about providing internal assets with
	  the wrong debug access level, exposing the asset to
	  untrusted debug agents.


Improper Identifier for IP Block used in System-On-Chip (SOC)

Summary: The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.


Power-On of Untrusted Execution Core Before Enabling Fabric Access Control

Summary: The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.

An untrusted component can master transactions on the HW bus and target memory or other assets to compromise the SoC boot firmware.


ASP.NET Misconfiguration: Missing Custom Error Page

Summary: An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.

Default error pages gives detailed information about the error that occurred, and should not be used in production environments. Attackers can leverage the additional information provided by a default error page to mount attacks targeted on the framework, database, or other resources used by the application.


Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

Classic Buffer Overflow

This term was frequently used by vulnerability researchers during approximately 1995 to 2005 to differentiate buffer copies without length checks (which had been known about for decades) from other emerging weaknesses that still involved invalid accesses of buffers, as vulnerability researchers began to develop advanced exploitation techniques.

Summary: The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them.

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of the product's implicit security policy. This can often be used to subvert any other security service.

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the product into an infinite loop.


Generation of Weak Initialization Vector (IV)

Summary:
The product uses a cryptographic primitive that uses an Initialization
			Vector (IV), but the product does not generate IVs that are
			sufficiently unpredictable or unique according to the expected
			cryptographic requirements for that primitive.

As of CWE 4.5, terminology related to randomness, entropy, and
			  predictability can vary widely. Within the developer and other
			  communities, "randomness" is used heavily. However, within
			  cryptography, "entropy" is distinct, typically implied as a
			  measurement. There are no commonly-used definitions, even within
			  standards documents and cryptography papers. Future versions of
			  CWE will attempt to define these terms and, if necessary,
			  distinguish between them in ways that are appropriate for
			  different communities but do not reduce the usability of CWE for
			  mapping, understanding, or other scenarios.

If the IV is not properly initialized, data that is encrypted can be compromised and information about the data can be leaked. See [REF-1179].


Failure to Disable Reserved Bits

Summary: The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design.   However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.

This type of weakness all depends on the capabilities of the logic being controlled or configured by the reserved bits.


Stack-based Buffer Overflow

Stack Overflow

"Stack Overflow" is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged.

Summary: A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

Stack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc.

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.


Heap-based Buffer Overflow

Summary: A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().

Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows.

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.


Insufficient Granularity of Access Control

Summary: The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.


Incorrect Register Defaults or Module Parameters

Summary: Hardware description language code incorrectly defines register defaults or hardware Intellectual Property (IP) parameters to insecure values.

Degradation of system functionality, or loss of access control enforcement can occur.


Insufficient Granularity of Address Regions Protected by Register Locks

Summary: The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.

System security configuration cannot be defined in a way that does not conflict with functional requirements of device.


Race Condition for Write-Once Attributes

Summary: A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.

System configuration cannot be programmed in a secure way.


Improper Restriction of Write-Once Bit Fields

Summary: The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.


Creation of Emergent Resource

Summary: The product manages resources or behaves in a way that indirectly creates a new, distinct resource that can be used by attackers in violation of the intended policy.


Write-what-where Condition

Summary: Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.

Clearly, write-what-where conditions can be used to write data to areas of memory outside the scope of a policy. Also, they almost invariably can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. If the attacker can overwrite a pointer's worth of memory (usually 32 or 64 bits), they can redirect a function pointer to their own malicious code. Even when the attacker can only modify a single byte arbitrary code execution can be possible. Sometimes this is because the same problem can be exploited repeatedly to the same effect. Other times it is because the attacker can overwrite security-critical application-specific data -- such as a flag indicating whether the user is an administrator.

Many memory accesses can lead to program termination, such as when writing to addresses that are invalid for the current process.


Exposure of Sensitive Information Through Metadata

Summary: The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.


Improper Prevention of Lock Bit Modification

Summary: The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.

Set the lock bit. Power cycle the
	     device. Attempt to clear the lock bit.  If the
	     information is changed, implement a design
	     fix. Retest. Also, attempt to indirectly clear the lock
	     bit or bypass it.

Registers protected by lock bit can be modified even when lock is set.


Improper Lock Behavior After Power State Transition

Summary: Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.


Security-Sensitive Hardware Controls with Missing Lock Bit Protection

Summary: The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.

Set the lock bit. Attempt to modify the
	     information protected by the lock bit. If the information
	     is changed, implement a design fix. Retest. Also, attempt
	     to indirectly clear the lock bit or bypass
	     it.

System Configuration protected by the lock bit can be modified even when the lock is set.


Hardware Internal or Debug Modes Allow Override of Locks

Summary: System configuration protection may be bypassed during debug mode.

Bypass of lock bit allows access and modification of system configuration even when the lock bit is set.


Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations

Summary: The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.

Incorrect autoboxing/unboxing would result in reduced performance, which sometimes can lead to resource consumption issues.


Improper Neutralization of Formula Elements in a CSV File

Summary: The product saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by a spreadsheet product.

Current versions of Excel warn users of untrusted content.


Improper Zeroization of Hardware Register

Summary: The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.

The consequences will depend on the information disclosed due to the vulnerability.


Buffer Underwrite ('Buffer Underflow')

buffer underrun

Some prominent vendors and researchers use the term "buffer underrun". "Buffer underflow" is more commonly used, although both terms are also sometimes used to describe a buffer under-read (CWE-127).

Summary: The product writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.

This could be resultant from several errors, including a bad offset or an array index that decrements before the beginning of the buffer (see CWE-129).

Out of bounds memory access will very likely result in the corruption of relevant memory, and perhaps instructions, possibly leading to a crash.

If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code. If the corrupted memory is data rather than instructions, the system will continue to function with improper changes, possibly in violation of an implicit or explicit policy. The consequences would only be limited by how the affected data is used, such as an adjacent memory location that is used to specify whether the user has special privileges.

When the consequence is arbitrary code execution, this can often be used to subvert any other security service.


Use of a Cryptographic Primitive with a Risky Implementation

Summary: To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.

Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.

Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.

For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236].

It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).

Since CWE 4.4, various cryptography-related entries, including CWE-327 and CWE-1240, have been slated for extensive research, analysis, and community consultation to define consistent terminology, improve relationships, and reduce overlap or duplication. As of CWE 4.6, this work is still ongoing.

Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.


Use of Predictable Algorithm in Random Number Generator

Summary: The device uses an algorithm that is predictable and generates a pseudo-random number.

As of CWE 4.5, terminology related to randomness, entropy, and
	   predictability can vary widely. Within the developer and other
	   communities, "randomness" is used heavily. However, within
	   cryptography, "entropy" is distinct, typically implied as a
	   measurement. There are no commonly-used definitions, even within
	   standards documents and cryptography papers. Future versions of
	   CWE will attempt to define these terms and, if necessary,
	   distinguish between them in ways that are appropriate for
	   different communities but do not reduce the usability of CWE for
	   mapping, understanding, or other scenarios.


Inclusion of Undocumented Features or Chicken Bits

Summary: The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.


Sensitive Non-Volatile Information Not Protected During Debug

Summary: Access to security-sensitive information stored in fuses is not limited during debug.


Internal Asset Exposed to Unsafe Debug Access Level or State

Summary:
The product uses physical debug or test
        interfaces with support for multiple access levels, but it
        assigns the wrong debug access level to an internal asset,
        providing unintended access to the asset from untrusted debug
        agents.

Check 2 devices for their passcode to authenticate access to JTAG/debugging ports. If the passcodes are missing or the same, update the design to fix and retest. Check communications over JTAG/debugging ports for encryption. If the communications are not encrypted, fix the design and retest.

CWE-1191 and CWE-1244 both involve physical debug access,
	  but the weaknesses are different. CWE-1191 is effectively
	  about missing authorization for a debug interface,
	  i.e. JTAG.  CWE-1244 is about providing internal assets with
	  the wrong debug access level, exposing the asset to
	  untrusted debug agents.


Improper Finite State Machines (FSMs) in Hardware Logic

Summary: Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.


Improper Write Handling in Limited-write Non-Volatile Memories

Summary: The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.


Improper Protection Against Voltage and Clock Glitches

Summary: The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.

During the implementation phase where actual hardware is available, specialized hardware tools and apparatus such as ChipWhisperer may be used to check if the platform is indeed susceptible to voltage and clock glitching attacks.

Review if the protections against glitching merely transfer the attack target. For example, suppose a critical authentication routine that an attacker would want to bypass is given the protection of modifying certain artifacts from within that specific routine (so that if the routine is bypassed, one can examine the artifacts and figure out that an attack must have happened). However, if the attacker has the ability to bypass the critical authentication routine, they might also have the ability to bypass the other protection routine that checks the artifacts. Basically, depending on these kind of protections is akin to resorting to "Security by Obscurity".

Many SoCs come equipped with a built-in Dynamic Voltage and Frequency Scaling (DVFS) that can control the voltage and clocks via software alone. However, there have been demonstrated attacks (like Plundervolt and CLKSCREW) that target this DVFS [REF-1081] [REF-1082]. During the design and implementation phases, one needs to check if the interface to this power management feature is available from unprivileged SW (CWE-1256), which would make the attack very easy.


Semiconductor Defects in Hardware Logic with Security-Sensitive Implications

Summary: The security-sensitive hardware module contains semiconductor defects.


Application-Level Admin Tool with Inconsistent View of Underlying Operating System

Summary: The product provides an application for administrators to manage parts of the underlying operating system, but the application does not accurately identify all of the relevant entities or resources that exist in the OS; that is, the application's model of the OS's state is inconsistent with the OS's actual state.


Out-of-bounds Read

OOB read

Shorthand for "Out of bounds" read

Summary: The product reads data past the end, or before the beginning, of the intended buffer.

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

An attacker could get secret values such as cryptographic keys, PII, memory addresses, or other information that could be used in additional attacks.

Out-of-bounds memory could contain memory addresses or other information that can be used to bypass ASLR and other protection mechanisms in order to improve the reliability of exploiting a separate weakness for code execution.

An attacker could cause a segmentation fault or crash by causing memory to be read outside of the bounds of the buffer. This is especially likely when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string.

The read operation could produce other undefined or unexpected results.


Improper Preservation of Consistency Between Independent Representations of Shared State

Summary: The product has or supports multiple distributed components or sub-systems that are each required to keep their own local copy of shared data - such as state or cache - but the product does not ensure that all local copies remain consistent with each other.

Issues related to state and cache - creation,
		preservation, and update - are a significant gap in
		CWE that is expected to be addressed in future
		versions.  It likely has relationships to concurrency
		and synchronization, incorrect behavior order, and
		other areas that already have some coverage in CWE,
		although the focus has typically been on independent
		processes on the same operating system - not on
		independent systems that are all a part of a larger
		system-of-systems.


Mirrored Regions with Different Values

Summary: The product's architecture mirrors regions without ensuring that their contents always stay in sync.

Issues related to state and cache - creation, preservation, and update - are a significant gap in CWE that is expected to be addressed in future versions. It has relationships to concurrency and synchronization, incorrect behavior order, and other areas that already have some coverage in CWE, although the focus has typically been on independent processes on the same operating system - not on independent systems that are all a part of a larger system-of-systems.


CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

Summary: The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.


Incorrect Selection of Fuse Values

Summary: The logic level used to set a system to a secure state relies on a fuse being unblown. An attacker can set the system to an insecure state merely by blowing the fuse.

This entry is still under development and will continue to see updates and content improvements.


Incorrect Comparison Logic Granularity

Summary: The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.

CWE 4.16 removed a demonstrative example for a hardware module because it was inaccurate and unable to be adapted. The CWE team is developing an alternative.


Comparison Logic is Vulnerable to Power Side-Channel Attacks

Summary: A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.

As compromising a security token may result in complete system control, the impacts are relatively universal.


Improper Restriction of Software Interfaces to Hardware Features

Summary:
The product provides software-controllable
			device functionality for capabilities such as power and
			clock management, but it does not properly limit
			functionality that can lead to modification of
			hardware memory or register bits, or the ability to
			observe physical side channels.

Perform a security evaluation of system-level
		architecture and design with software-aided physical attacks
		in scope.


Improper Access Control Applied to Mirrored or Aliased Memory Regions

Summary: Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.


Exposure of Sensitive System Information Due to Uncleared Debug Information

Summary: The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.


Improper Restriction of Security Token Assignment

Summary: The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.

This entry is still under development and will continue to see updates and content improvements. Currently it is expressed as a general absence of a protection mechanism as opposed to a specific mistake, and the entry's name and description could be interpreted as applying to software.


Buffer Over-read

Summary: The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.

These problems may be resultant from missing sentinel values (CWE-463) or trusting a user-influenced input length variable.

By reading out-of-bounds memory, an attacker might be able to get secret values, such as memory addresses, which can be bypass protection mechanisms such as ASLR in order to improve the reliability and likelihood of exploiting a separate weakness to achieve code execution instead of just denial of service.


Improper Handling of Overlap Between Protected Memory Ranges

Summary: The product allows address regions to overlap, which can result in the bypassing of intended memory protection.

Create a high privilege memory block of any arbitrary size. Attempt to create a lower privilege memory block with an overlap of the high privilege memory block. If the creation attempt works, fix the hardware. Repeat the test.

As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.


Improper Handling of Single Event Upsets

Summary: The hardware logic does not effectively handle when single-event upsets (SEUs) occur.


Improper Access Control for Register Interface

Summary: The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.

This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.

Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.

Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.

Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.

Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.

Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.

Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.

Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.


Improper Physical Access Control

Summary: The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.


Hardware Logic with Insecure De-Synchronization between Control and Data Channels

Summary: The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.

As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. As a result, this entry might change significantly in CWE 4.10.


Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls

Summary: During execution of non-reentrant code, the product performs a call that unintentionally produces a nested invocation of the non-reentrant code.

Exploitation of this weakness can leave the application in an unexpected state and cause variables to be reassigned before the first invocation has completed. This may eventually result in memory corruption or unexpected code execution.


Improper Scrubbing of Sensitive Data from Decommissioned Device

Summary: The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned.  A scrubbing capability could be missing, insufficient, or incorrect.


Policy Uses Obsolete Encoding

Summary: The product uses an obsolete encoding mechanism to implement access controls.


Policy Privileges are not Assigned Consistently Between Control and Data Agents

Summary: The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.


Product Released in Non-Release Configuration

Summary: The product released to market is released in pre-production or manufacturing configuration.


Buffer Under-read

Summary: The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.


Generation of Incorrect Security Tokens

Summary: The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.


Uninitialized Value on Reset for Registers Holding Security Settings

Summary: Security-critical logic is not set to a known value on reset.


Sensitive Information Uncleared Before Debug/Power State Transition

Summary: The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.

Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the pattern that was originally written, the test fails and the device needs to be fixed. Note that this test can likely be automated.

Sensitive information may be used to unlock additional capabilities of the device and take advantage of hidden functionalities which could be used to compromise device security.


Device Unlock Credential Sharing

Summary: The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.

Once unlock credentials are compromised, an attacker can use the credentials to unlock the device and gain unauthorized access to the hidden functionalities protected by those credentials.


Improper Access Control for Volatile Memory Containing Boot Code

Summary: The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.

Ensure the volatile memory is lockable or has locks. Ensure the volatile memory is locked for writes from untrusted agents or adversaries. Try modifying the volatile memory from an untrusted agent, and ensure these writes are dropped.


Sensitive Cookie with Improper SameSite Attribute

Summary: The SameSite attribute for sensitive cookies is not set, or an insecure value is used.

If the website does not impose additional defense against CSRF attacks, failing to use the 'Lax' or 'Strict' values could increase the risk of exposure to CSRF attacks. The likelihood of the integrity breach is Low because a successful attack does not only depend on an insecure SameSite attribute. In order to perform a CSRF attack there are many conditions that must be met, such as the lack of CSRF tokens, no confirmations for sensitive actions on the website, a "simple" "Content-Type" header in the HTTP request and many more.


Hardware Child Block Incorrectly Connected to Parent System

Summary: Signals between a hardware IP and the parent system design are incorrectly connected causing security risks.


Firmware Not Updateable

Summary:
The product does not provide its
			users with the ability to update or patch its
			firmware to address any vulnerabilities or
			weaknesses that may be present.

Create a new installable boot image of the current build with a minor version number change. Use the standard installation method to update the boot image. Verify that the minor version number has changed. Create a fake image. Verify that the boot updater will not install the fake image and generates an "invalid image" error message or equivalent.

Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.

Determine if there is a lack of a capability to update read-only memory (ROM) structure. This could manifest as a difference between the latest firmware version and the current version within the device.

The "firmware" term does not have a single commonly-shared definition, so there may be variations in how this CWE entry is interpreted during mapping.

If an attacker can identify an exploitable vulnerability in one device that has no means of patching, the attack may be used against an entire class of devices.


Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques

Summary: Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.

This entry is still under development and will continue to see updates and content improvements. It is more attack-oriented, so it might be more suited for CAPEC.

A common goal of malicious actors who reverse engineer ICs is to produce and sell counterfeit versions of the IC.


Cryptographic Operations are run Before Supporting Units are Ready

Summary: Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.


Wrap-around Error

Summary: Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.

The relationship between overflow and wrap-around needs to be examined more closely, since several entries (including CWE-190) are closely related.

This weakness will generally lead to undefined behavior and therefore crashes. In the case of overflows involving loop index variables, the likelihood of infinite loops is also high.

If the value in question is important to data (as opposed to flow), simple data corruption has occurred. Also, if the wrap around results in other conditions such as buffer overflows, further memory corruption may occur.

This weakness can sometimes trigger buffer overflows which can be used to execute arbitrary code. This is usually outside the scope of a program's implicit security policy.


Access Control Check Implemented After Asset is Accessed

Summary: A product's hardware-based access control check occurs after the asset has been accessed.


Sequence of Processor Instructions Leads to Unexpected Behavior

Summary: Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed.


Assumed-Immutable Data is Stored in Writable Memory

Summary: Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.

This entry is still under development and will continue to
          see updates and content improvements.

As of CWE 4.3, CWE-1282 and CWE-1233 are being investigated
		  for potential duplication or overlap.


Mutable Attestation or Measurement Reporting Data

Summary: The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.

This entry is still in development and will continue to see updates and content improvements.


Improper Validation of Specified Quantity in Input

Summary: The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.

This entry is still under development and will continue to see updates and content improvements.

Since quantities are used so often to affect resource allocation or process financial data, they are often present in many places in the code.


Improper Validation of Specified Index, Position, or Offset in Input

Summary: The product receives input that is expected to specify an index, position, or offset into an indexable resource such as a buffer or file, but it does not validate or incorrectly validates that the specified index/position/offset has the required properties.


Improper Validation of Syntactic Correctness of Input

Summary: The product receives input that is expected to be well-formed - i.e., to comply with a certain syntax - but it does not validate or incorrectly validates that the input complies with the syntax.


Improper Validation of Specified Type of Input

Summary: The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.


Improper Validation of Consistency within Input

Summary: The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.


Improper Validation of Unsafe Equivalence in Input

Summary: The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.


Improper Validation of Array Index

Summary: The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Black box methods might not get the needed code coverage within limited time constraints, and a dynamic test might not produce any noticeable side effects even if it is successful.

This weakness can precede uncontrolled memory allocation (CWE-789) in languages that automatically expand an array when an index is used that is larger than the size of the array, such as JavaScript.

An improperly validated array index might lead directly to the always-incorrect behavior of "access of array using out-of-bounds index."

Use of an index that is outside the bounds of an array will very likely result in the corruption of relevant memory and perhaps instructions, leading to a crash, if the values are outside of the valid memory area.

If the memory corrupted is data, rather than instructions, the system will continue to function with improper values.

Use of an index that is outside the bounds of an array can also trigger out-of-bounds read or write operations, or operations on the wrong objects; i.e., "buffer overflows" are not always the result. This may result in the exposure or modification of sensitive data.

If the memory accessible by the attacker can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow and possibly without the use of large inputs if a precise index can be controlled.

A single fault could allow either an overflow (CWE-788) or underflow (CWE-786) of the array index. What happens next will depend on the type of operation being performed out of bounds, but can expose sensitive information, cause a system crash, or possibly lead to arbitrary code execution.


Incorrect Decoding of Security Identifiers

Summary: The product implements a decoding mechanism to decode certain bus-transaction signals to security identifiers. If the decoding is implemented incorrectly, then untrusted agents can now gain unauthorized access to the asset.


Public Key Re-Use for Signing both Debug and Production Code

Summary: The same public key is used for signing both debug and production code.


Incorrect Conversion of Security Identifiers

Summary: The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers. However, if the conversion is incorrectly implemented, untrusted agents can gain unauthorized access to the asset.


Missing Source Correlation of Multiple Independent Data

Summary: The product relies on one source of data, preventing the ability to detect if an adversary has compromised a data source.

An attacker that may be able to execute a single Person-in-the-Middle attack can subvert a check of an external oracle (e.g. the ACME protocol check for a file on a website), and thus inject an arbitrary reply to the single perspective request to the external oracle.


Insecure Security Identifier Mechanism

Summary: The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.


Debug Messages Revealing Unnecessary Information

Summary: The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.


Incorrect Chaining or Granularity of Debug Components

Summary: The product's debug components contain incorrect chaining or granularity of debug components.

Appropriate Post-Si tests should be carried out at various authorization levels to ensure that debug components are properly chained and accessible only to users with appropriate credentials.

Depending on the access to debug component(s) erroneously granted, an attacker could use the debug component to gain additional understanding about the system to further an attack and/or execute other commands. This could compromise any security property, including the ones listed above.


Unprotected Confidential Information on Device is Accessible by OSAT Vendors

Summary: The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.

Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.

This entry might be subject to CWE Scope Exclusion SCOPE.SITUATIONS (Focus on situations in which weaknesses may appear); SCOPE.HUMANPROC (Human/organizational process; and/or SCOPE.CUSTREL (Not customer-relevant).

The impact depends on the confidential information itself and who is inadvertently granted access. For example, if the confidential information is a key that can unlock all the parts of a generation, the impact could be severe.


Hardware Logic Contains Race Conditions

Summary: A race condition in the hardware logic results in undermining security guarantees of the system.


Missing Protection Mechanism for Alternate Hardware Interface

Summary:
The lack of protections on alternate paths to access
                control-protected assets (such as unprotected shadow registers
                and other external facing unguarded interfaces) allows an
                attacker to bypass existing protections to the asset that are
		only performed against the primary path.


ASP.NET Misconfiguration: Password in Configuration File

Summary: Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.


Improper Handling of Length Parameter Inconsistency

Summary: The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.

This probably overlaps other categories including zero-length issues.


Improper Protection of Physical Side Channels

Summary:
The device does not contain sufficient protection
	mechanisms to prevent physical side channels from exposing
	sensitive information due to patterns in physically observable
	phenomena such as variations in power consumption,
	electromagnetic emissions (EME), or acoustic emissions.

Perform a set of leakage detection tests such as the procedure outlined in the Test Vector Leakage Assessment (TVLA) test requirements for AES [REF-1230].  TVLA is the basis for the ISO standard 17825 [REF-1229]. A separate methodology is provided by [REF-1228]. Note that sole reliance on this method might not yield expected results [REF-1239] [REF-1240].


Insufficient or Incomplete Data Removal within Hardware Component

Summary: The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.


Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC)

Summary: The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier.


Non-Transparent Sharing of Microarchitectural Resources

Summary: Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.

As of CWE 4.9, members of the CWE Hardware SIG are closely analyzing this entry and others to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks. Additional investigation may include other weaknesses related to microarchitectural state. Finally, this entry's demonstrative example might not be appropriate. As a result, this entry might change significantly in CWE 4.10.

Microarchitectural side-channels have been used to leak specific information such as cryptographic keys, and Address Space Layout Randomization (ALSR) offsets as well as arbitrary memory.


Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation

Summary:
The product performs a power save/restore
            operation, but it does not ensure that the integrity of
            the configuration state is maintained and/or verified between
	    the beginning and ending of the operation.


Incorrect Calculation of Buffer Size

Summary: The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow.

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

If the incorrect calculation is used in the context of memory allocation, then the software may create a buffer that is smaller or larger than expected. If the allocated buffer is smaller than expected, this could lead to an out-of-bounds read or write (CWE-119), possibly causing a crash, allowing arbitrary code execution, or exposing sensitive data.


Missing Ability to Patch ROM Code

Summary: Missing an ability to patch ROM code may leave a System or System-on-Chip (SoC) in a vulnerable state.

When the system is unable to be patched, it can be left in a vulnerable state.


Improper Translation of Security Attributes by Fabric Bridge

Summary: The bridge incorrectly translates security attributes from either trusted to untrusted or from untrusted to trusted when converting from one fabric protocol to another.


Missing Protection for Mirrored Regions in On-Chip Fabric Firewall

Summary: The firewall in an on-chip fabric protects the main addressed region, but it does not protect any mirrored memory or memory-mapped-IO (MMIO) regions.

Using an external debugger, send write transactions to mirrored regions to test if original, write-protected regions are modified. Similarly, send read transactions to mirrored regions to test if the original, read-protected signals can be read.


Hardware Allows Activation of Test or Debug Logic at Runtime

Summary: During runtime, the hardware allows for test or debug logic (feature) to be activated, which allows for changing the state of the hardware. This feature can alter the intended behavior of the system and allow for alteration and leakage of sensitive data by an adversary.


Missing Write Protection for Parametric Data Values

Summary: The device does not write-protect the parametric data values for sensors that scale the sensor value, allowing untrusted software to manipulate the apparent result and potentially damage hardware or cause operational failure.

Sensor value manipulation, particularly thermal or power, may allow physical damage to occur or disabling of the device by a false fault shutdown causing a Denial-Of-Service.


Improper Setting of Bus Controlling Capability in Fabric End-point

Summary: The bus controller enables bits in the fabric end-point to allow responder devices to control transactions on the fabric.


Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges

Summary: The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.

Review address map in specification to see if there are any overlapping ranges.

Negative testing of access control on overlapped ranges.

As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.


Improper Access Control in Fabric Bridge

Summary: The product uses a fabric bridge for transactions between two Intellectual Property (IP) blocks, but the bridge does not properly perform the expected privilege, identity, or other access control checks between those IP blocks.

RTL simulation to ensure that bridge-access controls are implemented properly.

Formal verification of bridge RTL to ensure that access control cannot be bypassed.


Missing Support for Security Features in On-chip Fabrics or Buses

Summary: On-chip fabrics or buses either do not support or are not configured to support privilege separation or other security features, such as access control.

Review the fabric specification and ensure that it contains signals to transfer security-sensitive signals.

Lack of security features can also be confirmed through manual RTL review of the fabric RTL.


Improper Protection against Electromagnetic Fault Injection (EM-FI)

Summary: The device is susceptible to electromagnetic fault injection attacks, causing device internal information to be compromised or security mechanisms to be bypassed.

This entry is attack-oriented and may require significant modification in future versions, or even deprecation. It is not clear whether there is really a design "mistake" that enables such attacks, so this is not necessarily a weakness and may be more appropriate for CAPEC.


DEPRECATED: Miscalculated Null Termination

Summary: This entry has been deprecated because it was a duplicate of CWE-170. All content has been transferred to CWE-170.


Improper Protection for Outbound Error Messages and Alert Signals

Summary: Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.


Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Summary: The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.

An attacker can inject attributes that are used in other components.

An attacker can override existing attributes with ones that have incompatible type, which may lead to a crash.


Use of Blocking Code in Single-threaded, Non-blocking Context

Summary:
The product uses a non-blocking model that relies on a single threaded process
			for features such as scalability, but it contains code that can block when it is invoked.

An unexpected call to blocking code can trigger an infinite loop, or a large loop that causes the software to pause and wait indefinitely.


Improper Management of Sensitive Trace Data

Summary:
Trace data collected from several sources on the
                System-on-Chip (SoC) is stored in unprotected locations or
                transported to untrusted agents.

An adversary can read secret values if they are captured in debug traces and stored unsafely.


DEPRECATED: Sensitive Information Accessible by Physical Probing of JTAG Interface

Summary: This entry has been deprecated because it was at a lower level of abstraction than supported by CWE. All relevant content has been integrated into CWE-319.