CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-1008: Architectural Concepts (3.0)  
ID

CWE VIEW: Architectural Concepts

View ID: 1008
Type: Graph
Status: Incomplete
+ Objective
This view organizes weaknesses according to common architectural security tactics. It is intended to assist architects in identifying potential weaknesses when designing software. The top level categories in this view represent the individual tactics that are part of a secure-by-design approach to software development. The weaknesses that are members of each category contain information about how each is introduced relative to the software's architecture. Three different modes of introduction are used: Omission - caused by missing a security tactic when it is necessary. Commission - refers to incorrect choice of tactics which could result in undesirable consequences. Realization - appropriate security tactics are adopted but are incorrectly implemented.
+ Audience
StakeholderDescription
Software DesignersSoftware designers may find this view useful as the weaknesses are organized by known security tactics, aiding the designer in imbedding security throughout the design process instead of discovering weaknesses after the software has been built.
EducatorsSince Architectural Concepts covers weaknesses based on security tactics, educators may use this view as reference material when discussing security by design or architectural weaknesses.
+ Relationships
Show Details:
1008 - Architectural Concepts
+CategoryCategoryAudit - (1009)
1008 (Architectural Concepts) > 1009 (Audit)
Weaknesses in this category are related to the design and architecture of audit-based components of the system. Frequently these deal with logging user activities in order to identify attackers and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed when designing or implementing a secure architecture.
*BaseBaseImproper Output Neutralization for Logs - (117)
1008 (Architectural Concepts) > 1009 (Audit) > 117 (Improper Output Neutralization for Logs)
The software does not neutralize or incorrectly neutralizes output that is written to logs.
*BaseBaseOmission of Security-relevant Information - (223)
1008 (Architectural Concepts) > 1009 (Audit) > 223 (Omission of Security-relevant Information)
The application does not record or display information that would be important for identifying the source or nature of an attack, or determining if an action is safe.
*BaseBaseObscured Security-relevant Information by Alternate Name - (224)
1008 (Architectural Concepts) > 1009 (Audit) > 224 (Obscured Security-relevant Information by Alternate Name)
The software records security-relevant information according to an alternate name of the affected entity, instead of the canonical name.
*VariantVariantInformation Exposure Through Log Files - (532)
1008 (Architectural Concepts) > 1009 (Audit) > 532 (Information Exposure Through Log Files)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*BaseBaseInsufficient Logging - (778)
1008 (Architectural Concepts) > 1009 (Audit) > 778 (Insufficient Logging)
When a security-critical event occurs, the software either does not record the event or omits important details about the event when logging it.
*BaseBaseLogging of Excessive Data - (779)
1008 (Architectural Concepts) > 1009 (Audit) > 779 (Logging of Excessive Data)
The software logs too much information, making log files hard to process and possibly hindering recovery efforts or forensic analysis after an attack.
+CategoryCategoryAuthenticate Actors - (1010)
1008 (Architectural Concepts) > 1010 (Authenticate Actors)
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is indeed who it claims to be. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
*VariantVariantEmpty Password in Configuration File - (258)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 258 (Empty Password in Configuration File)
Using an empty string as a password is insecure.
*BaseBaseUse of Hard-coded Password - (259)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 259 (Use of Hard-coded Password)
The software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
*VariantVariantNot Using Password Aging - (262)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 262 (Not Using Password Aging)
If no mechanism is in place for managing password aging, users will have no incentive to update passwords in a timely manner.
*BaseBasePassword Aging with Long Expiration - (263)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 263 (Password Aging with Long Expiration)
Allowing password aging to occur unchecked can result in the possibility of diminished password integrity.
*ClassClassImproper Authentication - (287)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 287 (Improper Authentication)
When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.authentificationAuthC
*BaseBaseAuthentication Bypass Using an Alternate Path or Channel - (288)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 288 (Authentication Bypass Using an Alternate Path or Channel)
A product requires authentication, but the product has an alternate path or channel that does not require authentication.
*VariantVariantAuthentication Bypass by Alternate Name - (289)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 289 (Authentication Bypass by Alternate Name)
The software performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
*BaseBaseAuthentication Bypass by Spoofing - (290)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 290 (Authentication Bypass by Spoofing)
This attack-focused weakness is caused by improperly implemented authentication schemes that are subject to spoofing attacks.
*VariantVariantReliance on IP Address for Authentication - (291)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 291 (Reliance on IP Address for Authentication)
The software uses an IP address for authentication.
*VariantVariantUsing Referer Field for Authentication - (293)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 293 (Using Referer Field for Authentication)
The referer field in HTTP requests can be easily modified and, as such, is not a valid means of message integrity checking.referrer
*BaseBaseAuthentication Bypass by Capture-replay - (294)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 294 (Authentication Bypass by Capture-replay)
A capture-replay flaw exists when the design of the software makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
*VariantVariantReflection Attack in an Authentication Protocol - (301)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 301 (Reflection Attack in an Authentication Protocol)
Simple authentication protocols are subject to reflection attacks if a malicious user can use the target machine to impersonate a trusted user.
*VariantVariantAuthentication Bypass by Assumed-Immutable Data - (302)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 302 (Authentication Bypass by Assumed-Immutable Data)
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
*BaseBaseIncorrect Implementation of Authentication Algorithm - (303)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 303 (Incorrect Implementation of Authentication Algorithm)
The requirements for the software dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
*BaseBaseMissing Critical Step in Authentication - (304)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 304 (Missing Critical Step in Authentication)
The software implements an authentication technique, but it skips a step that weakens the technique.
*BaseBaseAuthentication Bypass by Primary Weakness - (305)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 305 (Authentication Bypass by Primary Weakness)
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
*VariantVariantMissing Authentication for Critical Function - (306)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 306 (Missing Authentication for Critical Function)
The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
*BaseBaseImproper Restriction of Excessive Authentication Attempts - (307)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 307 (Improper Restriction of Excessive Authentication Attempts)
The software does not implement sufficient measures to prevent multiple failed authentication attempts within in a short time frame, making it more susceptible to brute force attacks.
*BaseBaseUse of Single-factor Authentication - (308)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 308 (Use of Single-factor Authentication)
The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
*BaseBaseKey Exchange without Entity Authentication - (322)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 322 (Key Exchange without Entity Authentication)
The software performs a key exchange with an actor without verifying the identity of that actor.
*BaseBaseWeak Password Requirements - (521)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 521 (Weak Password Requirements)
The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts.
*VariantVariantAuthentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created - (593)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 593 (Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created)
The software modifies the SSL context after connection creation has begun.
*BaseBaseUse of Client-Side Authentication - (603)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 603 (Use of Client-Side Authentication)
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.
*VariantVariantUnverified Password Change - (620)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 620 (Unverified Password Change)
When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication.
*BaseBaseWeak Password Recovery Mechanism for Forgotten Password - (640)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 640 (Weak Password Recovery Mechanism for Forgotten Password)
The software contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
*BaseBaseUse of Hard-coded Credentials - (798)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 798 (Use of Hard-coded Credentials)
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
*BaseBaseUse of Password Hash Instead of Password for Authentication - (836)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 836 (Use of Password Hash Instead of Password for Authentication)
The software records password hashes in a data store, receives a hash of a password from a client, and compares the supplied hash to the hash obtained from the data store.
*BaseBaseUse of Password Hash With Insufficient Computational Effort - (916)
1008 (Architectural Concepts) > 1010 (Authenticate Actors) > 916 (Use of Password Hash With Insufficient Computational Effort)
The software generates a hash for a password, but it uses a scheme that does not provide a sufficient level of computational effort that would make password cracking attacks infeasible or expensive.
+CategoryCategoryAuthorize Actors - (1011)
1008 (Architectural Concepts) > 1011 (Authorize Actors)
Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have the required permissions before performing certain operations, such as modifying data. The weaknesses in this category could lead to a degredation of quality of the authorization capability if they are not addressed when designing or implementing a secure architecture.
*BaseBaseProcess Control - (114)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 114 (Process Control)
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.
*BaseBaseExternal Control of System or Configuration Setting - (15)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 15 (External Control of System or Configuration Setting)
One or more system settings or configuration elements can be externally controlled by a user.
*VariantVariantSensitive Data Under Web Root - (219)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 219 (Sensitive Data Under Web Root)
The application stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
*VariantVariantSensitive Data Under FTP Root - (220)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 220 (Sensitive Data Under FTP Root)
The application stores sensitive data under the FTP document root with insufficient access control, which might make it accessible to untrusted parties.
*BaseBaseIncorrect Privilege Assignment - (266)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 266 (Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
*BaseBasePrivilege Defined With Unsafe Actions - (267)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 267 (Privilege Defined With Unsafe Actions)
A particular privilege, role, capability, or right can be used to perform unsafe actions that were not intended, even when it is assigned to the correct entity.
*BaseBasePrivilege Chaining - (268)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 268 (Privilege Chaining)
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
*ClassClassImproper Privilege Management - (269)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 269 (Improper Privilege Management)
The software does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
*BaseBasePrivilege Context Switching Error - (270)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 270 (Privilege Context Switching Error)
The software does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.
*ClassClassPrivilege Dropping / Lowering Errors - (271)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 271 (Privilege Dropping / Lowering Errors)
The software does not drop privileges before passing control of a resource to an actor that does not have those privileges.
*BaseBaseLeast Privilege Violation - (272)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 272 (Least Privilege Violation)
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
*BaseBaseImproper Check for Dropped Privileges - (273)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 273 (Improper Check for Dropped Privileges)
The software attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.
*BaseBaseImproper Handling of Insufficient Privileges - (274)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 274 (Improper Handling of Insufficient Privileges)
The software does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.
*VariantVariantIncorrect Default Permissions - (276)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 276 (Incorrect Default Permissions)
The software, upon installation, sets incorrect permissions for an object that exposes it to an unintended actor.
*VariantVariantInsecure Inherited Permissions - (277)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 277 (Insecure Inherited Permissions)
A product defines a set of insecure permissions that are inherited by objects that are created by the program.
*VariantVariantIncorrect Execution-Assigned Permissions - (279)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 279 (Incorrect Execution-Assigned Permissions)
While it is executing, the software sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
*BaseBaseImproper Handling of Insufficient Permissions or Privileges - (280)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 280 (Improper Handling of Insufficient Permissions or Privileges )
The application does not handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the application in an invalid state.
*BaseBaseImproper Preservation of Permissions - (281)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 281 (Improper Preservation of Permissions)
The software does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.
*ClassClassImproper Ownership Management - (282)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 282 (Improper Ownership Management)
The software assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.
*BaseBaseUnverified Ownership - (283)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 283 (Unverified Ownership)
The software does not properly verify that a critical resource is owned by the proper entity.
*ClassClassImproper Access Control - (284)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 284 (Improper Access Control)
The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.Authorization
*ClassClassImproper Authorization - (285)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 285 (Improper Authorization)
The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.AuthZ
*ClassClassIncorrect User Management - (286)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 286 (Incorrect User Management)
The software does not properly manage a user within its environment.
*ClassClassChannel Accessible by Non-Endpoint ('Man-in-the-Middle') - (300)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle'))
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.
*BaseBasePredictable from Observable State - (341)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 341 (Predictable from Observable State)
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
*ClassClassExposure of Private Information ('Privacy Violation') - (359)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 359 (Exposure of Private Information ('Privacy Violation'))
The software does not properly prevent private data (such as credit card numbers) from being accessed by actors who either (1) are not explicitly authorized to access the data or (2) do not have the implicit consent of the people to which the data is related.Privacy leakPrivacy leakage
*BaseBaseExposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') - (403)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 403 (Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))
A process does not close sensitive file descriptors before invoking a child process, which allows the child to perform unauthorized I/O operations using those descriptors.File descriptor leak
*BaseBaseUnprotected Primary Channel - (419)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 419 (Unprotected Primary Channel)
The software uses a primary channel for administration or restricted functionality, but it does not properly protect the channel.
*BaseBaseUnprotected Alternate Channel - (420)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 420 (Unprotected Alternate Channel)
The software protects a primary channel, but it does not use the same level of protection for an alternate channel.
*BaseBaseDirect Request ('Forced Browsing') - (425)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 425 (Direct Request ('Forced Browsing'))
The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.forced browsing
*CompositeCompositeUntrusted Search Path - (426)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 426 (Untrusted Search Path)
The application searches for critical resources using an externally-supplied search path that can point to resources that are not under the application's direct control.Untrusted Path
*BaseBaseUnrestricted Upload of File with Dangerous Type - (434)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 434 (Unrestricted Upload of File with Dangerous Type)
The software allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment.Unrestricted File Upload
*VariantVariantExposure of CVS Repository to an Unauthorized Control Sphere - (527)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 527 (Exposure of CVS Repository to an Unauthorized Control Sphere)
The product stores a CVS repository in a directory or other container that is accessible to actors outside of the intended control sphere.
*VariantVariantExposure of Core Dump File to an Unauthorized Control Sphere - (528)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere)
The product generates a core dump file in a directory that is accessible to actors outside of the intended control sphere.
*VariantVariantExposure of Access Control List Files to an Unauthorized Control Sphere - (529)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 529 (Exposure of Access Control List Files to an Unauthorized Control Sphere)
The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.
*VariantVariantExposure of Backup File to an Unauthorized Control Sphere - (530)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 530 (Exposure of Backup File to an Unauthorized Control Sphere)
A backup file is stored in a directory that is accessible to actors outside of the intended control sphere.
*BaseBaseFile and Directory Information Exposure - (538)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 538 (File and Directory Information Exposure)
The product stores sensitive information in files or directories that are accessible to actors outside of the intended control sphere.
*BaseBaseIncorrect Behavior Order: Authorization Before Parsing and Canonicalization - (551)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 551 (Incorrect Behavior Order: Authorization Before Parsing and Canonicalization)
If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.
*BaseBaseFiles or Directories Accessible to External Parties - (552)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 552 (Files or Directories Accessible to External Parties)
Files or directories are accessible in the environment that should not be.
*VariantVariantAuthorization Bypass Through User-Controlled SQL Primary Key - (566)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 566 (Authorization Bypass Through User-Controlled SQL Primary Key)
The software uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
*BaseBaseAuthorization Bypass Through User-Controlled Key - (639)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 639 (Authorization Bypass Through User-Controlled Key)
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.Insecure Direct Object ReferenceHorizontal Authorization
*ClassClassExternal Control of Critical State Data - (642)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 642 (External Control of Critical State Data)
The software stores security-critical state information about its users, or the software itself, in a location that is accessible to unauthorized actors.
*VariantVariantUse of Non-Canonical URL Paths for Authorization Decisions - (647)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 647 (Use of Non-Canonical URL Paths for Authorization Decisions)
The software defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
*BaseBaseInsufficient Compartmentalization - (653)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 653 (Insufficient Compartmentalization)
The product does not sufficiently compartmentalize functionality or processes that require different privilege levels, rights, or permissions.Separation of Privilege
*BaseBaseReliance on Security Through Obscurity - (656)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 656 (Reliance on Security Through Obscurity)
The software uses a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism.Never Assuming your secrets are safe
*ClassClassExposure of Resource to Wrong Sphere - (668)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 668 (Exposure of Resource to Wrong Sphere)
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
*ClassClassIncorrect Resource Transfer Between Spheres - (669)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 669 (Incorrect Resource Transfer Between Spheres)
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
*ClassClassLack of Administrator Control over Security - (671)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 671 (Lack of Administrator Control over Security)
The product uses security features in a way that prevents the product's administrator from tailoring security settings to reflect the environment in which the product is being used. This introduces resultant weaknesses or prevents it from operating at a level of security that is desired by the administrator.
*ClassClassExternal Influence of Sphere Definition - (673)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 673 (External Influence of Sphere Definition)
The product does not prevent the definition of control spheres from external actors.
*BaseBaseIncorrect Ownership Assignment - (708)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 708 (Incorrect Ownership Assignment)
The software assigns an owner to a resource, but the owner is outside of the intended control sphere.
*ClassClassIncorrect Permission Assignment for Critical Resource - (732)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
*BaseBaseAllocation of Resources Without Limits or Throttling - (770)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 770 (Allocation of Resources Without Limits or Throttling)
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
*VariantVariantExposed IOCTL with Insufficient Access Control - (782)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 782 (Exposed IOCTL with Insufficient Access Control)
The software implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.
*BaseBaseImproper Control of Document Type Definition - (827)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 827 (Improper Control of Document Type Definition)
The software does not restrict a reference to a Document Type Definition (DTD) to the intended control sphere. This might allow attackers to reference arbitrary DTDs, possibly causing the software to expose files, consume excessive system resources, or execute arbitrary http requests on behalf of the attacker.
*ClassClassMissing Authorization - (862)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 862 (Missing Authorization)
The software does not perform an authorization check when an actor attempts to access a resource or perform an action.AuthZ
*ClassClassIncorrect Authorization - (863)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 863 (Incorrect Authorization)
The software performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.AuthZ
*BaseBaseStorage of Sensitive Data in a Mechanism without Access Control - (921)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 921 (Storage of Sensitive Data in a Mechanism without Access Control)
The software stores sensitive information in a file system or device that does not have built-in access control.
*ClassClassImproper Restriction of Communication Channel to Intended Endpoints - (923)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 923 (Improper Restriction of Communication Channel to Intended Endpoints)
The software establishes a communication channel to (or from) an endpoint for privileged or protected operations, but it does not properly ensure that it is communicating with the correct endpoint.
*BaseBaseImproper Authorization in Handler for Custom URL Scheme - (939)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 939 (Improper Authorization in Handler for Custom URL Scheme)
The software uses a handler for a custom URL scheme, but it does not properly restrict which actors can invoke the handler using the scheme.
*VariantVariantOverly Permissive Cross-domain Whitelist - (942)
1008 (Architectural Concepts) > 1011 (Authorize Actors) > 942 (Overly Permissive Cross-domain Whitelist)
The software uses a cross-domain policy file that includes domains that should not be trusted.
+CategoryCategoryCross Cutting - (1012)
1008 (Architectural Concepts) > 1012 (Cross Cutting)
Weaknesses in this category are related to the design and architecture of multiple security tactics and how they affect a system. For example, information exposure can impact the Limit Access and Limit Exposure security tactics. The weaknesses in this category could lead to a degradation of the quality of many capabilities if they are not addressed when designing or implementing a secure architecture.
*BaseBaseInformation Exposure Through Timing Discrepancy - (208)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 208 (Information Exposure Through Timing Discrepancy)
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
*BaseBaseMissing Report of Error Condition - (392)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 392 (Missing Report of Error Condition)
The software encounters an error but does not provide a status code or return value to indicate that an error has occurred.
*VariantVariantImproper Cleanup on Thrown Exception - (460)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 460 (Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
*BaseBaseMissing Standardized Error Handling Mechanism - (544)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 544 (Missing Standardized Error Handling Mechanism)
The software does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
*BaseBaseClient-Side Enforcement of Server-Side Security - (602)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 602 (Client-Side Enforcement of Server-Side Security)
The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
*ClassClassImproper Check or Handling of Exceptional Conditions - (703)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 703 (Improper Check or Handling of Exceptional Conditions)
The software does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the software.
*ClassClassImproper Check for Unusual or Exceptional Conditions - (754)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 754 (Improper Check for Unusual or Exceptional Conditions)
The software does not check or improperly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the software.
*VariantVariantReliance on Cookies without Validation and Integrity Checking in a Security Decision - (784)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 784 (Reliance on Cookies without Validation and Integrity Checking in a Security Decision)
The application uses a protection mechanism that relies on the existence or values of a cookie, but it does not properly ensure that the cookie is valid for the associated user.
*BaseBaseReliance on Untrusted Inputs in a Security Decision - (807)
1008 (Architectural Concepts) > 1012 (Cross Cutting) > 807 (Reliance on Untrusted Inputs in a Security Decision)
The application uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
+CategoryCategoryEncrypt Data - (1013)
1008 (Architectural Concepts) > 1013 (Encrypt Data)
Weaknesses in this category are related to the design and architecture of data confidentiality in a system. Frequently these deal with the use of encryption libraries. The weaknesses in this category could lead to a degradation of the quality data encyprtion if they are not addressed when designing or implementing a secure architecture.
*VariantVariantPlaintext Storage of a Password - (256)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 256 (Plaintext Storage of a Password)
Storing a password in plaintext may result in a system compromise.
*BaseBaseStoring Passwords in a Recoverable Format - (257)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 257 (Storing Passwords in a Recoverable Format)
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.
*VariantVariantPassword in Configuration File - (260)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 260 (Password in Configuration File)
The software stores a password in a configuration file that might be accessible to actors who do not know the password.
*VariantVariantWeak Cryptography for Passwords - (261)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 261 (Weak Cryptography for Passwords)
Obscuring a password with a trivial encoding does not protect the password.
*BaseBaseMissing Encryption of Sensitive Data - (311)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 311 (Missing Encryption of Sensitive Data)
The software does not encrypt sensitive or critical information before storage or transmission.
*BaseBaseCleartext Storage of Sensitive Information - (312)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 312 (Cleartext Storage of Sensitive Information)
The application stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
*VariantVariantCleartext Storage in a File or on Disk - (313)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 313 (Cleartext Storage in a File or on Disk)
The application stores sensitive information in cleartext in a file, or on disk.
*VariantVariantCleartext Storage in the Registry - (314)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 314 (Cleartext Storage in the Registry)
The application stores sensitive information in cleartext in the registry.
*VariantVariantCleartext Storage of Sensitive Information in a Cookie - (315)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 315 (Cleartext Storage of Sensitive Information in a Cookie)
The application stores sensitive information in cleartext in a cookie.
*VariantVariantCleartext Storage of Sensitive Information in Memory - (316)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 316 (Cleartext Storage of Sensitive Information in Memory)
The application stores sensitive information in cleartext in memory.
*VariantVariantCleartext Storage of Sensitive Information in GUI - (317)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 317 (Cleartext Storage of Sensitive Information in GUI)
The application stores sensitive information in cleartext within the GUI.
*VariantVariantCleartext Storage of Sensitive Information in Executable - (318)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 318 (Cleartext Storage of Sensitive Information in Executable)
The application stores sensitive information in cleartext in an executable.
*BaseBaseCleartext Transmission of Sensitive Information - (319)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 319 (Cleartext Transmission of Sensitive Information)
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
*BaseBaseUse of Hard-coded Cryptographic Key - (321)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 321 (Use of Hard-coded Cryptographic Key)
The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered.
*BaseBaseReusing a Nonce, Key Pair in Encryption - (323)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 323 (Reusing a Nonce, Key Pair in Encryption)
Nonces should be used for the present occasion and only once.
*BaseBaseUse of a Key Past its Expiration Date - (324)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 324 (Use of a Key Past its Expiration Date)
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
*BaseBaseMissing Required Cryptographic Step - (325)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 325 (Missing Required Cryptographic Step)
The software does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by that algorithm.
*ClassClassInadequate Encryption Strength - (326)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 326 (Inadequate Encryption Strength)
The software stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
*BaseBaseUse of a Broken or Risky Cryptographic Algorithm - (327)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.
*BaseBaseReversible One-Way Hash - (328)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 328 (Reversible One-Way Hash)
The product uses a hashing algorithm that produces a hash value that can be used to determine the original input, or to find an input that can produce the same hash, more efficiently than brute force techniques.
*ClassClassUse of Insufficiently Random Values - (330)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 330 (Use of Insufficiently Random Values)
The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
*BaseBaseInsufficient Entropy - (331)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 331 (Insufficient Entropy)
The software uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
*VariantVariantInsufficient Entropy in PRNG - (332)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
*VariantVariantImproper Handling of Insufficient Entropy in TRNG - (333)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 333 (Improper Handling of Insufficient Entropy in TRNG)
True random number generators (TRNG) generally have a limited source of entropy and therefore can fail or block.
*BaseBaseSmall Space of Random Values - (334)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 334 (Small Space of Random Values)
The number of possible random values is smaller than needed by the product, making it more susceptible to brute force attacks.
*BaseBaseIncorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) - (335)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG))
The software uses a Pseudo-Random Number Generator (PRNG) that does not correctly manage seeds.
*BaseBaseSame Seed in Pseudo-Random Number Generator (PRNG) - (336)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
*BaseBasePredictable Seed in Pseudo-Random Number Generator (PRNG) - (337)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
*BaseBaseUse of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - (338)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 338 (Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.
*BaseBaseSmall Seed Space in PRNG - (339)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 339 (Small Seed Space in PRNG)
A PRNG uses a relatively small space of seeds.
*BaseBaseImproper Verification of Cryptographic Signature - (347)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 347 (Improper Verification of Cryptographic Signature)
The software does not verify, or incorrectly verifies, the cryptographic signature for data.
*BaseBaseInsufficiently Protected Credentials - (522)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 522 (Insufficiently Protected Credentials)
This weakness occurs when the application transmits or stores authentication credentials and uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
*VariantVariantUnprotected Transport of Credentials - (523)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 523 (Unprotected Transport of Credentials)
Login pages not using adequate measures to protect the user name and password while they are in transit from the client to the server.
*ClassClassSelection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') - (757)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 757 (Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade'))
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
*BaseBaseUse of a One-Way Hash without a Salt - (759)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 759 (Use of a One-Way Hash without a Salt)
The software uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the software does not also use a salt as part of the input.
*BaseBaseUse of a One-Way Hash with a Predictable Salt - (760)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 760 (Use of a One-Way Hash with a Predictable Salt)
The software uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the software uses a predictable salt as part of the input.
*VariantVariantUse of RSA Algorithm without OAEP - (780)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 780 (Use of RSA Algorithm without OAEP)
The software uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
*ClassClassInsecure Storage of Sensitive Information - (922)
1008 (Architectural Concepts) > 1013 (Encrypt Data) > 922 (Insecure Storage of Sensitive Information)
The software stores sensitive information without properly limiting read or write access by unauthorized actors.
+CategoryCategoryIdentify Actors - (1014)
1008 (Architectural Concepts) > 1014 (Identify Actors)
Weaknesses in this category are related to the design and architecture of a system's identification management components. Frequently these deal with verifying that external agents provide inputs into the system. The weaknesses in this category could lead to a degradation of the quality of identification maangment if they are not addressed when designing or implementing a secure architecture.
*BaseBaseImproper Certificate Validation - (295)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 295 (Improper Certificate Validation)
The software does not validate, or incorrectly validates, a certificate.
*BaseBaseImproper Following of a Certificate's Chain of Trust - (296)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 296 (Improper Following of a Certificate's Chain of Trust)
The software does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
*VariantVariantImproper Validation of Certificate with Host Mismatch - (297)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 297 (Improper Validation of Certificate with Host Mismatch)
The software communicates with a host that provides a certificate, but the software does not properly ensure that the certificate is actually associated with that host.
*VariantVariantImproper Validation of Certificate Expiration - (298)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 298 (Improper Validation of Certificate Expiration)
A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age.
*BaseBaseImproper Check for Certificate Revocation - (299)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 299 (Improper Check for Certificate Revocation)
The software does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
*ClassClassInsufficient Verification of Data Authenticity - (345)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 345 (Insufficient Verification of Data Authenticity)
The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
*BaseBaseOrigin Validation Error - (346)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 346 (Origin Validation Error)
The software does not properly verify that the source of data or communication is valid.
*VariantVariantMissing Check for Certificate Revocation after Initial Check - (370)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 370 (Missing Check for Certificate Revocation after Initial Check)
The software does not check the revocation status of a certificate after its initial revocation check, which can cause the software to perform privileged actions even after the certificate is revoked at a later time.
*ClassClassUnintended Proxy or Intermediary ('Confused Deputy') - (441)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
*VariantVariantMissing Validation of OpenSSL Certificate - (599)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 599 (Missing Validation of OpenSSL Certificate)
The software uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.
*BaseBaseImproper Verification of Source of a Communication Channel - (940)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 940 (Improper Verification of Source of a Communication Channel)
The software establishes a communication channel to handle an incoming request that has been initiated by an actor, but it does not properly verify that the request is coming from the expected origin.
*BaseBaseIncorrectly Specified Destination in a Communication Channel - (941)
1008 (Architectural Concepts) > 1014 (Identify Actors) > 941 (Incorrectly Specified Destination in a Communication Channel)
The software creates a communication channel to initiate an outgoing request to an actor, but it does not correctly specify the intended destination for that actor.
+CategoryCategoryLimit Access - (1015)
1008 (Architectural Concepts) > 1015 (Limit Access)
Weaknesses in this category are related to the design and architecture of system resources. Frequently these deal with restricting the amount of resources that are accessed by actors, such as memory, network connections, CPU or access points. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
*VariantVariantInformation Exposure Through Sent Data - (201)
1008 (Architectural Concepts) > 1015 (Limit Access) > 201 (Information Exposure Through Sent Data)
The accidental exposure of sensitive information through sent data refers to the transmission of data which are either sensitive in and of itself or useful in the further exploitation of the system through standard data channels.
*BaseBaseInformation Exposure Through an Error Message - (209)
1008 (Architectural Concepts) > 1015 (Limit Access) > 209 (Information Exposure Through an Error Message)
The software generates an error message that includes sensitive information about its environment, users, or associated data.
*BaseBaseImproper Cross-boundary Removal of Sensitive Data - (212)
1008 (Architectural Concepts) > 1015 (Limit Access) > 212 (Improper Cross-boundary Removal of Sensitive Data)
The software uses a resource that contains sensitive data, but it does not properly remove that data before it stores, transfers, or shares the resource with actors in another control sphere.
*VariantVariantCreation of chroot Jail Without Changing Working Directory - (243)
1008 (Architectural Concepts) > 1015 (Limit Access) > 243 (Creation of chroot Jail Without Changing Working Directory)
The program uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
*ClassClassExecution with Unnecessary Privileges - (250)
1008 (Architectural Concepts) > 1015 (Limit Access) > 250 (Execution with Unnecessary Privileges)
The software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
*ClassClassExternally Controlled Reference to a Resource in Another Sphere - (610)
1008 (Architectural Concepts) > 1015 (Limit Access) > 610 (Externally Controlled Reference to a Resource in Another Sphere)
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
*VariantVariantImproper Restriction of XML External Entity Reference ('XXE') - (611)
1008 (Architectural Concepts) > 1015 (Limit Access) > 611 (Improper Restriction of XML External Entity Reference ('XXE'))
The software processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.XXE
*ClassClassExternal Control of File Name or Path - (73)
1008 (Architectural Concepts) > 1015 (Limit Access) > 73 (External Control of File Name or Path)
The software allows user input to control or influence paths or file names that are used in filesystem operations.
+CategoryCategoryLimit Exposure - (1016)
1008 (Architectural Concepts) > 1016 (Limit Exposure)
Weaknesses in this category are related to the design and architecture of the entry points to a system. Frequently these deal with minimizing the attack surface through designing the system with the least needed amount of entry points. The weaknesses in this category could lead to a degradation of a system's defenses if they are not addressed when designing or implementing a secure architecture.
*BaseBaseInformation Exposure Through Self-generated Error Message - (210)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 210 (Information Exposure Through Self-generated Error Message)
The software identifies an error condition and creates its own diagnostic or error messages that contain sensitive information.
*BaseBaseInformation Exposure Through Externally-Generated Error Message - (211)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 211 (Information Exposure Through Externally-Generated Error Message)
The software performs an operation that triggers an external diagnostic or error message that is not directly generated by the software, such as an error generated by the programming language interpreter that the software uses. The error can contain sensitive system information.
*VariantVariantInformation Exposure Through Process Environment - (214)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 214 (Information Exposure Through Process Environment)
A process is invoked with sensitive arguments, environment variables, or other elements that can be seen by other processes on the operating system.
*VariantVariantInformation Exposure Through Server Error Message - (550)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 550 (Information Exposure Through Server Error Message)
Certain conditions, such as network failure, will cause a server error message to be displayed.
*ClassClassInclusion of Functionality from Untrusted Control Sphere - (829)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 829 (Inclusion of Functionality from Untrusted Control Sphere)
The software imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
*BaseBaseInclusion of Web Functionality from an Untrusted Source - (830)
1008 (Architectural Concepts) > 1016 (Limit Exposure) > 830 (Inclusion of Web Functionality from an Untrusted Source)
The software includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the software, potentially granting total access and control of the software to the untrusted source.
+CategoryCategoryLock Computer - (1017)
1008 (Architectural Concepts) > 1017 (Lock Computer)
Weaknesses in this category are related to the design and architecture of a system's lockout mechanism. Frequently these deal with scenarios that take effect in case of multiple failed attempts to access a given resource. The weaknesses in this category could lead to a degradation of access to system assets if they are not addressed when designing or implementing a secure architecture.
*BaseBaseOverly Restrictive Account Lockout Mechanism - (645)
1008 (Architectural Concepts) > 1017 (Lock Computer) > 645 (Overly Restrictive Account Lockout Mechanism)
The software contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.
+CategoryCategoryManage User Sessions - (1018)
1008 (Architectural Concepts) > 1018 (Manage User Sessions)
Weaknesses in this category are related to the design and architecture of session managment. Frequently these deal with the information or status about each user and their access rights for the duration of multiple requests. The weaknesses in this category could lead to a degradation of the quality of session managment if they are not addressed when designing or implementing a secure architecture.
*CompositeCompositeSession Fixation - (384)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 384 (Session Fixation)
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
*VariantVariantExposure of Data Element to Wrong Session - (488)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 488 (Exposure of Data Element to Wrong Session)
The product does not sufficiently enforce boundaries between the states of different sessions, causing data to be provided to, or used by, the wrong session.
*VariantVariantJ2EE Bad Practices: Non-serializable Object Stored in Session - (579)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 579 (J2EE Bad Practices: Non-serializable Object Stored in Session)
The application stores a non-serializable object as an HttpSession attribute, which can hurt reliability.
*VariantVariantJ2EE Misconfiguration: Insufficient Session-ID Length - (6)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 6 (J2EE Misconfiguration: Insufficient Session-ID Length)
The J2EE application is configured to use an insufficient session ID length.
*BaseBaseInsufficient Session Expiration - (613)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 613 (Insufficient Session Expiration)
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
*BaseBaseImproper Enforcement of Behavioral Workflow - (841)
1008 (Architectural Concepts) > 1018 (Manage User Sessions) > 841 (Improper Enforcement of Behavioral Workflow)
The software supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.
+CategoryCategoryValidate Inputs - (1019)
1008 (Architectural Concepts) > 1019 (Validate Inputs)
Weaknesses in this category are related to the design and architecture of a system's input validation components. Frequently these deal with sanitizing, neutralizing and validating any externally provided inputs to minimize malformed data from entering the system and preventing code injection in the input data. The weaknesses in this category could lead to a degradation of the quality of data flow in a system if they are not addressed when designing or implementing a secure architecture.
*ClassClassImproper Neutralization of Special Elements - (138)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 138 (Improper Neutralization of Special Elements)
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as control elements or syntactic markers when they are sent to a downstream component.
*VariantVariantImproper Neutralization of Escape, Meta, or Control Sequences - (150)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 150 (Improper Neutralization of Escape, Meta, or Control Sequences)
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.
*ClassClassImproper Input Validation - (20)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 20 (Improper Input Validation)
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
*BaseBaseAcceptance of Extraneous Untrusted Data With Trusted Data - (349)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)
The software, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
*CompositeCompositeCross-Site Request Forgery (CSRF) - (352)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 352 (Cross-Site Request Forgery (CSRF))
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.Session RidingCross Site Reference ForgeryXSRF
*BaseBaseExternal Control of Assumed-Immutable Web Parameter - (472)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.Assumed-Immutable Parameter Tampering
*VariantVariantPHP External Variable Modification - (473)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 473 (PHP External Variable Modification)
A PHP application does not properly protect against the modification of variables from external sources, such as query parameters or cookies. This can expose the application to numerous weaknesses that would not exist otherwise.
*VariantVariantDeserialization of Untrusted Data - (502)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 502 (Deserialization of Untrusted Data)
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, Unpickling
*BaseBaseImproper Link Resolution Before File Access ('Link Following') - (59)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The software attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary file
*VariantVariantURL Redirection to Untrusted Site ('Open Redirect') - (601)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 601 (URL Redirection to Untrusted Site ('Open Redirect'))
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.Open RedirectCross-site RedirectCross-domain Redirect
*BaseBaseImproper Restriction of Names for Files and Other Resources - (641)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 641 (Improper Restriction of Names for Files and Other Resources)
The application constructs the name of a file or other resource using input from an upstream component, but it does not restrict or incorrectly restricts the resulting name.
*BaseBaseImproper Neutralization of Data within XPath Expressions ('XPath Injection') - (643)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 643 (Improper Neutralization of Data within XPath Expressions ('XPath Injection'))
The software uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
*BaseBaseImproper Neutralization of Data within XQuery Expressions ('XQuery Injection') - (652)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 652 (Improper Neutralization of Data within XQuery Expressions ('XQuery Injection'))
The software uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.
*ClassClassImproper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') - (74)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))
The software constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
*ClassClassFailure to Sanitize Special Elements into a Different Plane (Special Element Injection) - (75)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 75 (Failure to Sanitize Special Elements into a Different Plane (Special Element Injection))
The software does not adequately filter user-controlled input for special elements with control implications.
*BaseBaseImproper Neutralization of Equivalent Special Elements - (76)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 76 (Improper Neutralization of Equivalent Special Elements)
The software properly neutralizes certain special elements, but it improperly neutralizes equivalent special elements.
*ClassClassImproper Neutralization of Special Elements used in a Command ('Command Injection') - (77)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The software constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
*BaseBaseImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters
*BaseBaseImproper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSCSS
*ClassClassImproper Filtering of Special Elements - (790)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 790 (Improper Filtering of Special Elements)
The software receives data from an upstream component, but does not filter or incorrectly filters special elements before sending it to a downstream component.
*BaseBaseIncomplete Filtering of Special Elements - (791)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 791 (Incomplete Filtering of Special Elements)
The software receives data from an upstream component, but does not completely filter special elements before sending it to a downstream component.
*VariantVariantIncomplete Filtering of One or More Instances of Special Elements - (792)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 792 (Incomplete Filtering of One or More Instances of Special Elements)
The software receives data from an upstream component, but does not completely filter one or more instances of special elements before sending it to a downstream component.
*VariantVariantOnly Filtering One Instance of a Special Element - (793)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 793 (Only Filtering One Instance of a Special Element)
The software receives data from an upstream component, but only filters a single instance of a special element before sending it to a downstream component.
*VariantVariantIncomplete Filtering of Multiple Instances of Special Elements - (794)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 794 (Incomplete Filtering of Multiple Instances of Special Elements)
The software receives data from an upstream component, but does not filter all instances of a special element before sending it to a downstream component.
*BaseBaseOnly Filtering Special Elements at a Specified Location - (795)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 795 (Only Filtering Special Elements at a Specified Location)
The software receives data from an upstream component, but only accounts for special elements at a specified location, thereby missing remaining special elements that may exist before sending it to a downstream component.
*VariantVariantOnly Filtering Special Elements Relative to a Marker - (796)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 796 (Only Filtering Special Elements Relative to a Marker)
The software receives data from an upstream component, but only accounts for special elements positioned relative to a marker (e.g. "at the beginning/end of a string; the second argument"), thereby missing remaining special elements that may exist before sending it to a downstream component.
*VariantVariantOnly Filtering Special Elements at an Absolute Position - (797)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 797 (Only Filtering Special Elements at an Absolute Position)
The software receives data from an upstream component, but only accounts for special elements at an absolute position (e.g. "byte number 10"), thereby missing remaining special elements that may exist before sending it to a downstream component.
*BaseBaseArgument Injection or Modification - (88)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 88 (Argument Injection or Modification)
The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
*BaseBaseImproper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
*BaseBaseImproper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))
The software constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.
*BaseBaseXML Injection (aka Blind XPath Injection) - (91)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 91 (XML Injection (aka Blind XPath Injection))
The software does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
*BaseBaseImproper Neutralization of CRLF Sequences ('CRLF Injection') - (93)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 93 (Improper Neutralization of CRLF Sequences ('CRLF Injection'))
The software uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
*ClassClassImproper Control of Generation of Code ('Code Injection') - (94)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 94 (Improper Control of Generation of Code ('Code Injection'))
The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
*ClassClassImproper Neutralization of Special Elements in Data Query Logic - (943)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 943 (Improper Neutralization of Special Elements in Data Query Logic)
The application generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.
*BaseBaseImproper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') - (95)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
*BaseBaseImproper Neutralization of Directives in Statically Saved Code ('Static Code Injection') - (96)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 96 (Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection'))
The software receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before inserting the input into an executable resource, such as a library, configuration file, or template.
*VariantVariantImproper Neutralization of Server-Side Includes (SSI) Within a Web Page - (97)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 97 (Improper Neutralization of Server-Side Includes (SSI) Within a Web Page)
The software generates a web page, but does not neutralize or incorrectly neutralizes user-controllable input that could be interpreted as a server-side include (SSI) directive.
*BaseBaseImproper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') - (98)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 98 (Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion'))
The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in "require," "include," or similar functions.Remote file includeRFILocal file inclusion
*BaseBaseImproper Control of Resource Identifiers ('Resource Injection') - (99)
1008 (Architectural Concepts) > 1019 (Validate Inputs) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))
The software receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.Insecure Direct Object Reference
+CategoryCategoryVerify Message Integrity - (1020)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity)
Weaknesses in this category are related to the design and architecture of a system's data integrity components. Frequently these deal with ensuring integrity of data, such as messages, resource files, deployment files, and configuration files. The weaknesses in this category could lead to a degradation of data integrity quality if they are not addressed when designing or implementing a secure architecture.
*BaseBaseMissing Support for Integrity Check - (353)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 353 (Missing Support for Integrity Check)
The software uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
*BaseBaseImproper Validation of Integrity Check Value - (354)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 354 (Improper Validation of Integrity Check Value)
The software does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
*ClassClassDetection of Error Condition Without Action - (390)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 390 (Detection of Error Condition Without Action)
The software detects a specific error, but takes no actions to handle the error.
*BaseBaseUnchecked Error Condition - (391)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 391 (Unchecked Error Condition)
Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
*BaseBaseDownload of Code Without Integrity Check - (494)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 494 (Download of Code Without Integrity Check)
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
*BaseBaseReliance on Cookies without Validation and Integrity Checking - (565)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 565 (Reliance on Cookies without Validation and Integrity Checking)
The application relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.
*BaseBaseReliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking - (649)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 649 (Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking)
The software uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the software does not use integrity checks to detect if those inputs have been modified.
*ClassClassImproper Enforcement of Message or Data Structure - (707)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 707 (Improper Enforcement of Message or Data Structure)
The software does not enforce or incorrectly enforces that structured messages or data are well-formed before being read from an upstream component or sent to a downstream component.
*ClassClassImproper Handling of Exceptional Conditions - (755)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 755 (Improper Handling of Exceptional Conditions)
The software does not handle or incorrectly handles an exceptional condition.
*ClassClassImproper Enforcement of Message Integrity During Transmission in a Communication Channel - (924)
1008 (Architectural Concepts) > 1020 (Verify Message Integrity) > 924 (Improper Enforcement of Message Integrity During Transmission in a Communication Channel)
The software establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission.
+ Notes

Maintenance

This view is under development, and subsequent releases will focus on reviewing the individual weaknesses to verify their inclusion in this view and adding any applicable ChildOf relationships. Comments about revisions are welcome.
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2017-06-22Joanna C.S. Santos, Mehdi Mirakhorli
Provided the catalog, Common Architectural Weakness Enumeration (CAWE), and research papers for this view.
+ View Metrics
CWEs in this viewTotal CWEs
Total235out of982
Weaknesses223out of 714
Categories12out of 237
Views0out of 31

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

Weakness ID: 349
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass345Insufficient Verification of Data Authenticity
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass345Insufficient Verification of Data Authenticity
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control
Integrity

Technical Impact: Bypass Protection Mechanism; Modify Application Data

An attacker could package untrusted data with trusted data to bypass protection mechanisms to gain access to and possibly modify sensitive data.
+ Observed Examples
ReferenceDescription
Does not verify that trusted entity is authoritative for all entities in its response.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUntrusted Data Appended with Trusted Data
CERT Java Secure CodingENV01-JPlace all security-sensitive code in a single JAR and sign and seal it
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Untrusted Data Appended with Trusted Data

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on how many resources can be allocated, in violation of the intended security policy for that actor.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Availability

Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

This code allocates a socket and forks each time it receives a new connection.

(bad)
Example Language:
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();

}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.

Example 2

In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad)
Example Language:
int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);

}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;

}

}
closeFile();

}
closeSocket(socket);

}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.

Example 3

In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad)
Example Language:
/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{
char *body;

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);

}
else {
printf("Unable to process message; invalid message length");
return(FAIL);

}

}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good)
Example Language:
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}

Example 4

In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad)
Example Language: Java 
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();

}
serverSocket.close();


} catch (IOException ex) {...}

}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);

}
serverSocket.close();


} catch (IOException ex) {...}

}

Example 5

An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:

[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.
+ Observed Examples
ReferenceDescription
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
+ Potential Mitigations

Phase: Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Phase: Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Phase: Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Phase: Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Phase: Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery. Ensure that all failures in resource allocation place the system into a safe posture.

Phases: Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
+ Detection Methods

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted software in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the software within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CERT Java Secure CodingFIO04-JClose resources when they are no longer needed
CERT Java Secure CodingSER12-JAvoid memory and resource leaks during serialization
CERT Java Secure CodingMSC05-JDo not exhaust heap space
+ References
[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11. <http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
[REF-387] D.J. Bernstein. "Resource exhaustion". <http://cr.yp.to/docs/resources.html>.
[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004. <http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23. <http://blogs.sans.org/appsecstreetfighter/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-05-13CWE Content TeamMITRE
Modifications
Modification DateModifierOrganizationSource
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-10-29CWE Content TeamMITRE
updated Relationships
2009-12-28CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2010-02-16CWE Content TeamMITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2011-03-29CWE Content TeamMITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITRE
updated Relationships
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings

CWE-88: Argument Injection or Modification

Weakness ID: 88
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic; Read Application Data; Modify Application Data

An attacker could include arguments that allow unintended commands or code to be executed, allow sensitive data to be read or modified or could cause other unintended behavior.
+ Demonstrative Examples

Example 1

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

(bad)
Example Language:
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);

}

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Note that if argv[1] is a very long argument, then this issue might also be subject to a buffer overflow (CWE-120).

+ Observed Examples
ReferenceDescription
Canonical Example
Web browser executes Telnet sessions using command line arguments that are specified by the web site, which could allow remote attackers to execute arbitrary commands.
Web browser allows remote attackers to execute commands by spawning Telnet with a log file option on the command line and writing arbitrary code into an executable file which is later executed.
Argument injection vulnerability in the mail function for PHP may allow attackers to bypass safe mode restrictions and modify command line arguments to the MTA (e.g. sendmail) possibly executing commands.
Help and Support center in windows does not properly validate HCP URLs, which allows remote attackers to execute arbitrary code via quotation marks in an "hcp://" URL.
Mail client does not sufficiently filter parameters of mailto: URLs when using them as arguments to mail executable, which allows remote attackers to execute arbitrary programs.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Mail client allows remote attackers to execute arbitrary code via a URI that uses a UNC network share pathname to provide an alternate configuration file.
SSH URI handler for web browser allows remote attackers to execute arbitrary code or conduct port forwarding via the a command line option.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Argument injection vulnerability in TellMe 1.2 and earlier allows remote attackers to modify command line arguments for the Whois program and obtain sensitive information via "--" style options in the q_Host parameter.
Beagle before 0.2.5 can produce certain insecure command lines to launch external helper applications while indexing, which allows attackers to execute arbitrary commands. NOTE: it is not immediately clear whether this issue involves argument injection, shell metacharacters, or other issues.
Argument injection vulnerability in Internet Explorer 6 for Windows XP SP2 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Mozilla Firefox 1.0.6 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Avant Browser 10.1 Build 17 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in the URI handler in Skype 2.0.*.104 and 2.5.*.0 through 2.5.*.78 for Windows allows remote authorized attackers to download arbitrary files via a URL that contains certain command-line switches.
Argument injection vulnerability in WinSCP 3.8.1 build 328 allows remote attackers to upload or download arbitrary files via encoded spaces and double-quote characters in a scp or sftp URI.
Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a "/" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka "Object Packager Dialogue Spoofing Vulnerability."
Argument injection vulnerability in HyperAccess 8.4 allows user-assisted remote attackers to execute arbitrary vbscript and commands via the /r option in a telnet:// URI, which is configured to use hawin32.exe.
Argument injection vulnerability in the telnet daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets certain client "-f" sequences as valid requests for the login program to skip authentication, which allows remote attackers to log into certain accounts, as demonstrated by the bin account.
Language interpreter's mail function accepts another argument that is concatenated to a string used in a dangerous popen() call. Since there is no neutralization of this argument, both OS Command Injection (CWE-78) and Argument Injection (CWE-88) are possible.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.

Phase: Implementation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

Phase: Implementation

When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Phase: Implementation

When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.

Phase: Testing

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

Use 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.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Affected Resources
  • System Process
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Relationship

At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERArgument Injection or Modification
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
CERT C Secure CodingENV33-CImpreciseDo not call system()
CERT C Secure CodingSTR02-CSanitize data passed to complex subsystems
WASC30Mail Command Injection
+ References
[REF-859] Steven Christey. "Argument injection issues". <http://www.securityfocus.com/archive/1/archive/1/460089/100/100/threaded>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "The Argument Array", Page 567.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITRE
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Relationship_Notes
2009-10-29CWE Content TeamMITRE
updated Observed_Examples
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITRE
updated Observed_Examples, Relationships
2010-09-27CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Taxonomy_Mappings

CWE CATEGORY: Audit

Category ID: 1009
Status: Draft
+ Summary
Weaknesses in this category are related to the design and architecture of audit-based components of the system. Frequently these deal with logging user activities in order to identify attackers and modifications to the system. The weaknesses in this category could lead to a degradation of the quality of the audit capability if they are not addressed when designing or implementing a secure architecture.
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2017-07-25CWE Content TeamMITRE
New Entry

CWE CATEGORY: Authenticate Actors

Category ID: 1010
Status: Draft
+ Summary
Weaknesses in this category are related to the design and architecture of authentication components of the system. Frequently these deal with verifying the entity is indeed who it claims to be. The weaknesses in this category could lead to a degradation of the quality of authentication if they are not addressed when designing or implementing a secure architecture.
+ Membership
NatureTypeIDName
MemberOfViewView1008Architectural Concepts
HasMemberVariantVariant258Empty Password in Configuration File
HasMemberBaseBase259Use of Hard-coded Password
HasMemberVariantVariant262Not Using Password Aging
HasMemberBaseBase263Password Aging with Long Expiration
HasMemberClassClass287Improper Authentication
HasMemberBaseBase288Authentication Bypass Using an Alternate Path or Channel
HasMemberVariantVariant289Authentication Bypass by Alternate Name
HasMemberBaseBase290Authentication Bypass by Spoofing
HasMemberVariantVariant291Reliance on IP Address for Authentication
HasMemberVariantVariant293Using Referer Field for Authentication
HasMemberBaseBase294Authentication Bypass by Capture-replay
HasMemberVariantVariant301Reflection Attack in an Authentication Protocol
HasMemberVariantVariant302Authentication Bypass by Assumed-Immutable Data
HasMemberBaseBase303Incorrect Implementation of Authentication Algorithm
HasMemberBaseBase304Missing Critical Step in Authentication
HasMemberBaseBase305Authentication Bypass by Primary Weakness
HasMemberVariantVariant306Missing Authentication for Critical Function
HasMemberBaseBase307Improper Restriction of Excessive Authentication Attempts
HasMemberBaseBase308Use of Single-factor Authentication
HasMemberBaseBase322Key Exchange without Entity Authentication
HasMemberBaseBase521Weak Password Requirements
HasMemberVariantVariant593Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created
HasMemberBaseBase603Use of Client-Side Authentication
HasMemberVariantVariant620Unverified Password Change
HasMemberBaseBase640Weak Password Recovery Mechanism for Forgotten Password
HasMemberBaseBase798Use of Hard-coded Credentials
HasMemberBaseBase836Use of Password Hash Instead of Password for Authentication
HasMemberBaseBase916Use of Password Hash With Insufficient Computational Effort
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2017-07-25CWE Content TeamMITRE
New Entry

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Relationship

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

Theoretical

Alternate names are useful in data driven manipulation attacks, not just for authentication.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by alternate name
CERT Java Secure CodingIDS01-JNormalize strings before validating them
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2009-07-27CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.

(bad)
Example Language: Java 
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) {
...

}

Of course, modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.

+ Observed Examples
ReferenceDescription
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
CERT Java Secure CodingSEC02-JDo not base security checks on untrusted sources
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Demonstrative_Examples, Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships

CWE-294: Authentication Bypass by Capture-replay

Weakness ID: 294
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A capture-replay flaw exists when the design of the software makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
+ Extended Description
Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Gain Privileges or Assume Identity

Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication.
+ Likelihood Of Exploit
High
+ Observed Examples
ReferenceDescription
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).
+ Potential Mitigations

Phase: Architecture and Design

Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.

Phase: Architecture and Design

Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView884CWE Cross-section
MemberOfCategoryCategory956SFP Secondary Cluster: Channel Attack
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by replay
CLASPCapture-replay
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2009-10-29CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships

CWE-305: Authentication Bypass by Primary Weakness

Weakness ID: 305
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The authentication algorithm is sound, but the implemented mechanism can be bypassed as the result of a separate weakness that is primary to the authentication error.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
The provided password is only compared against the first character of the real password.
The password is not properly checked, which allows remote attackers to bypass access controls by sending a 1-byte password that matches the first character of the real password.
Chain: Forum software does not properly initialize an array, which inadvertently sets the password to a single character, allowing remote attackers to easily guess the password and gain administrative privileges.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory947SFP Secondary Cluster: Authentication Bypass
+ Notes

Relationship

Most "authentication bypass" errors are resultant, not primary.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass by Primary Weakness
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships

CWE-290: Authentication Bypass by Spoofing

Weakness ID: 290
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
This attack-focused weakness is caused by improperly implemented authentication schemes that are subject to spoofing attacks.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity

This weakness can allow an attacker to access resources which are not otherwise accessible without proper authentication.
+ Demonstrative Examples

Example 1

The following code authenticates users.

(bad)
Example Language: Java 
String sourceIP = request.getRemoteAddr();
if (sourceIP != null && sourceIP.equals(APPROVED_IP)) {
authenticated = true;

}

The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism.

Example 2

Both of these examples check if a request is from a trusted address before responding to the request.

(bad)
Example Language:
sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_ANY);
servr.sin_port = htons(1008);
bind(sd, (struct sockaddr *) & serv, sizeof(serv));

while (1) {
memset(msg, 0x0, MAX_MSG);
clilen = sizeof(cli);
if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) {
n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen);

}

}
(bad)
Example Language: Java 
while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp);
String in = new String(p.getData(),0, rp.getLength());
InetAddress clientIPAddress = rp.getAddress();
int port = rp.getPort();

if (isTrustedAddress(clientIPAddress) & secretKey.equals(in)) {
out = secret.getBytes();
DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp);

}

}

The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client

Example 3

The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(bad)
Example Language:
struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com";
myaddr.s_addr=inet_addr(ip_addr_string);

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {
trusted = true;

} else {
trusted = false;

}
(bad)
Example Language: Java 
String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;

}
(bad)
Example Language: C# 
IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;

}

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

+ Observed Examples
ReferenceDescription
VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView884CWE Cross-section
MemberOfCategoryCategory956SFP Secondary Cluster: Channel Attack
+ Notes

Relationship

This can be resultant from insufficient verification.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication bypass by spoofing
+ References
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Spoofing and Identification", Page 72.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Relationship_Notes
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships

CWE-288: Authentication Bypass Using an Alternate Path or Channel

Weakness ID: 288
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
A product requires authentication, but the product has an alternate path or channel that does not require authentication.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory840Business Logic Errors
ChildOfClassClass287Improper Authentication
ParentOfBaseBase425Direct Request ('Forced Browsing')
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and DesignThis is often seen in web applications that assume that access to a particular CGI program can only be obtained through a "front" screen, when the supporting programs are directly accessible. But this problem is not just in web apps.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

+ Observed Examples
ReferenceDescription
Router allows remote attackers to read system logs without authentication by directly connecting to the login screen and typing certain control characters.
Attackers with physical access to the machine may bypass the password prompt by pressing the ESC (Escape) key.
OS allows local attackers to bypass the password protection of idled sessions via the programmer's switch or CMD-PWR keyboard sequence, which brings up a debugger that the attacker can use to disable the lock.
Direct request of installation file allows attacker to create administrator accounts.
Attackers may gain additional privileges by directly requesting the web management URL.
Bypass authentication via direct request to named pipe.
User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing.
+ Potential Mitigations

Phase: Architecture and Design

Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Relationship

overlaps Unprotected Alternate Channel
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass by Alternate Path/Channel
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITRE
updated Description, Modes_of_Introduction, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Type
2008-11-24CWE Content TeamMITRE
updated Observed_Examples
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Authentication Bypass by Alternate Path/Channel

CWE-593: Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

Weakness ID: 593
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software modifies the SSL context after connection creation has begun.
+ Extended Description
If the program modifies the SSL_CTX object after creating SSL objects from it, there is the possibility that older SSL objects created from the original context could all be affected by that change.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1010Authenticate Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfClassClass287Improper Authentication
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

No authentication takes place in this process, bypassing an assumed protection of encryption.
Confidentiality

Technical Impact: Read Application Data

The encrypted communication between a user and a trusted host may be subject to a "man in the middle" sniffing attack.
+ Demonstrative Examples

Example 1

The following example demonstrates the weakness.

(bad)
Example Language:
#define CERT "secret.pem"
#define CERT2 "secret2.pem"

int main(){
SSL_CTX *ctx;
SSL *ssl;
init_OpenSSL();
seed_prng();

ctx = SSL_CTX_new(SSLv23_method());

if (SSL_CTX_use_certificate_chain_file(ctx, CERT) != 1)
int_error("Error loading certificate from file");


if (SSL_CTX_use_PrivateKey_file(ctx, CERT, SSL_FILETYPE_PEM) != 1)
int_error("Error loading private key from file");


if (!(ssl = SSL_new(ctx)))
int_error("Error creating an SSL context");


if ( SSL_CTX_set_default_passwd_cb(ctx, "new default password" != 1))
int_error("Doing something which is dangerous to do anyways");


if (!(ssl2 = SSL_new(ctx)))
int_error("Error creating an SSL context");

}
+ Potential Mitigations

Phase: Architecture and Design

Use a language or a library that provides a cryptography framework at a higher level of abstraction.

Phase: Implementation

Most SSL_CTX functions have SSL counterparts that act on SSL-type objects.

Phase: Implementation

Applications should set up an SSL_CTX completely, before creating SSL objects from it.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory948SFP Secondary Cluster: Digital Certificate
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Other_Notes
2009-07-27CWE Content TeamMITRE
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-06-27CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Potential_Mitigations, Relationships
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Relationships

CWE-639: Authorization Bypass Through User-Controlled Key

Weakness ID: 639
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
+ Extended Description

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.

For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.

One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory840Business Logic Errors
ChildOfClassClass862Missing Authorization
ParentOfVariantVariant566Authorization Bypass Through User-Controlled SQL Primary Key
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control

Technical Impact: Bypass Protection Mechanism

Access control checks for specific user data or functionality can be bypassed.
Access Control

Technical Impact: Gain Privileges or Assume Identity

Horizontal escalation of privilege is possible (one user can view/modify information of another user).
Access Control

Technical Impact: Gain Privileges or Assume Identity

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.
+ Alternate Terms
Insecure Direct Object Reference:The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.
Horizontal Authorization:"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.
+ Likelihood Of Exploit
High
+ Potential Mitigations

Phase: Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Phases: Architecture and Design; Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Phase: Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-01-30Evgeny LebanidzeCigital
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITRE
updated Common_Consequences, Relationships, Type
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Relationships
2009-05-27CWE Content TeamMITRE
updated Relationships
2009-10-29CWE Content TeamMITRE
updated Common_Consequences
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-03-29CWE Content TeamMITRE
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-02-21CWE Content TeamMITRE
updated Alternate_Terms, Common_Consequences
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Access Control Bypass Through User-Controlled Key

CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key

Weakness ID: 566
Abstraction: Variant
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.
+ Extended Description

When a user can set a primary key to any value, then the user can modify the key to point to unauthorized records.

Database access control errors occur when:

  • Data enters a program from an untrusted source.
  • The data is used to specify the value of a primary key in a SQL query.
  • The untrusted source does not have the permissions to be able to access all rows in the associated table.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Technologies

Database Server: (Often Prevalent)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Application Data; Modify Application Data; Bypass Protection Mechanism

+ Demonstrative Examples

Example 1

The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.

(bad)
Example Language: C# 
...
conn = new SqlConnection(_ConnectionString);
conn.Open();
int16 id = System.Convert.ToInt16(invoiceID.Text);
SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
query.Parameters.AddWithValue("@id", id);
SqlDataReader objReader = objCommand.ExecuteReader();
...

The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.

+ Potential Mitigations

Phase: Implementation

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an "accept known good" validation strategy.

Phase: Implementation

Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory994SFP Secondary Cluster: Tainted Input to Variable
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP25Tainted input to variable
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Description
2011-03-29CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Access Control Bypass Through User-Controlled SQL Primary Key

CWE CATEGORY: Authorize Actors

Category ID: 1011
Status: Draft
+ Summary
Weaknesses in this category are related to the design and architecture of a system's authorization components. Frequently these deal with enforcing that agents have the required permissions before performing certain operations, such as modifying data. The weaknesses in this category could lead to a degredation of quality of the authorization capability if they are not addressed when designing or implementing a secure architecture.
+ Membership
NatureTypeIDName
MemberOfViewView1008Architectural Concepts
HasMemberBaseBase15External Control of System or Configuration Setting
HasMemberBaseBase114Process Control
HasMemberVariantVariant219Sensitive Data Under Web Root
HasMemberVariantVariant220Sensitive Data Under FTP Root
HasMemberBaseBase266Incorrect Privilege Assignment
HasMemberBaseBase267Privilege Defined With Unsafe Actions
HasMemberBaseBase268Privilege Chaining
HasMemberClassClass269Improper Privilege Management
HasMemberBaseBase270Privilege Context Switching Error
HasMemberClassClass271Privilege Dropping / Lowering Errors
HasMemberBaseBase272Least Privilege Violation
HasMemberBaseBase273Improper Check for Dropped Privileges
HasMemberBaseBase274Improper Handling of Insufficient Privileges
HasMemberVariantVariant276Incorrect Default Permissions
HasMemberVariantVariant277Insecure Inherited Permissions
HasMemberVariantVariant279Incorrect Execution-Assigned Permissions
HasMemberBaseBase280Improper Handling of Insufficient Permissions or Privileges
HasMemberBaseBase281Improper Preservation of Permissions
HasMemberClassClass282Improper Ownership Management
HasMemberBaseBase283Unverified Ownership
HasMemberClassClass284Improper Access Control
HasMemberClassClass285Improper Authorization
HasMemberClassClass286Incorrect User Management
HasMemberClassClass300Channel Accessible by Non-Endpoint ('Man-in-the-Middle')
HasMemberBaseBase341Predictable from Observable State
HasMemberClassClass359Exposure of Private Information ('Privacy Violation')
HasMemberBaseBase403Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak')
HasMemberBaseBase419Unprotected Primary Channel
HasMemberBaseBase420Unprotected Alternate Channel
HasMemberBaseBase425Direct Request ('Forced Browsing')
HasMemberCompositeComposite426Untrusted Search Path
HasMemberBaseBase434Unrestricted Upload of File with Dangerous Type
HasMemberVariantVariant527Exposure of CVS Repository to an Unauthorized Control Sphere
HasMemberVariantVariant528Exposure of Core Dump File to an Unauthorized Control Sphere
HasMemberVariantVariant529Exposure of Access Control List Files to an Unauthorized Control Sphere
HasMemberVariantVariant530Exposure of Backup File to an Unauthorized Control Sphere
HasMemberBaseBase538File and Directory Information Exposure
HasMemberBaseBase551Incorrect Behavior Order: Authorization Before Parsing and Canonicalization
HasMemberBaseBase552Files or Directories Accessible to External Parties
HasMemberVariantVariant566Authorization Bypass Through User-Controlled SQL Primary Key
HasMemberBaseBase639Authorization Bypass Through User-Controlled Key
HasMemberClassClass642External Control of Critical State Data
HasMemberVariantVariant647Use of Non-Canonical URL Paths for Authorization Decisions
HasMemberBaseBase653Insufficient Compartmentalization
HasMemberBaseBase656Reliance on Security Through Obscurity
HasMemberClassClass668Exposure of Resource to Wrong Sphere
HasMemberClassClass669Incorrect Resource Transfer Between Spheres
HasMemberClassClass671Lack of Administrator Control over Security
HasMemberClassClass673External Influence of Sphere Definition
HasMemberBaseBase708Incorrect Ownership Assignment
HasMemberClassClass732Incorrect Permission Assignment for Critical Resource
HasMemberBaseBase770Allocation of Resources Without Limits or Throttling
HasMemberVariantVariant782Exposed IOCTL with Insufficient Access Control
HasMemberBaseBase827Improper Control of Document Type Definition
HasMemberClassClass862Missing Authorization
HasMemberClassClass863Incorrect Authorization
HasMemberBaseBase921Storage of Sensitive Data in a Mechanism without Access Control
HasMemberClassClass923Improper Restriction of Communication Channel to Intended Endpoints
HasMemberBaseBase939Improper Authorization in Handler for Custom URL Scheme
HasMemberVariantVariant942Overly Permissive Cross-domain Whitelist
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2017-07-25CWE Content TeamMITRE
New Entry

CWE-300: Channel Accessible by Non-Endpoint ('Man-in-the-Middle')

Weakness ID: 300
Abstraction: Class
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.
+ Extended Description
In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Inadequate or inconsistent verification may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1011Authorize Actors
+ Relevant to the view "Development Concepts" (CWE-699)
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Integrity
Access Control

Technical Impact: Read Application Data; Modify Application Data; Gain Privileges or Assume Identity

An attacker could pose as one of the entities and read or possibly modify the communication.
+ Demonstrative Examples

Example 1

In the Java snippet below, data is sent over an unencrypted channel to a remote server.

(bad)
Example Language: Java 
Socket sock;
PrintWriter out;

try {
sock = new Socket(REMOTE_HOST, REMOTE_PORT);
out = new PrintWriter(echoSocket.getOutputStream(), true);
// Write data to remote host via socket output stream.

...

}

By eavesdropping on the communication channel or posing as the endpoint, an attacker would be able to read all of the transmitted data.

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing man-in-the-middle attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle')).
+ Potential Mitigations

Phase: Implementation

Always fully authenticate both ends of any communications channel.

Phase: Architecture and Design

Adhere to the principle of complete mediation.

Phase: Implementation

A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Maintenance

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMan-in-the-middle (MITM)
WASC32Routing Detour
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
+ References
[REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Description
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-02-18CWE Content TeamMITRE
updated Relationships
2014-06-23CWE Content TeamMITRE
updated Observed_Examples
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Man-in-the-middle (MITM)
2009-05-27Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')

CWE-313: Cleartext Storage in a File or on Disk

Weakness ID: 313
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext in a file, or on disk.
+ Extended Description
The sensitive information could be read by attackers with access to the file, or with physical or administrator access to the raw disk. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.

This Java example shows a properties file with a cleartext username / password pair.

(bad)
Example Language: Java 
# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext.

(bad)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information and avoid CWE-260 and CWE-13

+ Observed Examples
ReferenceDescription
Cleartext credentials in world-readable file.
Password in cleartext in config file.
Password in cleartext in config file.
Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
Cleartext storage of private key and passphrase in log file when user imports the key.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory963SFP Secondary Cluster: Exposed Data
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in File or on Disk
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Plaintext Storage in File or on Disk
2013-07-17Plaintext Storage in a File or on Disk

CWE-314: Cleartext Storage in the Registry

Weakness ID: 314
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext in the registry.
+ Extended Description
Attackers can read the information by accessing the registry key. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
Cleartext passwords in registry key.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory963SFP Secondary Cluster: Exposed Data
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Registry
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Observed_Examples, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Plaintext Storage in Registry
2013-07-17Plaintext Storage in the Registry

CWE-312: Cleartext Storage of Sensitive Information

Weakness ID: 312
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
+ Extended Description
Because the information is stored in cleartext, attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Mobile: (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

An attacker with access to the system could read sensitive information stored in cleartext.
+ Demonstrative Examples

Example 1

The following code excerpt stores a plaintext user account ID in a browser cookie.

(bad)
Example Language: Java 
response.addCookie( new Cookie("userAccountID", acctID);

Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.

Example 2

This code writes a user's login information to a cookie so the user does not have to login again later.

(bad)
Example Language: PHP 
function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);

}

The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.

Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).

Example 3

The following code attempts to establish a connection, read in a password, then store it to a buffer.

(bad)
Example Language:
server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host");
memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length);
if (argc < 3) port = 80;
else port = (unsigned short)atoi(argv[3]);
server.sin_port = htons(port);
if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting");
...
while ((n=read(sock,buffer,BUFSIZE-1))!=-1) {

write(dfd,password_buffer,n);
...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.

Example 4

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in plaintext.

This Java example shows a properties file with a plaintext username / password pair.

(bad)
Example Language: Java 
# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in plaintext.

(bad)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information and avoid CWE-260 and CWE-13.

+ Observed Examples
ReferenceDescription
password and username stored in cleartext in a cookie
password stored in cleartext in a file with insecure permissions
chat program disables SSL in some circumstances even when the user says to use SSL.
Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
storage of unencrypted passwords in a database
storage of unencrypted passwords in a database
product stores a password in cleartext in memory
storage of a secret key in cleartext in a temporary file
SCADA product uses HTTP Basic Authentication, which is not encrypted
login credentials stored unencrypted in a registry key
Plaintext credentials in world-readable file.
Password in cleartext in config file.
Password in cleartext in config file.
Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
Plaintext storage of private key and passphrase in log file when user imports the key.
Admin password in plaintext in a cookie.
Default configuration has cleartext usernames/passwords in cookie.
Usernames/passwords in cleartext in cookies.
Authentication information stored in cleartext in a cookie.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage of Sensitive Information
Software Fault PatternsSFP23Exposed Data
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43.. 1st Edition. Addison Wesley. 2006.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Description, Name
2010-02-16CWE Content TeamMITRE
updated References
2010-06-21CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Description, Relationships, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Storage of Sensitive Information

CWE-315: Cleartext Storage of Sensitive Information in a Cookie

Weakness ID: 315
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext in a cookie.
+ Extended Description
Attackers can use widely-available tools to view the cookie and read the sensitive information. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Demonstrative Examples

Example 1

The following code excerpt stores a plaintext user account ID in a browser cookie.

(bad)
Example Language: Java 
response.addCookie( new Cookie("userAccountID", acctID);

Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.

+ Observed Examples
ReferenceDescription
Admin password in cleartext in a cookie.
Default configuration has cleartext usernames/passwords in cookie.
Usernames/passwords in cleartext in cookies.
Authentication information stored in cleartext in a cookie.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory963SFP Secondary Cluster: Exposed Data
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Cookie
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigital
added/updated demonstrative examples
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Plaintext Storage in Cookie
2013-07-17Plaintext Storage in a Cookie

CWE-318: Cleartext Storage of Sensitive Information in Executable

Weakness ID: 318
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext in an executable.
+ Extended Description
Attackers can reverse engineer binary code to obtain secret data. This is especially easy when the cleartext is plain ASCII. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Application Data

+ Observed Examples
ReferenceDescription
Product stores RSA private key in a DLL and uses it to sign a certificate, allowing spoofing of servers and MITM attacks.
administration passwords in cleartext in executable
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory963SFP Secondary Cluster: Exposed Data
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Executable
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Plaintext Storage in Executable

CWE-317: Cleartext Storage of Sensitive Information in GUI

Weakness ID: 317
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext within the GUI.
+ Extended Description
An attacker can often obtain data from a GUI, even if hidden, by using an API to directly access GUI objects such as windows and menus. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory355User Interface Security Issues
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Operating Systems

(Windows classes): (Sometimes Prevalent)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory; Read Application Data

+ Observed Examples
ReferenceDescription
Unencrypted passwords stored in GUI dialog may allow local users to access the passwords.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory963SFP Secondary Cluster: Exposed Data
+ Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in GUI
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Description, Relationships, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Plaintext Storage in GUI

CWE-316: Cleartext Storage of Sensitive Information in Memory

Weakness ID: 316
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The application stores sensitive information in cleartext in memory.
+ Extended Description

The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the application crashes, or if the programmer does not properly clear the memory before freeing it.

It could be argued that such problems are usually only exploitable by those with administrator privileges. However, swapping could cause the memory to be written to disk and leave it accessible to physical attack afterwards. Core dump files might have insecure permissions or be stored in archive files that are accessible to untrusted people. Or, uncleared sensitive memory might be inadvertently exposed to attackers due to another weakness.

+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase312Cleartext Storage of Sensitive Information
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Memory

+ Observed Examples
ReferenceDescription
Sensitive authentication information in cleartext in memory.
Sensitive authentication information in cleartext in memory.
Password protector leaves passwords in memory when window is minimized, even when "clear password when minimized" is set.
SSH client does not clear credentials from memory.
+ Affected Resources
  • Memory
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory963SFP Secondary Cluster: Exposed Data
+ Notes

Relationship

This could be a resultant weakness, e.g. if the compiler removes code that was intended to wipe memory.

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Storage in Memory
Software Fault PatternsSFP23Exposed Data
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2013-07-17CWE Content TeamMITRE
updated Applicable_Platforms, Description, Name, Other_Notes, Potential_Mitigations, Terminology_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Modes_of_Introduction, Observed_Examples, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2013-07-17Plaintext Storage in Memory

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
+ Extended Description
Many communication channels can be "sniffed" by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1013Encrypt Data
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
ChildOfBaseBase311Missing Encryption of Sensitive Data
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignOMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation
System Configuration
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Mobile: (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Read Application Data; Modify Files or Directories

Anyone can read the information by gaining access to the channel being used for communication.
+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();

}
catch (IOException e) {
//...

}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

+ Observed Examples
ReferenceDescription
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Potential Mitigations

Phase: Architecture and Design

Encrypt the data with a reliable encryption scheme before transmitting.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
+ Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPlaintext Transmission of Sensitive Information
CERT Java Secure CodingSEC06-JDo not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
CERT Java Secure CodingSER02-JSign then seal sensitive objects before sending them outside a trust boundary
Software Fault PatternsSFP23Exposed Data
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <http://www.veracode.com/blog/2010/12/mobile-app-top-10-list/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21CWE Content TeamMITRE
updated Detection_Factors, Relationships
2010-12-13CWE Content TeamMITRE
updated Observed_Examples, Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Potential_Mitigations
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21CWE Content TeamMITRE
updated Applicable_Platforms, References
2013-07-17CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Related_Attack_Patterns
2014-06-23CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Plaintext Transmission of Sensitive Information

CWE-602: Client-Side Enforcement of Server-Side Security

Weakness ID: 602
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
+ Extended Description
When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1012Cross Cutting
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory2547PK - Security Features
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignCOMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and DesignConsider a product that consists of two or more processes or nodes that must interact closely, such as a client/server model. If the product uses protection schemes in the client in order to defend from attacks against the server, and the server does not use the same schemes, then an attacker could modify the client in a way that bypasses those schemes. This is a fundamental design flaw that is primary to many weaknesses.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Client Server: (Sometimes Prevalent)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Access Control
Availability

Technical Impact: Bypass Protection Mechanism; DoS: Crash, Exit, or Restart

Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviors and possibly a resulting crash.
Access Control

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.
+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1

This example contains client-side code that checks if the user authenticated successfully before sending a command. The server-side code performs the authentication in one step, and executes the command in a separate step.

CLIENT-SIDE (client.pl)

(good)
Example Language: Perl 
$server = "server.example.com";
$username = AskForUserName();
$password = AskForPassword();
$address = AskForAddress();
$sock = OpenSocket($server, 1234);
writeSocket($sock, "AUTH $username $password\n");
$resp = readSocket($sock);
if ($resp eq "success") {
# username/pass is valid, go ahead and update the info!
writeSocket($sock, "CHANGE-ADDRESS $username $address\n";

}
else {
print "ERROR: Invalid Authentication!\n";

}

SERVER-SIDE (server.pl):

(bad)
 
$sock = acceptSocket(1234);
($cmd, $args) = ParseClientRequest($sock);
if ($cmd eq "AUTH") {
($username, $pass) = split(/\s+/, $args, 2);
$result = AuthenticateUser($username, $pass);
writeSocket($sock, "$result\n");
# does not close the socket on failure; assumes the
# user will try again

}
elsif ($cmd eq "CHANGE-ADDRESS") {
if (validateAddress($args)) {
$res = UpdateDatabaseRecord($username, "address", $args);
writeSocket($sock, "SUCCESS\n");

}
else {
writeSocket($sock, "FAILURE -- address is malformed\n");

}

}

The server accepts 2 commands, "AUTH" which authenticates the user, and "CHANGE-ADDRESS" which updates the address field for the username. The client performs the authentication and only sends a CHANGE-ADDRESS for that user if the authentication succeeds. Because the client has already performed the authentication, the server assumes that the username in the CHANGE-ADDRESS is the same as the authenticated user. An attacker could modify the client by removing the code that sends the "AUTH" command and simply executing the CHANGE-ADDRESS.

+ Observed Examples
ReferenceDescription
ASP program allows upload of .asp files by bypassing client-side checks.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
client allows server to modify client's configuration and overwrite arbitrary files.
+ Potential Mitigations

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Phase: Architecture and Design

If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.

Phase: Testing

Use 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.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOfCategoryCategory7532009 Top 25 - Porous Defenses
MemberOfViewView884CWE Cross-section
MemberOfCategoryCategory975SFP Secondary Cluster: Architecture
+ Notes

Research Gap

Server-side enforcement of client-side security is conceptually likely to occur, but some architectures might have these strong dependencies as part of legitimate behavior, such as thin clients.
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 23, "Client-Side Security Is an Oxymoron" Page 687. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoft.com/mspress/books/toc/5957.aspx>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Research_Gaps, Time_of_Introduction
2009-03-10CWE Content TeamMITRE
updated Potential_Mitigations
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITRE
updated Related_Attack_Patterns, Relationships
2009-10-29CWE Content TeamMITRE
updated Applicable_Platforms, Common_Consequences, Description
2010-02-16CWE Content TeamMITRE
updated References
2010-04-05CWE Content TeamMITRE
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITRE
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITRE
updated Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships
2017-05-03CWE Content TeamMITRE
updated Related_Attack_Patterns
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Client-Side Enforcement of Server-Side Security
2009-01-12Design Principle Violation: Client-Side Enforcement of Server-Side Security

CWE-243: Creation of chroot Jail Without Changing Working Directory

Weakness ID: 243
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The program uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
+ Extended Description
Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1015Limit Access
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory265Privilege / Sandbox Issues
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
ImplementationREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C: (Undetermined Prevalence)

C++: (Undetermined Prevalence)

Operating Systems

(Unix classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality

Technical Impact: Read Files or Directories

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1

Consider the following source code from a (hypothetical) FTP server:

(bad)
Example Language:
chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);

}
fclose(localfile);

This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server does not change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Affected Resources
  • File or Directory
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory2277PK - API Abuse
MemberOfCategoryCategory979SFP Secondary Cluster: Failed Chroot Jail
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsDirectory Restriction
Software Fault PatternsSFP17Failed chroot jail
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious Kingdoms
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Background_Details, Description, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITRE
updated Description
2009-03-10CWE Content TeamMITRE
updated Demonstrative_Examples
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Affected_Resources, Causal_Nature, Modes_of_Introduction, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-01-30Directory Restriction
2010-12-13Failure to Change Working Directory in chroot Jail

CWE CATEGORY: Cross Cutting

Category ID: 1012
Status: Draft
+ Summary
Weaknesses in this category are related to the design and architecture of multiple security tactics and how they affect a system. For example, information exposure can impact the Limit Access and Limit Exposure security tactics. The weaknesses in this category could lead to a degradation of the quality of many capabilities if they are not addressed when designing or implementing a secure architecture.
+ References
[REF-9] Santos, J. C. S., Tarrit, K. and Mirakhorli, M.. "A Catalog of Security Architecture Weaknesses.". 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/cawe-paper.pdf>.
[REF-10] Santos, J. C. S., Peruma, A., Mirakhorli, M., Galster, M. and Sejfia, A.. "Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird.". pages 69 - 78. 2017 IEEE International Conference on Software Architecture (ICSA). 2017. <https://design.se.rit.edu/papers/TacticalVulnerabilities.pdf>.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2017-07-25CWE Content TeamMITRE
New Entry

CWE-352: Cross-Site Request Forgery (CSRF)

Weakness ID: 352
Abstraction: Compound
Structure: Composite
Status: Draft
Presentation Filter:
+ Description
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
+ Composite Components
+ Extended Description
When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfClassClass345Insufficient Verification of Data Authenticity
+ Relevant to the view "Architectural Concepts" (CWE-1008)
NatureTypeIDName
MemberOfCategoryCategory1019Validate Inputs
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory442Web Problems
ChildOfClassClass345Insufficient Verification of Data Authenticity
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and DesignREALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

Technologies

Web Server: (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Non-Repudiation
Access Control

Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism; Read Application Data; Modify Application Data; DoS: Crash, Exit, or Restart

The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim's privileges.
+ Alternate Terms
Session Riding
Cross Site Reference Forgery
XSRF