CWE VIEW: Weaknesses in OWASP Top Ten (2010)
CWE nodes in this view (graph) are associated with the OWASP Top Ten, as released in 2010. This view is considered obsolete as a newer version of the OWASP Top Ten is available.
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:
809 - Weaknesses in OWASP Top Ten (2010)
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
810
(OWASP Top Ten 2010 Category A1 - Injection)
Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
810
(OWASP Top Ten 2010 Category A1 - 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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
810
(OWASP Top Ten 2010 Category A1 - 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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
810
(OWASP Top Ten 2010 Category A1 - 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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
810
(OWASP Top Ten 2010 Category A1 - 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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
810
(OWASP Top Ten 2010 Category A1 - 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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
811
(OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS))
Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
811
(OWASP Top Ten 2010 Category A2 - Cross-Site Scripting (XSS)) >
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
CSS
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
812
(OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management)
Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
812
(OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
812
(OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
812
(OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
812
(OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management) >
798
(Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References)
Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
862
(Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
AuthZ
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
813
(OWASP Top Ten 2010 Category A4 - Insecure Direct Object References) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
814
(OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF))
Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
814
(OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF)) >
352
(Cross-Site Request Forgery (CSRF))
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
Session Riding
Cross Site Reference Forgery
XSRF
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration)
Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration) >
250
(Execution with Unnecessary Privileges)
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration) >
552
(Files or Directories Accessible to External Parties)
The product makes files or directories accessible to unauthorized actors, even though they should not be.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
815
(OWASP Top Ten 2010 Category A6 - Security Misconfiguration) >
732
(Incorrect Permission Assignment for Critical Resource)
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
816
(OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage)
Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
816
(OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) >
311
(Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
816
(OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) >
312
(Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
816
(OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
816
(OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
816
(OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
817
(OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access)
Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
817
(OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
817
(OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access) >
862
(Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
AuthZ
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
817
(OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access) >
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
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
818
(OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection) >
311
(Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
818
(OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection) >
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.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
819
(OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards)
Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2010.
![]() ![]()
809
(Weaknesses in OWASP Top Ten (2010)) >
819
(OWASP Top Ten 2010 Category A10 - Unvalidated Redirects and Forwards) >
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
Relationship
The relationships in this view are a direct extraction of the CWE mappings that are in the 2010 OWASP document. CWE has changed since the release of that document.
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-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.
![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) 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.
![]()
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 FilterThe product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
Because the information is stored in cleartext (i.e., unencrypted), attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information. When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet. In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) 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.
![]()
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 FilterThe product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data. 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. When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. 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. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Often Prevalent) Class: System on Chip (Undetermined Prevalence) Test/Debug Hardware (Often Prevalent) 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:
![]()
Maintenance
The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
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 FilterThe web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.
![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Web Server (Undetermined Prevalence) 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.
![]()
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-250: Execution with Unnecessary Privileges
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 performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges. Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Mobile (Undetermined Prevalence) Example 1 This code temporarily raises the program's privileges to allow creation of a new user folder. (bad code)
Example Language: Python
def makeNewUserDir(username):
While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur. Example 2 The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file. (bad code)
Example Language: C
chroot(APP_HOME);
chdir("/"); FILE* data = fopen(argv[1], "r+"); ... Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced. Example 3 This application intends to use a user's location to determine the timezone the user is in: (bad code)
Example Language: Java
locationClient = new LocationClient(this, this, this);
locationClient.connect(); Location userCurrLocation; userCurrLocation = locationClient.getLastLocation(); setTimeZone(userCurrLocation); This is unnecessary use of the location API, as this information is already available using the Android Time API. Always be sure there is not another way to obtain needed information before resorting to using the location API. Example 4 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.
![]()
Relationship Maintenance Maintenance
The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
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. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Not Technology-Specific (Undetermined Prevalence) Class: Cloud Computing (Often Prevalent) 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
![]()
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 |