The software receives data from an upstream component, but does not completely filter one or more instances of special elements before sending it to a downstream component.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Integrity: Unexpected State
The software receives data from an upstream component, but only filters a single instance of a special element before sending it to a downstream component.
Incomplete filtering of this nature may be location-dependent, as in only the first or last element is filtered.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Integrity: Unexpected State
The software receives data from an upstream component, but does not filter all instances of a special element before sending it to a downstream component.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Integrity: Unexpected State
The software receives data from an upstream component, but only accounts for special elements at a specified location, thereby missing remaining special elements that may exist before sending it to a downstream component.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Integrity: Unexpected State
The software receives data from an upstream component, but only accounts for special elements positioned relative to a marker (e.g. “at the beginning/end of a string; the second argument”), thereby missing remaining special elements that may exist before sending it to a downstream component.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Integrity: Unexpected State
The software receives data from an upstream component, but only accounts for special elements at an absolute position (e.g. “byte number 10”), thereby missing remaining special elements that may exist before sending it to a downstream component.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Integrity: Unexpected State
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: High
CWE-287
CWE-287
CWE-344
CWE-671
CWE-257
Access Control: Bypass Protection Mechanism
If hard-coded passwords are used, it is almost certain that malicious users will gain access to the account in question.
Integrity, Confidentiality, Availability, Access Control, Other: Read Application Data, Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, Other
This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.
Phase: Architecture and Design
Effectiveness:
Description:
Phase: Architecture and Design
Effectiveness:
Description:
For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a “first login” mode that requires the user to enter a unique strong password or key.
Phase: Architecture and Design
Effectiveness:
Description:
If the software must contain hard-coded credentials or they cannot be removed, perform access control checks and limit which entities can access the feature that requires the hard-coded credentials. For example, a feature might only be enabled through the system console instead of through a network connection.
Phase: Architecture and Design
Effectiveness:
Description:
Phase: Architecture and Design
Effectiveness:
Description:
The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests.
This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Availability, Access Control, Other: DoS: Resource Consumption (Other), Bypass Protection Mechanism, Other
When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean’s data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application’s expectations, potentially leading to other vulnerabilities.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Confidentiality, Integrity: Read Application Data, Modify Application Data
Phase: Implementation
Effectiveness:
Description:
Declare Java beans “local” when possible. When a bean must be remotely accessible, make sure that sensitive information is not exposed, and ensure that the application logic performs appropriate validation of any data that might be modified by an attacker.
The software 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.
This may allow such characters to be treated as control characters, which are executed client-side in the context of the user’s session. Although this can be classified as an injection problem, the more pertinent issue is the improper conversion of such special characters to respective context-appropriate entities before displaying them to the user.
Modes of Introduction:
– Implementation
Likelihood of Exploit: High
Confidentiality, Integrity, Availability: Read Application Data, Execute Unauthorized Code or Commands
Phase: Implementation
Effectiveness:
Description:
Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.
Phase: Implementation
Effectiveness:
Description:
Phase: Implementation
Effectiveness:
Description:
With Struts, write all data from form beans with the bean’s filter attribute set to true.
Phase: Implementation
Effectiveness: Defense in Depth
Description:
To help mitigate XSS attacks against the user’s session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user’s session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.