CWE VIEW: Weaknesses in OWASP Top Ten (2021)
CWE entries in this view (graph) are associated with the OWASP Top Ten, as released in 2021.
The following graph shows the tree-like relationships between
weaknesses that exist at different levels of abstraction. At the highest level, categories
and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are
special CWE entries used to group weaknesses that share a common characteristic. Pillars are
weaknesses that are described in the most abstract fashion. Below these top-level entries
are weaknesses are varying levels of abstraction. Classes are still very abstract, typically
independent of any specific language or technology. Base level weaknesses are used to
present a more specific type of weakness. A variant is a weakness that is described at a
very low level of detail, typically limited to a specific language or technology. A chain is
a set of weaknesses that must be reachable consecutively in order to produce an exploitable
vulnerability. While a composite is a set of weaknesses that must all be present
simultaneously in order to produce an exploitable vulnerability.
Show Details:
1344 - Weaknesses in OWASP Top Ten (2021)
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control)
Weaknesses in this category are related to the A01 category "Broken Access Control" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
22
(Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Directory traversal
Path traversal
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
23
(Relative Path Traversal)
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.
Zip Slip
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
35
(Path Traversal: '.../...//')
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '.../...//' (doubled triple dot slash) sequences that can resolve to a location that is outside of that directory.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
59
(Improper Link Resolution Before File Access ('Link Following'))
The product 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
Zip Slip
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
200
(Exposure of Sensitive Information to an Unauthorized Actor)
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Information Disclosure
Information Leak
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
201
(Insertion of Sensitive Information Into Sent Data)
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
219
(Storage of File with Sensitive Data Under Web Root)
The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
264
(Permissions, Privileges, and Access Controls)
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
275
(Permission Issues)
Weaknesses in this category are related to improper assignment or handling of permissions.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
276
(Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
284
(Improper Access Control)
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Authorization
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
285
(Improper Authorization)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
AuthZ
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
352
(Cross-Site Request Forgery (CSRF))
The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.
Session Riding
Cross Site Reference Forgery
XSRF
CSRF
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
359
(Exposure of Private Personal Information to an Unauthorized Actor)
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected.
Privacy violation
Privacy leak / Privacy leakage
PPI
PII
PHI
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
377
(Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
402
(Transmission of Private Resources into a New Sphere ('Resource Leak'))
The product makes resources available to untrusted parties when those resources are only intended to be accessed by the product.
Resource Leak
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
425
(Direct Request ('Forced Browsing'))
The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.
forced browsing
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
441
(Unintended Proxy or Intermediary ('Confused Deputy'))
The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product 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
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
497
(Exposure of Sensitive System Information to an Unauthorized Control Sphere)
The product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
538
(Insertion of Sensitive Information into Externally-Accessible File or Directory)
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
540
(Inclusion of Sensitive Information in Source Code)
Source code on a web server or repository often contains sensitive information and should generally not be accessible to users.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
548
(Exposure of Information Through Directory Listing)
The product inappropriately exposes a directory listing with an index of all the resources located inside of the directory.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
552
(Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
566
(Authorization Bypass Through User-Controlled SQL Primary Key)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
601
(URL Redirection to Untrusted Site ('Open Redirect'))
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.
Open Redirect
Cross-site Redirect
Cross-domain Redirect
Unvalidated Redirect
Drive-by download
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
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 Reference / IDOR
Broken Object Level Authorization / BOLA
Horizontal Authorization
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
651
(Exposure of WSDL File Containing Sensitive Information)
The Web services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
706
(Use of Incorrectly-Resolved Name or Reference)
The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
862
(Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
AuthZ
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
863
(Incorrect Authorization)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
AuthZ
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
913
(Improper Control of Dynamically-Managed Code Resources)
The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
922
(Insecure Storage of Sensitive Information)
The product stores sensitive information without properly limiting read or write access by unauthorized actors.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1345
(OWASP Top Ten 2021 Category A01:2021 - Broken Access Control) >
1275
(Sensitive Cookie with Improper SameSite Attribute)
The SameSite attribute for sensitive cookies is not set, or an insecure value is used.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures)
Weaknesses in this category are related to the A02 category "Cryptographic Failures" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
261
(Weak Encoding for Password)
Obscuring a password with a trivial encoding does not protect the password.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
296
(Improper Following of a Certificate's Chain of Trust)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
310
(Cryptographic Issues)
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
319
(Cleartext Transmission of Sensitive Information)
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
321
(Use of Hard-coded Cryptographic Key)
The product uses a hard-coded, unchangeable cryptographic key.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
322
(Key Exchange without Entity Authentication)
The product performs a key exchange with an actor without verifying the identity of that actor.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
323
(Reusing a Nonce, Key Pair in Encryption)
Nonces should be used for the present occasion and only once.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
325
(Missing Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
326
(Inadequate Encryption Strength)
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
328
(Use of Weak Hash)
The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack).
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
329
(Generation of Predictable IV with CBC Mode)
The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
331
(Insufficient Entropy)
The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
335
(Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
340
(Generation of Predictable Numbers or Identifiers)
The product uses a scheme that generates numbers or identifiers that are more predictable than required.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
347
(Improper Verification of Cryptographic Signature)
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
523
(Unprotected Transport of Credentials)
Login pages do not use adequate measures to protect the user name and password while they are in transit from the client to the server.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
720
(OWASP Top Ten 2007 Category A9 - Insecure Communications)
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2007.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
759
(Use of a One-Way Hash without a Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
760
(Use of a One-Way Hash with a Predictable Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
780
(Use of RSA Algorithm without OAEP)
The product uses the RSA algorithm but does not incorporate Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
818
(OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection)
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2010.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1346
(OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures) >
916
(Use of Password Hash With Insufficient Computational Effort)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection)
Weaknesses in this category are related to the A03 category "Injection" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
20
(Improper Input Validation)
The product receives input or data, but it does
not validate or incorrectly validates that the input has the
properties that are required to process the data safely and
correctly.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
74
(Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
75
(Failure to Sanitize Special Elements into a Different Plane (Special Element Injection))
The product does not adequately filter user-controlled input for special elements with control implications.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
77
(Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The product 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.
Command injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
78
(Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The product 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 injection
Shell metacharacters
OS Command Injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
79
(Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The product 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.
XSS
HTML Injection
Reflected XSS / Non-Persistent XSS / Type 1 XSS
Stored XSS / Persistent XSS / Type 2 XSS
DOM-Based XSS / Type 0 XSS
CSS
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
80
(Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special characters such as "<", ">", and "&" that could be interpreted as web-scripting elements when they are sent to a downstream component that processes web pages.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
83
(Improper Neutralization of Script in Attributes in a Web Page)
The product does not neutralize or incorrectly neutralizes "javascript:" or other URIs from dangerous attributes within tags, such as onmouseover, onload, onerror, or style.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
87
(Improper Neutralization of Alternate XSS Syntax)
The product does not neutralize or incorrectly neutralizes user-controlled input for alternate script syntax.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
88
(Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))
The product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
89
(Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The product 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. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
SQL injection
SQLi
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
90
(Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
91
(XML Injection (aka Blind XPath Injection))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
93
(Improper Neutralization of CRLF Sequences ('CRLF Injection'))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
94
(Improper Control of Generation of Code ('Code Injection'))
The product 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.
Code Injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
95
(Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
The product 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").
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
96
(Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection'))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
97
(Improper Neutralization of Server-Side Includes (SSI) Within a Web Page)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
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 include
RFI
Local file inclusion
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
99
(Improper Control of Resource Identifiers ('Resource Injection'))
The product 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
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
113
(Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'))
The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.
HTTP Request Splitting
HTTP Response Splitting
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
116
(Improper Encoding or Escaping of Output)
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
Output Sanitization
Output Validation
Output Encoding
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
138
(Improper Neutralization of Special Elements)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
184
(Incomplete List of Disallowed Inputs)
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
Denylist / Deny List
Blocklist / Block List
Blacklist / Black List
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
470
(Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))
The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.
Reflection Injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
471
(Modification of Assumed-Immutable Data (MAID))
The product does not properly protect an assumed-immutable element from being modified by an attacker.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
564
(SQL Injection: Hibernate)
Using Hibernate to execute a dynamic SQL statement built with user-controlled input can allow an attacker to modify the statement's meaning or to execute arbitrary SQL commands.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
643
(Improper Neutralization of Data within XPath Expressions ('XPath Injection'))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
644
(Improper Neutralization of HTTP Headers for Scripting Syntax)
The product does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
652
(Improper Neutralization of Data within XQuery Expressions ('XQuery Injection'))
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1347
(OWASP Top Ten 2021 Category A03:2021 - Injection) >
917
(Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'))
The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.
EL Injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design)
Weaknesses in this category are related to the A04 "Insecure Design" category in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
73
(External Control of File Name or Path)
The product allows user input to control or influence paths or file names that are used in filesystem operations.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
183
(Permissive List of Allowed Inputs)
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.
Allowlist / Allow List
Safelist / Safe List
Whitelist / White List
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
209
(Generation of Error Message Containing Sensitive Information)
The product generates an error message that includes sensitive information about its environment, users, or associated data.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
213
(Exposure of Sensitive Information Due to Incompatible Policies)
The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
235
(Improper Handling of Extra Parameters)
The product does not handle or incorrectly handles when the number of parameters, fields, or arguments with the same name exceeds the expected amount.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
256
(Plaintext Storage of a Password)
The product stores a password in plaintext within resources such as memory or files.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
266
(Incorrect Privilege Assignment)
A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
269
(Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
280
(Improper Handling of Insufficient Permissions or Privileges )
The product 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 product in an invalid state.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
311
(Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
312
(Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
313
(Cleartext Storage in a File or on Disk)
The product stores sensitive information in cleartext in a file, or on disk.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
316
(Cleartext Storage of Sensitive Information in Memory)
The product stores sensitive information in cleartext in memory.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
419
(Unprotected Primary Channel)
The product uses a primary channel for administration or restricted functionality, but it does not properly protect the channel.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
430
(Deployment of Wrong Handler)
The wrong "handler" is assigned to process an object.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
434
(Unrestricted Upload of File with Dangerous Type)
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
Unrestricted File Upload
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
444
(Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))
The product acts as an intermediary HTTP agent
(such as a proxy or firewall) in the data flow between two
entities such as a client and server, but it does not
interpret malformed HTTP requests or responses in ways that
are consistent with how the messages will be processed by
those entities that are at the ultimate destination.
HTTP Request Smuggling
HTTP Response Smuggling
HTTP Smuggling
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
451
(User Interface (UI) Misrepresentation of Critical Information)
The user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
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
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
501
(Trust Boundary Violation)
The product mixes trusted and untrusted data in the same data structure or structured message.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
522
(Insufficiently Protected Credentials)
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
525
(Use of Web Browser Cache Containing Sensitive Information)
The web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
539
(Use of Persistent Cookies Containing Sensitive Information)
The web application uses persistent cookies, but the cookies contain sensitive information.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
579
(J2EE Bad Practices: Non-serializable Object Stored in Session)
The product stores a non-serializable object as an HttpSession attribute, which can hurt reliability.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
598
(Use of GET Request Method With Sensitive Query Strings)
The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
602
(Client-Side Enforcement of Server-Side Security)
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
642
(External Control of Critical State Data)
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
646
(Reliance on File Name or Extension of Externally-Supplied File)
The product allows a file to be uploaded, but it relies on the file name or extension of the file to determine the appropriate behaviors. This could be used by attackers to cause the file to be misclassified and processed in a dangerous fashion.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
650
(Trusting HTTP Permission Methods on the Server Side)
The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
653
(Improper Isolation or Compartmentalization)
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.
Separation of Privilege
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
656
(Reliance on Security Through Obscurity)
The product 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
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
657
(Violation of Secure Design Principles)
The product violates well-established principles for secure design.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
799
(Improper Control of Interaction Frequency)
The product does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests.
Insufficient anti-automation
Brute force
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
807
(Reliance on Untrusted Inputs in a Security Decision)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
840
(Business Logic Errors)
Weaknesses in this category identify some of the underlying problems that commonly allow attackers to manipulate the business logic of an application. Errors in business logic can be devastating to an entire application. They can be difficult to find automatically, since they typically involve legitimate use of the application's functionality. However, many business logic errors can exhibit patterns that are similar to well-understood implementation and design weaknesses.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
841
(Improper Enforcement of Behavioral Workflow)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
927
(Use of Implicit Intent for Sensitive Communication)
The Android application uses an implicit intent for transmitting sensitive data to other applications.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
1021
(Improper Restriction of Rendered UI Layers or Frames)
The web application does not restrict or incorrectly restricts frame objects or UI layers that belong to another application or domain, which can lead to user confusion about which interface the user is interacting with.
Clickjacking
UI Redress Attack
Tapjacking
1344
(Weaknesses in OWASP Top Ten (2021)) >
1348
(OWASP Top Ten 2021 Category A04:2021 - Insecure Design) >
1173
(Improper Use of Validation Framework)
The product does not use, or incorrectly uses, an input validation framework that is provided by the source language or an independent library.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration)
Weaknesses in this category are related to the A05 category "Security Misconfiguration" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
2
(7PK - Environment)
This category represents one of the phyla in the Seven Pernicious Kingdoms vulnerability classification. It includes weaknesses that are typically introduced during unexpected environmental conditions. According to the authors of the Seven Pernicious Kingdoms, "This section includes everything that is outside of the source code but is still critical to the security of the product that is being created. Because the issues covered by this kingdom are not directly related to source code, we separated it from the rest of the kingdoms."
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
11
(ASP.NET Misconfiguration: Creating Debug Binary)
Debugging messages help attackers learn about the system and plan a form of attack.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
13
(ASP.NET Misconfiguration: Password in Configuration File)
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
15
(External Control of System or Configuration Setting)
One or more system settings or configuration elements can be externally controlled by a user.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
16
(Configuration)
Weaknesses in this category are typically introduced during the configuration of the software.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
260
(Password in Configuration File)
The product stores a password in a configuration file that might be accessible to actors who do not know the password.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
315
(Cleartext Storage of Sensitive Information in a Cookie)
The product stores sensitive information in cleartext in a cookie.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
520
(.NET Misconfiguration: Use of Impersonation)
Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
526
(Cleartext Storage of Sensitive Information in an Environment Variable)
The product uses an environment variable to store unencrypted sensitive information.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
537
(Java Runtime Error Message Containing Sensitive Information)
In many cases, an attacker can leverage the conditions that cause unhandled exception errors in order to gain unauthorized access to the system.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
541
(Inclusion of Sensitive Information in an Include File)
If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
547
(Use of Hard-coded, Security-relevant Constants)
The product uses hard-coded constants instead of symbolic names for security-critical values, which increases the likelihood of mistakes during code maintenance or security policy change.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
611
(Improper Restriction of XML External Entity Reference)
The product 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
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
614
(Sensitive Cookie in HTTPS Session Without 'Secure' Attribute)
The Secure attribute for sensitive cookies in HTTPS sessions is not set.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
756
(Missing Custom Error Page)
The product does not return custom error pages to the user, possibly exposing sensitive information.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
776
(Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion'))
The product uses XML documents and allows their structure to be defined with a Document Type Definition (DTD), but it does not properly control the number of recursive definitions of entities.
XEE
Billion Laughs Attack
XML Bomb
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
942
(Permissive Cross-domain Security Policy with Untrusted Domains)
The product uses a web-client protection
mechanism such as a Content Security Policy (CSP) or
cross-domain policy file, but the policy includes untrusted
domains with which the web client is allowed to
communicate.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
1004
(Sensitive Cookie Without 'HttpOnly' Flag)
The product uses a cookie to store sensitive information, but the cookie is not marked with the HttpOnly flag.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
1032
(OWASP Top Ten 2017 Category A6 - Security Misconfiguration)
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2017.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1349
(OWASP Top Ten 2021 Category A05:2021 - Security Misconfiguration) >
1174
(ASP.NET Misconfiguration: Improper Model Validation)
The ASP.NET application does not use, or incorrectly uses, the model validation framework.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1352
(OWASP Top Ten 2021 Category A06:2021 - Vulnerable and Outdated Components)
Weaknesses in this category are related to the A06 category "Vulnerable and Outdated Components" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1352
(OWASP Top Ten 2021 Category A06:2021 - Vulnerable and Outdated Components) >
937
(OWASP Top Ten 2013 Category A9 - Using Components with Known Vulnerabilities)
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2013.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1352
(OWASP Top Ten 2021 Category A06:2021 - Vulnerable and Outdated Components) >
1035
(OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities)
Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2017.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1352
(OWASP Top Ten 2021 Category A06:2021 - Vulnerable and Outdated Components) >
1104
(Use of Unmaintained Third Party Components)
The product relies on third-party components that are not
actively supported or maintained by the original developer or a trusted proxy
for the original developer.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures)
Weaknesses in this category are related to the A07 category "Identification and Authentication Failures" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
255
(Credentials Management Errors)
Weaknesses in this category are related to the management of credentials.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
259
(Use of Hard-coded Password)
The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
287
(Improper Authentication)
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
authentification
AuthN
AuthC
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
288
(Authentication Bypass Using an Alternate Path or Channel)
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
290
(Authentication Bypass by Spoofing)
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
294
(Authentication Bypass by Capture-replay)
A capture-replay flaw exists when the design of the product 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).
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
295
(Improper Certificate Validation)
The product does not validate, or incorrectly validates, a certificate.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
297
(Improper Validation of Certificate with Host Mismatch)
The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
300
(Channel Accessible by Non-Endpoint)
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.
Adversary-in-the-Middle / AITM
Attacker-in-the-Middle / AITM
Man-in-the-Middle / MITM
Person-in-the-Middle / PITM
Monkey-in-the-Middle
Monster-in-the-Middle
Manipulator-in-the-Middle
On-path attack
Interception attack
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
304
(Missing Critical Step in Authentication)
The product implements an authentication technique, but it skips a step that weakens the technique.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
306
(Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
307
(Improper Restriction of Excessive Authentication Attempts)
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
346
(Origin Validation Error)
The product does not properly verify that the source of data or communication is valid.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
521
(Weak Password Requirements)
The product does not require that users should have strong passwords.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
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."
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
640
(Weak Password Recovery Mechanism for Forgotten Password)
The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
798
(Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
940
(Improper Verification of Source of a Communication Channel)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1353
(OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures) >
1216
(Lockout Mechanism Errors)
Weaknesses in this category are related to a software 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures)
Weaknesses in this category are related to the A08 category "Software and Data Integrity Failures" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
345
(Insufficient Verification of Data Authenticity)
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
353
(Missing Support for Integrity Check)
The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
426
(Untrusted Search Path)
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
Untrusted Path
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
502
(Deserialization of Untrusted Data)
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
Marshaling, Unmarshaling
Pickling, Unpickling
PHP Object Injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
565
(Reliance on Cookies without Validation and Integrity Checking)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
784
(Reliance on Cookies without Validation and Integrity Checking in a Security Decision)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
829
(Inclusion of Functionality from Untrusted Control Sphere)
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
830
(Inclusion of Web Functionality from an Untrusted Source)
The product includes web functionality (such as a web widget) from another domain, which causes it to operate within the domain of the product, potentially granting total access and control of the product to the untrusted source.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1354
(OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures) >
915
(Improperly Controlled Modification of Dynamically-Determined Object Attributes)
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.
Mass Assignment
AutoBinding
PHP Object Injection
1344
(Weaknesses in OWASP Top Ten (2021)) >
1355
(OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures)
Weaknesses in this category are related to the A09 category "Security Logging and Monitoring Failures" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1355
(OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures) >
117
(Improper Output Neutralization for Logs)
The product constructs a log message from external input, but it does not neutralize or incorrectly neutralizes special elements when the message is written to a log file.
Log forging
1344
(Weaknesses in OWASP Top Ten (2021)) >
1355
(OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures) >
223
(Omission of Security-relevant Information)
The product 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.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1355
(OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures) >
532
(Insertion of Sensitive Information into Log File)
The product writes sensitive information to a log file.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1355
(OWASP Top Ten 2021 Category A09:2021 - Security Logging and Monitoring Failures) >
778
(Insufficient Logging)
When a security-critical event occurs, the product either does not record the event or omits important details about the event when logging it.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1356
(OWASP Top Ten 2021 Category A10:2021 - Server-Side Request Forgery (SSRF))
Weaknesses in this category are related to the A10 category "Server-Side Request Forgery (SSRF)" in the OWASP Top Ten 2021.
1344
(Weaknesses in OWASP Top Ten (2021)) >
1356
(OWASP Top Ten 2021 Category A10:2021 - Server-Side Request Forgery (SSRF)) >
918
(Server-Side Request Forgery (SSRF))
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
XSPA
SSRF
Maintenance
As of CWE 4.6, the relationships in this view were pulled directly from the CWE mappings cited in the 2021 OWASP Top Ten. These mappings include categories and high-level weaknesses. One mapping to a deprecated entry was removed. The CWE Program will work with OWASP to improve these mappings, possibly requiring modifications to CWE itself.
View ComponentsA | 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-11: ASP.NET Misconfiguration: Creating Debug Binary
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production.
This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The file web.config contains the debug mode setting. Setting debug to "true" will let the browser display debugging information. (bad code)
Example Language: XML
<?xml version="1.0" encoding="utf-8" ?>
<configuration> <system.web> </configuration><compilation </system.web>defaultLanguage="c#" debug="true" /> ... Change the debug mode to false when the application is deployed into production.
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.
CWE-1174: ASP.NET Misconfiguration: Improper Model Validation
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe ASP.NET application does not use, or incorrectly uses, the model validation framework.
This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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.
CWE-13: ASP.NET Misconfiguration: Password in Configuration File
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterStoring a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.
This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 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 code)
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.
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.
CWE-302: Authentication Bypass by Assumed-Immutable Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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 code)
Example Language: Java
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) { ... }Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-294: Authentication Bypass by Capture-replay
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA capture-replay flaw exists when the design of the product 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).
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.
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-290: Authentication Bypass by Spoofing
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code authenticates users. (bad code)
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 code)
Example Language: C
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 code)
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 code)
Example Language: C
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 code)
Example Language: Java
String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip); if (addr.getCanonicalHostName().endsWith("trustme.com")) { trusted = true; }(bad code)
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-288: Authentication Bypass Using an Alternate Path or Channel
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1
Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not. Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset). Though this example is shown in Verilog, it will apply to VHDL as well. (informative)
Example Language: Verilog
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out; input [31:0] data_in, incoming_id, address; input clk, rst_n; wire write_auth, addr_auth; reg [31:0] data_out, acl_oh_allowlist, q; assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0; always @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;always @ (posedge clk or negedge rst_n)
if (!rst_n)
endmodule
begin
else
q <= 32'h0;
enddata_out <= 32'h0;
begin
end
q <= (addr_auth & write_auth) ? data_in: q;
enddata_out <= q; (bad code)
Example Language: Verilog
assign addr_auth = (address == 32'hF00) ? 1: 0;
The bugged line of code is repeated in the Bad example above. Weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME, the address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below. (good code)
Example Language: Verilog
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-639: Authorization Bypass Through User-Controlled Key
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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.
This table 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.
This table 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" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "CISQ Data Protection Measures" (View-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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 code)
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-566: Authorization Bypass Through User-Controlled SQL Primary Key
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product 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.
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:
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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 code)
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.
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.
CWE CATEGORY: Business Logic Errors
Weaknesses in this category identify some of the underlying problems that commonly allow attackers to manipulate the business logic of an application. Errors in business logic can be devastating to an entire application. They can be difficult to find automatically, since they typically involve legitimate use of the application's functionality. However, many business logic errors can exhibit patterns that are similar to well-understood implementation and design weaknesses.
Terminology The "Business Logic" term is generally used to describe issues that require domain-specific knowledge or "business rules" to determine if they are weaknesses or vulnerabilities, instead of legitimate behavior. Such issues might not be easily detectable via automatic code analysis, because the associated operations do not produce clear errors or undefined behavior at the code level. However, many such "business logic" issues can be understood as instances of other weaknesses such as input validation, access control, numeric computation, order of operations, etc. Research Gap The classification of business logic flaws has been under-studied, although exploitation of business flaws frequently happens in real-world systems, and many applied vulnerability researchers investigate them. The greatest focus is in web applications. There is debate within the community about whether these problems represent particularly new concepts, or if they are variations of well-known principles. Many business logic flaws appear to be oriented toward business processes, application flows, and sequences of behaviors, which are not as well-represented in CWE as weaknesses related to input validation, memory management, etc.
CWE-300: Channel Accessible by Non-Endpoint
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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.
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 In the Java snippet below, data is sent over an unencrypted channel to a remote server. (bad code)
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Maintenance
The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
CWE-313: Cleartext Storage in a File or on Disk
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
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.
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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 code)
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 code)
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
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).
CWE-312: Cleartext Storage of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code excerpt stores a plaintext user account ID in a browser cookie. (bad code)
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 code)
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 code)
Example Language: C
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 cleartext. This Java example shows a properties file with a cleartext username / password pair. (bad code)
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 code)
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. Example 5 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. At least one OT product stored a password in plaintext. Example 6 In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets. (bad code)
Example Language: Other
A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]
While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered. (good code)
Example Language: Other
The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]
Example 7 Consider the following PowerShell command examples for encryption scopes of Azure storage objects. In the first example, an encryption scope is set for the storage account. (bad code)
Example Language: Shell
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption
The result (edited and formatted for readability) might be: (bad code)
Example Language: Other
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount
However, the empty string under RequireInfrastructureEncryption indicates this service was not enabled at the time of creation, because the -RequireInfrastructureEncryption argument was not specified in the command. Including the -RequireInfrastructureEncryption argument addresses the issue: (good code)
Example Language: Shell
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption
This produces the report: (result)
Example Language: Other
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount
In a scenario where both software and hardware layer encryption is required ("double encryption"), Azure's infrastructure encryption setting can be enabled via the CLI or Portal. An important note is that infrastructure hardware encryption cannot be enabled or disabled after a blob is created. Furthermore, the default value for infrastructure encryption is disabled in blob creations. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
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).
Other
When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet.
CWE-315: Cleartext Storage of Sensitive Information in a Cookie
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
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.
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code excerpt stores a plaintext user account ID in a browser cookie. (bad code)
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. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
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).
CWE-526: Cleartext Storage of Sensitive Information in an Environment Variable
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
Information stored in an environment variable can be accessible by other processes with the execution context, including child processes that dependencies are executed in, or serverless functions in cloud environments. An environment variable's contents can also be inserted into messages, headers, log files, or other outputs. Often these other dependencies have no need to use the environment variable in question. A weakness that discloses environment variables could expose this information.
This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-316: Cleartext Storage of Sensitive Information in Memory
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the product 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. This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
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).
CWE-319: Cleartext Transmission of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "Hardware Design" (View-1194)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code attempts to establish a connection to a site to communicate sensitive information. (bad code)
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. Example 2 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used cleartext transmission of sensitive information in their OT products. Example 3 A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed. Example 4 The following Azure CLI command lists the properties of a particular storage account: (informative)
Example Language: Shell
az storage account show -g {ResourceGroupName} -n {StorageAccountName}
The JSON result might be: (bad code)
Example Language: JSON
{
"name": "{StorageAccountName}",
}
"enableHttpsTrafficOnly": false, "type": "Microsoft.Storage/storageAccounts" The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.). Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as: (good code)
Example Language: Shell
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true
The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true: (good code)
Example Language: JSON
{
"name": "{StorageAccountName}",
}
"enableHttpsTrafficOnly": true, "type": "Microsoft.Storage/storageAccounts"
Note: to enable secure transfer using Azure's Portal instead of the command line:
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Other
Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries.
CWE-602: Client-Side Enforcement of Server-Side Security
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
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.
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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 code)
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 code)
Example Language: Perl
$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. Example 2 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used client-side authentication in their OT products. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE CATEGORY: Configuration
Weaknesses in this category are typically introduced during the configuration of the software.
Maintenance
Further discussion about this category was held over the CWE Research mailing list in early 2020. No definitive action has been decided.
Maintenance
This entry is a Category, but various sources map to it anyway, despite CWE guidance that Categories should not be mapped. In this case, there are no clear CWE Weaknesses that can be utilized. "Inappropriate Configuration" sounds more like a Weakness in CWE's style, but it still does not indicate actual behavior of the product. Further research is still required, however, as a "configuration weakness" might be Primary to many other CWEs, i.e., it might be better described in terms of chaining relationships.
CWE CATEGORY: Credentials Management Errors
CWE-352: Cross-Site Request Forgery (CSRF)
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table 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.
This table 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" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 This example PHP code attempts to secure the form submission process by validating that the user submitting the form has a valid session. A CSRF attack would not be prevented by this countermeasure because the attacker forges a request through the user's web browser in which a valid session already exists. The following HTML is intended to allow a user to update a profile. (bad code)
Example Language: HTML
<form action="/url/profile.php" method="post">
<input type="text" name="firstname"/> <input type="text" name="lastname"/> <br/> <input type="text" name="email"/> <input type="submit" name="submit" value="Update"/> </form> profile.php contains the following code. (bad code)
Example Language: PHP
// initiate the session in order to validate sessions
session_start(); //if the session is registered to a valid user then allow update if (! session_is_registered("username")) { echo "invalid session detected!"; // Redirect user to login page [...] exit; // The user session is valid, so process the request // and update the information update_profile(); function update_profile { // read in the data from $POST and send an update // to the database SendUpdateToDatabase($_SESSION['username'], $_POST['email']); [...] echo "Your profile has been successfully updated."; This code may look protected since it checks for a valid session. However, CSRF attacks can be staged from virtually any tag or HTML construct, including image tags, links, embed or object tags, or other attributes that load background images. The attacker can then host code that will silently change the username and email address of any user that visits the page while remaining logged in to the target web application. The code might be an innocent-looking web page such as: (attack code)
Example Language: HTML
<SCRIPT>
function SendAttack () { form.email = "attacker@example.com"; }// send to profile.php form.submit(); </SCRIPT> <BODY onload="javascript:SendAttack();"> <form action="http://victim.example.com/profile.php" id="form" method="post"> <input type="hidden" name="firstname" value="Funny"> <input type="hidden" name="lastname" value="Joke"> <br/> <input type="hidden" name="email"> </form> Notice how the form contains hidden fields, so when it is loaded into the browser, the user will not notice it. Because SendAttack() is defined in the body's onload attribute, it will be automatically called when the victim loads the web page. Assuming that the user is already logged in to victim.example.com, profile.php will see that a valid user session has been established, then update the email address to the attacker's own address. At this stage, the user's identity has been compromised, and messages sent through this profile could be sent to the attacker's address. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Relationship There can be a close relationship between XSS and CSRF (CWE-352). An attacker might use CSRF in order to trick the victim into submitting requests to the server in which the requests contain an XSS payload. A well-known example of this was the Samy worm on MySpace [REF-956]. The worm used XSS to insert malicious HTML sequences into a user's profile and add the attacker as a MySpace friend. MySpace friends of that victim would then execute the payload to modify their own profiles, causing the worm to propagate exponentially. Since the victims did not intentionally insert the malicious script themselves, CSRF was a root cause. Theoretical The CSRF topology is multi-channel:
CWE CATEGORY: Cryptographic Issues
Weaknesses in this category are related to the design and implementation of data confidentiality and integrity. Frequently these deal with the use of encoding techniques, encryption libraries, and hashing algorithms. The weaknesses in this category could lead to a degradation of the quality data if they are not addressed.
CWE-430: Deployment of Wrong Handler
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
An example of deploying the wrong handler would be calling a servlet to reveal source code of a .JSP file, or automatically "determining" type of the object even if it is contradictory to an explicitly specified type.
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-502: Deserialization of Untrusted Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 This code snippet deserializes an object from a file and uses it as a UI button: (bad code)
Example Language: Java
try {
File file = new File("object.obj"); }ObjectInputStream in = new ObjectInputStream(new FileInputStream(file)); javax.swing.JButton button = (javax.swing.JButton) in.readObject(); in.close(); This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed. To mitigate this, explicitly define final readObject() to prevent deserialization. An example of this is: (good code)
Example Language: Java
private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); } Example 2 In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [REF-467], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token. (bad code)
Example Language: Python
try {
class ExampleProtocol(protocol.Protocol):
def dataReceived(self, data): # Code that would be here would parse the incoming data # After receiving headers, call confirmAuth() to authenticate def confirmAuth(self, headers): try: token = cPickle.loads(base64.b64decode(headers['AuthToken'])) if not check_hmac(token['signature'], token['data'], getSecretKey()): raise AuthFail self.secure_data = token['data'] except: raise AuthFail Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess module and execute /bin/sh. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-425: Direct Request ('Forced Browsing')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.
Web applications susceptible to direct request attacks often make the false assumption that such resources can only be reached through a given navigation path and so only apply authorization at certain points in the path.
This table 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.
This table 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" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 If forced browsing is possible, an attacker may be able to directly access a sensitive page by entering a URL similar to the following. (attack code)
Example Language: JSP
http://somesite.com/someapplication/admin.jsp
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Relationship
Overlaps Modification of Assumed-Immutable Data (MAID), authorization errors, container errors; often primary to other weaknesses such as XSS and SQL injection.
Theoretical
"Forced browsing" is a step-based manipulation involving the omission of one or more steps, whose order is assumed to be immutable. The application does not verify that the first step was performed successfully before the second step. The consequence is typically "authentication bypass" or "path disclosure," although it can be primary to all kinds of weaknesses, especially in languages such as PHP, which allow external modification of assumed-immutable variables.
CWE-494: Download of Code Without Integrity Check
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
An attacker can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit.
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 This example loads an external class from a local subdirectory. (bad code)
Example Language: Java
URL[] classURLs= new URL[]{
new URL("file:subdir/") };URLClassLoader loader = new URLClassLoader(classURLs); Class loadedClass = Class.forName("loadMe", true, loader); This code does not ensure that the class loaded is the intended one, for example by verifying the class's checksum. An attacker may be able to modify the class file to execute malicious code. Example 2 This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application. (bad code)
Example Language: PHP
//assume the password is already encrypted, avoiding CWE-312
function authenticate($username,$password){ include("http://external.example.com/dbInfo.php"); //dbInfo.php makes $dbhost, $dbuser, $dbpass, $dbname available mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql'); mysql_select_db($dbname); $query = 'Select * from users where username='.$username.' And password='.$password; $result = mysql_query($query); if(mysql_numrows($result) == 1){ mysql_close(); }return true; else{ mysql_close(); }return false; } This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow themself to access the application without a real user account. This example is also vulnerable to an Adversary-in-the-Middle AITM (CWE-300) attack. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Research Gap
This is critical for mobile code, but it is likely to become more and more common as developers continue to adopt automated, network-based product distributions and upgrades. Software-as-a-Service (SaaS) might introduce additional subtleties. Common exploitation scenarios may include ad server compromises and bad upgrades.
CWE-548: Exposure of Information Through Directory Listing
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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.
CWE-359: Exposure of Private Personal Information to an Unauthorized Actor
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account. (bad code)
Example Language: C#
pass = GetPassword();
... dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp); The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern. Example 2 This code uses location to determine the user's current US State location. First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml: (bad code)
Example Language: XML
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible: (bad code)
Example Language: Java
locationClient = new LocationClient(this, this, this);
locationClient.connect(); Location userCurrLocation; userCurrLocation = locationClient.getLastLocation(); deriveStateFromCoords(userCurrLocation); While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in. Example 3 In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Other There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information (PPI) may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation. Some types of private information include:
Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry. Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private. Maintenance
This entry overlaps many other
entries that are not organized around the kind of
sensitive information that is exposed, such as CWE-212:
Improper Removal of Sensitive Information Before Storage
or Transfer. However, because privacy is treated with
such importance due to regulations and other factors, and
it may be useful for weakness-finding tools to highlight
capabilities that detect personal private information
instead of system information, it is not clear whether -
or how - this entry should be deprecated.
CWE-668: Exposure of Resource to Wrong Sphere
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
Resources such as files and directories may be inadvertently exposed through mechanisms such as insecure permissions, or when a program accidentally operates on the wrong object. For example, a program may intend that private files can only be provided to a specific user. This effectively defines a control sphere that is intended to prevent attackers from accessing these private files. If the file permissions are insecure, then parties other than the user will be able to access those files. A separate control sphere might effectively require that the user can only access the private files, but not any other files on the system. If the program does not ensure that the user is only requesting private files, then the user might be able to access other files on the system. In either case, the end result is that a resource has been exposed to the wrong party. This table 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.
This table 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" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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.
Theoretical
A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.
CWE-213: Exposure of Sensitive Information Due to Incompatible Policies
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
When handling information, the developer must consider whether the information is regarded as sensitive by different stakeholders, such as users or administrators. Each stakeholder effectively has its own intended security policy that the product is expected to uphold. When a developer does not treat that information as sensitive, this can introduce a vulnerability that violates the expectations of the product's users. This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 This code displays some information on a web page. (bad code)
Example Language: JSP
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>
The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Theoretical
In vulnerability theory terms, this covers cases in which the developer's Intended Policy allows the information to be made available, but the information might be in violation of a Universal Policy in which the product's administrator should have control over which information is considered sensitive and therefore should not be exposed.
Maintenance
This entry is being considered for deprecation. It overlaps many other entries related to information exposures. It might not be essential to preserve this entry, since other key stakeholder policies are covered elsewhere, e.g. personal privacy leaks (CWE-359) and system-level exposures that are important to system administrators (CWE-497).
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:
Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:
Information exposures can occur in different ways:
It is common practice to describe any loss of confidentiality as an "information exposure," but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.
This table 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.
This table 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" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code checks validity of the supplied username and password and notifies the user of a successful or failed login. (bad code)
Example Language: Perl
my $username=param('username');
my $password=param('password'); if (IsValidUsername($username) == 1) { if (IsValidPassword($username, $password) == 1)
}
{ print "Login Successful";
}
else { print "Login Failed - incorrect password";
}
else { print "Login Failed - unknown username";
}
In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials. While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as: (result)
"Login Failed - incorrect username or password"
Example 2 This code tries to open a database connection, and prints any exceptions that occur. (bad code)
Example Language: PHP
try {
openDbConnection(); }//print exception message that includes exception message and configuration file location catch (Exception $e) { echo 'Caught exception: ', $e->getMessage(), '\n'; }echo 'Check credentials in config file at: ', $Mysql_config_location, '\n'; If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database. Example 3 In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file. (bad code)
Example Language: Java
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null; try { if (isAuthorizedUser(username)) { } catch (SQLException ex) {query = "SELECT * FROM accounts WHERE owner = " }+ username + " AND accountID = " + accountNumber; DatabaseManager dbManager = new DatabaseManager(); Connection conn = dbManager.getConnection(); Statement stmt = conn.createStatement(); ResultSet queryResult = stmt.executeQuery(query); userAccount = (BankAccount)queryResult.getObject(accountNumber); String logMessage = "Unable to retrieve account information from database,\nquery: " + query; }Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex); return userAccount; The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database. Example 4 This code stores location information about the current user: (bad code)
Example Language: Java
locationClient = new LocationClient(this, this, this);
locationClient.connect(); currentUser.setLocation(locationClient.getLastLocation()); ... catch (Exception e) { AlertDialog.Builder builder = new AlertDialog.Builder(this); }builder.setMessage("Sorry, this application has experienced an error."); AlertDialog alert = builder.create(); alert.show(); Log.e("ExampleActivity", "Caught exception: " + e + " While on User:" + User.toString()); When the application encounters an exception it will write the user object to the log. Because the user object contains location information, the user's location is also written to the log. Example 5 The following is an actual MySQL error statement: (result)
Example Language: SQL
Warning: mysql_pconnect(): Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4
The error clearly exposes the database credentials. Example 6 This code displays some information on a web page. (bad code)
Example Language: JSP
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>
The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary. Example 7 The following program changes its behavior based on a debug flag. (bad code)
Example Language: JSP
<% if (Boolean.getBoolean("debugEnabled")) {
%>
User account number: <%= acctNo %> <% } %> The code writes sensitive debug information to the client browser if the "debugEnabled" flag is set to true . Example 8 This code uses location to determine the user's current US State location. First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml: (bad code)
Example Language: XML
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible: (bad code)
Example Language: Java
locationClient = new LocationClient(this, this, this);
locationClient.connect(); Location userCurrLocation; userCurrLocation = locationClient.getLastLocation(); deriveStateFromCoords(userCurrLocation); While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Maintenance
As a result of mapping analysis in the 2020 Top 25 and more recent versions, this weakness is under review, since it is frequently misused in mapping to cover many problems that lead to loss of confidentiality. See Mapping Notes, Extended Description, and Alternate Terms.
CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not properly prevent sensitive system-level information from being accessed by unauthorized actors who do not have the same level of access to the underlying system as the product does.
Network-based products, such as web applications, often run on top of an operating system or similar environment. When the product communicates with outside parties, details about the underlying system are expected to remain hidden, such as path names for data files, other OS users, installed packages, the application environment, etc. This system information may be provided by the product itself, or buried within diagnostic or debugging messages. Debugging information helps an adversary learn about the system and form an attack plan. An information exposure occurs when system data or debugging information leaves the program through an output stream or logging function that makes it accessible to unauthorized parties. Using other weaknesses, an attacker could cause errors to occur; the response to these errors can reveal detailed system information, along with other impacts. An attacker can use messages that reveal technologies, operating systems, and product versions to tune the attack against known vulnerabilities in these technologies. A product may use diagnostic methods that provide significant implementation details such as stack traces as part of its error handling mechanism. This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code prints the path environment variable to the standard error stream: (bad code)
Example Language: C
char* path = getenv("PATH");
... sprintf(stderr, "cannot find exe on path %s\n", path); Example 2 This code prints all of the running processes belonging to the current user. (bad code)
Example Language: PHP
//assume getCurrentUser() returns a username that is guaranteed to be alphanumeric (avoiding CWE-78) $userName = getCurrentUser(); $command = 'ps aux | grep ' . $userName; system($command); If invoked by an unauthorized web user, it is providing a web page of potentially sensitive information on the underlying system, such as command-line arguments (CWE-497). This program is also potentially vulnerable to a PATH based attack (CWE-426), as an attacker may be able to create malicious versions of the ps or grep commands. While the program does not explicitly raise privileges to run the system commands, the PHP interpreter may by default be running with higher privileges than users. Example 3 The following code prints an exception to the standard error stream: (bad code)
Example Language: Java
try {
... } catch (Exception e) {e.printStackTrace(); }(bad code)
Example Language: Java
try {
... } catch (Exception e) {Console.Writeline(e); }Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program. Example 4 The following code constructs a database connection string, uses it to create a new connection to the database, and prints it to the console. (bad code)
Example Language: C#
string cs="database=northwind; server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs); ... Console.Writeline(cs); Depending on the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system is vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-651: Exposure of WSDL File Containing Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe Web services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).
An information exposure may occur if any of the following apply:
This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The WSDL for a service providing information on the best price of a certain item exposes the following method: float getBestPrice(String ItemID) An attacker might guess that there is a method setBestPrice (String ItemID, float Price) that is available and invoke that method to try and change the best price of a given item to their advantage. The attack may succeed if the attacker correctly guesses the name of the method, the method does not have proper access controls around it and the service itself has the functionality to update the best price of the item.
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.
CWE-472: External Control of Assumed-Immutable Web Parameter
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.
If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input. For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application. This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 In this example, a web application uses the value of a hidden form field (accountID) without having done any input validation because it was assumed to be immutable. (bad code)
Example Language: Java
String accountID = request.getParameter("accountID");
User user = getUserFromID(Long.parseLong(accountID)); Example 2 Hidden fields should not be trusted as secure parameters. An attacker can intercept and alter hidden fields in a post to the server as easily as user input fields. An attacker can simply parse the HTML for the substring: (bad code)
Example Language: HTML
<input type="hidden"
or even just "hidden". Hidden field values displayed later in the session, such as on the following page, can open a site up to cross-site scripting attacks. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Relationship
This is a primary weakness for many other weaknesses and functional consequences, including XSS, SQL injection, path disclosure, and file inclusion.
Theoretical
This is a technology-specific MAID problem.
CWE-642: External Control of Critical State Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
If an attacker can modify the state information without detection, then it could be used to perform unauthorized actions or access unexpected resources, since the application programmer does not expect that the state can be changed. State information can be stored in various locations such as a cookie, in a hidden web form field, input parameter or argument, an environment variable, a database record, within a settings file, etc. All of these locations have the potential to be modified by an attacker. When this state information is used to control security or determine resource usage, then it may create a vulnerability. For example, an application may perform authentication, then save the state in an "authenticated=true" cookie. An attacker may simply create this cookie in order to bypass the authentication. This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 In the following example, an authentication flag is read from a browser cookie, thus allowing for external control of user state data. (bad code)
Example Language: Java
Cookie[] cookies = request.getCookies();
for (int i =0; i< cookies.length; i++) { Cookie c = cookies[i]; }if (c.getName().equals("authenticated") && Boolean.TRUE.equals(c.getValue())) { authenticated = true; }Example 2 The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22). (bad code)
Example Language: Java
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName); ... rFile.delete(); Example 3 The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt. (bad code)
Example Language: Java
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr); out.println(arr); Example 4 This program is intended to execute a command that lists the contents of a restricted directory, then performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions check by the operating system. (bad code)
Example Language: C
#define DIR "/restricted/directory"
char cmd[500]; sprintf(cmd, "ls -l %480s", DIR); /* Raise privileges to those needed for accessing DIR. */ RaisePrivileges(...); system(cmd); DropPrivileges(...); ... This code may look harmless at first, since both the directory and the command are set to fixed values that the attacker can't control. The attacker can only see the contents for DIR, which is the intended program behavior. Finally, the programmer is also careful to limit the code that executes with raised privileges. However, because the program does not modify the PATH environment variable, the following attack would work: (attack code)
Example 5 The following code segment implements a basic server that uses the "ls" program to perform a directory listing of the directory that is listed in the "HOMEDIR" environment variable. The code intends to allow the user to specify an alternate "LANG" environment variable. This causes "ls" to customize its output based on a given language, which is an important capability when supporting internationalization. (bad code)
Example Language: Perl
$ENV{"HOMEDIR"} = "/home/mydir/public/";
my $stream = AcceptUntrustedInputStream(); while (<$stream>) { chomp;
if (/^ENV ([\w\_]+) (.*)/) { $ENV{$1} = $2; }elsif (/^QUIT/) { ... } elsif (/^LIST/) { open($fh, "/bin/ls -l $ENV{HOMEDIR}|"); }while (<$fh>) { SendOutput($stream, "FILEINFO: $_"); }close($fh); The programmer takes care to call a specific "ls" program and sets the HOMEDIR to a fixed value. However, an attacker can use a command such as "ENV HOMEDIR /secret/directory" to specify an alternate directory, enabling a path traversal attack (CWE-22). At the same time, other attacks are enabled as well, such as OS command injection (CWE-78) by setting HOMEDIR to a value such as "/tmp; rm -rf /". In this case, the programmer never intends for HOMEDIR to be modified, so input validation for HOMEDIR is not the solution. A partial solution would be an allowlist that only allows the LANG variable to be specified in the ENV command. Alternately, assuming this is an authenticated user, the language could be stored in a local file so that no ENV command at all would be needed. While this example may not appear realistic, this type of problem shows up in code fairly frequently. See CVE-1999-0073 in the observed examples for a real-world example with similar behaviors. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-73: External Control of File Name or Path
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product allows user input to control or influence paths or file names that are used in filesystem operations.
This could allow an attacker to access or modify system files or other files that are critical to the application. Path manipulation errors occur when the following two conditions are met: 1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.
For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker. This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22). (bad code)
Example Language: Java
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName); ... rFile.delete(); Example 2 The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt. (bad code)
Example Language: Java
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr); out.println(arr); Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Relationship The external control of filenames can be the primary link in chains with other file-related weaknesses, as seen in the CanPrecede relationships. This is because software systems use files for many different purposes: to execute programs, load code libraries, to store application data, to store configuration settings, record temporary data, act as signals or semaphores to other processes, etc. However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all. The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.
CWE-15: External Control of System or Configuration Setting
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterOne or more system settings or configuration elements can be externally controlled by a user.
Allowing external control of system settings can disrupt service or cause an application to behave in unexpected, and potentially malicious ways.
This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Architectural Concepts" (View-1008)
Relevant to the view "Seven Pernicious Kingdoms" (View-700)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following C code accepts a number as one of its command line parameters and sets it as the host ID of the current machine. (bad code)
Example Language: C
...
sethostid(argv[1]); ... Although a process must be privileged to successfully invoke sethostid(), unprivileged users may be able to invoke the program. The code in this example allows user input to directly control the value of a system setting. If an attacker provides a malicious value for host ID, the attacker can misidentify the affected machine on the network or cause other unintended behavior. Example 2 The following Java code snippet reads a string from an HttpServletRequest and sets it as the active catalog for a database Connection. (bad code)
Example Language: Java
...
conn.setCatalog(request.getParameter("catalog")); ... In this example, an attacker could cause an error by providing a nonexistent catalog name or connect to an unauthorized portion of the database.
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.
CWE-610: Externally Controlled Reference to a Resource in Another Sphere
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
This table 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.
This table 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" (View-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address. (bad code)
Example Language: Java
public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString(); }if (query.contains("url")) { String url = request.getParameter("url"); }response.sendRedirect(url); The problem with this Java servlet code is that an attacker could use the RedirectServlet as part of an e-mail phishing scam to redirect users to a malicious site. An attacker could send an HTML formatted e-mail directing the user to log into their account by including in the e-mail the following link: (attack code)
Example Language: HTML
<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>
The user may assume that the link is safe since the URL starts with their trusted bank, bank.example.com. However, the user will then be redirected to the attacker's web site (attacker.example.net) which the attacker may have made to appear very similar to bank.example.com. The user may then unwittingly enter credentials into the attacker's web page and compromise their bank account. A Java servlet should never redirect a user to a URL without verifying that the redirect address is a trusted site. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Relationship
This is a general class of weakness, but most research is focused on more specialized cases, such as path traversal (CWE-22) and symlink following (CWE-61). A symbolic link has a name; in general, it appears like any other file in the file system. However, the link includes a reference to another file, often in another directory - perhaps in another sphere of control. Many common library functions that accept filenames will "follow" a symbolic link and use the link's target instead.
Maintenance
The relationship between CWE-99 and CWE-610 needs further investigation and clarification. They might be duplicates. CWE-99 "Resource Injection," as originally defined in Seven Pernicious Kingdoms taxonomy, emphasizes the "identifier used to access a system resource" such as a file name or port number, yet it explicitly states that the "resource injection" term does not apply to "path manipulation," which effectively identifies the path at which a resource can be found and could be considered to be one aspect of a resource identifier. Also, CWE-610 effectively covers any type of resource, whether that resource is at the system layer, the application layer, or the code layer.
CWE-75: Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not adequately filter user-controlled input for special elements with control implications.
This table 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.
This table 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" (View-1000)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
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.
CWE-552: Files or Directories Accessible to External Parties
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product makes files or directories accessible to unauthorized actors, even though they should not be.
Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories. In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user. This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 The following Azure command updates the settings for a storage account: (bad code)
Example Language: Shell
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access true
However, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs. The command could be modified to disable "Allow Blob Public Access" by setting it to false. (good code)
Example Language: Shell
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access false
Example 2 The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME': (informative)
Example Language: Shell
gsutil iam get gs://BUCKET_NAME
Suppose the command returns the following result: (bad code)
Example Language: JSON
{
"bindings":[{
}
"members":[
},
"projectEditor: PROJECT-ID",
],"projectOwner: PROJECT-ID" "role":"roles/storage.legacyBucketOwner" {
"members":[
]
"allUsers",
}"projectViewer: PROJECT-ID" ], "role":"roles/storage.legacyBucketReader" This result includes the "allUsers" or IAM role added as members, causing this policy configuration to allow public access to cloud storage resources. There would be a similar concern if "allAuthenticatedUsers" was present. The command could be modified to remove "allUsers" and/or "allAuthenticatedUsers" as follows: (good code)
Example Language: Shell
gsutil iam ch -d allUsers gs://BUCKET_NAME
gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
CWE-209: Generation of Error Message Containing Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter This table 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.
This table 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" (View-1000)
Relevant to the view "Software Development" (View-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Relevant to the view "Architectural Concepts" (View-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 In the following example, sensitive information might be printed depending on the exception that occurs. (bad code)
Example Language: Java
try {
/.../ }catch (Exception e) { System.out.println(e); }If an exception related to SQL is handled by the catch, then the output might contain sensitive information such as SQL query structure or private information. If this output is redirected to a web user, this may represent a security problem. Example 2 This code tries to open a database connection, and prints any exceptions that occur. (bad code)
Example Language: PHP
try {
openDbConnection(); }//print exception message that includes exception message and configuration file location catch (Exception $e) { echo 'Caught exception: ', $e->getMessage(), '\n'; }echo 'Check credentials in config file at: ', $Mysql_config_location, '\n'; If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database. Example 3 The following code generates an error message that leaks the full pathname of the configuration file. If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application. Example 4 In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file. (bad code)
Example Language: Java
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null; try { if (isAuthorizedUser(username)) { } catch (SQLException ex) {query = "SELECT * FROM accounts WHERE owner = " }+ username + " AND accountID = " + accountNumber; DatabaseManager dbManager = new DatabaseManager(); Connection conn = dbManager.getConnection(); Statement stmt = conn.createStatement(); ResultSet queryResult = stmt.executeQuery(query); userAccount = (BankAccount)queryResult.getObject(accountNumber); String logMessage = "Unable to retrieve account information from database,\nquery: " + query; }Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex); return userAccount; The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Other The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more serious attacks. The error message may be created in different ways:
CWE-329: Generation of Predictable IV with CBC Mode
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
CBC mode eliminates a weakness of Electronic Code Book (ECB) mode by allowing identical plaintext blocks to be encrypted to different ciphertext blocks. This is possible by the XOR-ing of an IV with the initial plaintext block so that every plaintext block in the chain is XOR'd with a different value before encryption. If IVs are reused, then identical plaintexts would be encrypted to identical ciphertexts. However, even if IVs are not identical but are predictable, then they still break the security of CBC mode against Chosen Plaintext Attacks (CPA). This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 In the following examples, CBC mode is used when encrypting data: (bad code)
Example Language: C
EVP_CIPHER_CTX ctx;
char key[EVP_MAX_KEY_LENGTH]; char iv[EVP_MAX_IV_LENGTH]; RAND_bytes(key, b); memset(iv,0,EVP_MAX_IV_LENGTH); EVP_EncryptInit(&ctx,EVP_bf_cbc(), key,iv); (bad code)
Example Language: Java
public class SymmetricCipherTest {
public static void main() {
byte[] text ="Secret".getBytes(); byte[] iv ={ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };KeyGenerator kg = KeyGenerator.getInstance("DES"); kg.init(56); SecretKey key = kg.generateKey(); Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding"); IvParameterSpec ips = new IvParameterSpec(iv); cipher.init(Cipher.ENCRYPT_MODE, key, ips); return cipher.doFinal(inpBytes); In both of these examples, the initialization vector (IV) is always a block of zeros. This makes the resulting cipher text much more predictable and susceptible to a dictionary attack. Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Maintenance
As of CWE 4.5, terminology related to randomness, entropy, and
predictability can vary widely. Within the developer and other
communities, "randomness" is used heavily. However, within
cryptography, "entropy" is distinct, typically implied as a
measurement. There are no commonly-used definitions, even within
standards documents and cryptography papers. Future versions of
CWE will attempt to define these terms and, if necessary,
distinguish between them in ways that are appropriate for
different communities but do not reduce the usability of CWE for
mapping, understanding, or other scenarios.
CWE-340: Generation of Predictable Numbers or Identifiers
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product uses a scheme that generates numbers or identifiers that are more predictable than required.
This table 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.
This table 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" (View-1000)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows 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.
Example 1 This code generates a unique random identifier for a user's session. (bad code)
Example Language: PHP
function generateSessionID($userID){
srand($userID); }return rand(); Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session. This example also exhibits a Small Seed Space (CWE-339). Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
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.
Maintenance
As of CWE 4.5, terminology related to randomness, entropy, and
predictability can vary widely. Within the developer and other
communities, "randomness" is used heavily. However, within
cryptography, "entropy" is distinct, typically implied as a
measurement. There are no commonly-used definitions, even within
standards documents and cryptography papers. Future versions of
CWE will attempt to define these terms and, if necessary,
distinguish between them in ways that are appropriate for
different communities but do not reduce the usability of CWE for
mapping, understanding, or other scenarios.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

