Description
A static code block creates an instance of a class.
Modes of Introduction:
Related Weaknesses
Consequences
Other: Reduce Performance
A static code block creates an instance of a class.
Modes of Introduction:
Other: Reduce Performance
The software contains a function, subroutine, or method whose signature has an unnecessarily large number of
parameters/arguments.
Modes of Introduction:
Other: Reduce Maintainability
The application uses deployed components from application servers, but it also uses low-level functions/methods for management of resources, instead of the API provided by the application server.
Modes of Introduction:
Other: Reduce Reliability
The software uses a cookie to store sensitive information, but the cookie is not marked with the HttpOnly flag.
The HttpOnly flag directs compatible browsers to prevent client-side script from accessing cookies. Including the HttpOnly flag in the Set-Cookie HTTP response header helps mitigate the risk associated with Cross-Site Scripting (XSS) where an attacker’s script code might attempt to read the contents of a cookie and exfiltrate information obtained. When set, browsers that support the flag will not reveal the contents of the cookie to a third party via client-side script executed via XSS.
An HTTP cookie is a small piece of data attributed to a specific website and stored on the user’s computer by the user’s web browser. This data can be leveraged for a variety of purposes including saving information entered into form fields, recording user activity, and for authentication purposes. Cookies used to save or record information generated by the user are accessed and modified by script code embedded in a web page. While cookies used for authentication are created by the website’s server and sent to the user to be attached to future requests. These authentication cookies are often not meant to be accessed by the web page sent to the user, and are instead just supposed to be attached to future requests to verify authentication details.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Medium
Confidentiality: Read Application Data
If the HttpOnly flag is not set, then sensitive information stored in the cookie may be exposed to unintended parties.
Integrity: Gain Privileges or Assume Identity
If the cookie in question is an authentication cookie, then not setting the HttpOnly flag may allow an adversary to steal authentication data (e.g., a session ID) and assume the identity of the user.
Phase: Implementation
Effectiveness: High
Description:
Leverage the HttpOnly flag when setting a sensitive cookie in a response.
While this mitigation is effective for protecting cookies from a browser’s own scripting engine, third-party components or plugins may have their own engines that allow access to cookies. Attackers might also be able to use XMLHTTPResponse to read the headers directly and obtain the cookie.
The software displays information or identifiers to a user, but the display mechanism does not make it easy for the user to distinguish between visually similar or identical glyphs (homoglyphs), which may cause the user to misinterpret a glyph and perform an unintended, insecure action.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Integrity, Confidentiality: Other
An attacker may ultimately redirect a user to a malicious website, by deceiving the user into believing the URL they are accessing is a trusted domain. However, the attack can also be used to forge log entries by using homoglyphs in usernames. Homoglyph manipulations are often the first step towards executing advanced attacks such as stealing a user’s credentials, Cross-Site Scripting (XSS), or log forgery. If an attacker redirects a user to a malicious site, the attacker can mimic a trusted domain to steal account credentials and perform actions on behalf of the user, without the user’s knowledge. Similarly, an attacker could create a username for a website that contains homoglyph characters, making it difficult for an admin to review logs and determine which users performed which actions.
Phase: Implementation
Description:
Phase: Implementation
Description:
The application uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.
If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer’s expectations, possibly leading to resultant weaknesses. Moreover, it indicates that the validation logic is not up-to-date, and can indicate that other, more subtle validation errors are present.
Modes of Introduction:
– Implementation
Integrity: Unexpected State
Phase: Implementation
Description:
The DTD or schema validation will not catch the duplicate occurrence of the same form name. To find the issue in the implementation, manual checks or automated static analysis could be applied to the xml configuration files.
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.
A web application is expected to place restrictions on whether it is allowed to be rendered within frames, iframes, objects, embed or applet elements. Without the restrictions, users can be tricked into interacting with the application when they were not intending to.
Modes of Introduction:
– Implementation
Access Control: Gain Privileges or Assume Identity, Bypass Protection Mechanism, Read Application Data, Modify Application Data
An attacker can trick a user into performing actions that are masked and hidden from the user’s view. The impact varies widely, depending on the functionality of the underlying application. For example, in a social media application, clickjacking could be used to trik the user into changing privacy settings.
Phase: Implementation
Description:
Phase: Implementation
Description:
Phase: Implementation
Description:
This defense-in-depth technique can be used to prevent the improper usage of frames in web applications. It prioritizes the valid sources of data to be loaded into the application through the usage of declarative policies. Based on which implementation of Content Security Policy is in use, the developer should use the “frame-ancestors” directive or the “frame-src” directive to mitigate this weakness. Both directives allow for the placement of restrictions when it comes to allowing embedded content.
The web application produces links to untrusted external sites outside of its sphere of control, but it does not properly prevent the external site from modifying security-critical properties of the window.opener object, such as the location property.
When a user clicks a link to an external site (“target”), the target=”_blank” attribute causes the target site’s contents to be opened in a new window or tab, which runs in the same process as the original page. The window.opener object records information about the original page that offered the link. If an attacker can run script on the target page, then they could read or modify certain properties of the window.opener object, including the location property – even if the original and target site are not the same origin. An attacker can modify the location property to automatically redirect the user to a malicious site, e.g. as part of a phishing attack. Since this redirect happens in the original window/tab – which is not necessarily visible, since the browser is focusing the display on the new target page – the user might not notice any suspicious redirection.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Confidentiality: Alter Execution Logic
The user may be redirected to an untrusted page that contains undesired content or malicious script code.
Phase: Architecture and Design
Description:
Specify in the design that any linked external document must not be granted access to the location object of the calling page.
Phase: Implementation
Description:
Phase: Implementation
Description:
The software performs a comparison between entities that must consider multiple factors or characteristics of each entity, but the comparison does not include one or more of these factors.
An incomplete comparison can lead to resultant weaknesses, e.g., by operating on the wrong object or making a security decision without considering a required factor.
Modes of Introduction:
– Implementation
Integrity, Access Control: Alter Execution Logic, Bypass Protection Mechanism
Phase: Testing
Description:
Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing.
The software performs a comparison between two entities, but the entities are of different, incompatible types that cannot be guaranteed to provide correct results when they are directly compared.
In languages that are strictly typed but support casting/conversion, such as C or C++, the programmer might assume that casting one entity to the same type as another entity will ensure that the comparison will be performed correctly, but this cannot be guaranteed. In languages that are not strictly typed, such as PHP or JavaScript, there may be implicit casting/conversion to a type that the programmer is unaware of, causing unexpected results; for example, the string “123” might be converted to a number type. See examples.
Modes of Introduction:
– Implementation
Other: Varies by Context
Phase: Testing
Description:
Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing.