All posts by rocco

CWE

CWE-644 – Improper Neutralization of HTTP Headers for Scripting Syntax

Read Time:45 Second

Description

The application 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.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-116

 

Consequences

Integrity, Confidentiality, Availability: Execute Unauthorized Code or Commands

Run arbitrary code.

Confidentiality: Read Application Data

Attackers may be able to obtain sensitive information.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Perform output validation in order to filter/escape/encode unsafe data that is being passed from the server in an HTTP response header.

Phase: Architecture and Design

Description: 

Disable script execution functionality in the clients’ browser.

CVE References

  • CVE-2006-3918
    • Web server does not remove the Expect header from an HTTP request when it is reflected back in an error message, allowing a Flash SWF file to perform XSS attacks.
CWE

CWE-646 – Reliance on File Name or Extension of Externally-Supplied File

Read Time:1 Minute, 30 Second

Description

The software 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.

An application might use the file name or extension of of a user-supplied file to determine the proper course of action, such as selecting the correct process to which control should be passed, deciding what data should be made available, or what resources should be allocated. If the attacker can cause the code to misclassify the supplied file, then the wrong action could occur. For example, an attacker could supply a file that ends in a “.php.gif” extension that appears to be a GIF image, but would be processed as PHP code. In extreme cases, code execution is possible, but the attacker could also cause exhaustion of resources, denial of service, exposure of debug or system data (including application source code), or being bound to a particular server side process. This weakness may be due to a vulnerability in any of the technologies used by the web and application servers, due to misconfiguration, or resultant from another flaw in the application itself.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: High

 

Related Weaknesses

CWE-345

 

Consequences

Confidentiality: Read Application Data

An attacker may be able to read sensitive data.

Availability: DoS: Crash, Exit, or Restart

An attacker may be able to cause a denial of service.

Access Control: Gain Privileges or Assume Identity

An attacker may be able to gain privileges.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Make decisions on the server side based on file content and not on file name or extension.

CVE References

CWE

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

Read Time:2 Minute, 9 Second

Description

The software 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.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Medium

 

Related Weaknesses

CWE-669
CWE-693
CWE-471
CWE-290
CWE-300

 

Consequences

Access Control, Availability: Bypass Protection Mechanism, DoS: Crash, Exit, or Restart

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

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

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

Phase: Testing

Description: 

Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software’s operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Phase: Testing

Description: 

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

CVE References

  • CVE-2006-6994
    • ASP program allows upload of .asp files by bypassing client-side checks.
  • CVE-2007-0163
    • steganography products embed password information in the carrier file, which can be extracted from a modified client.
  • CVE-2007-0164
    • steganography products embed password information in the carrier file, which can be extracted from a modified client.
  • CVE-2007-0100
    • client allows server to modify client’s configuration and overwrite arbitrary files.
CWE

CWE-603 – Use of Client-Side Authentication

Read Time:42 Second

Description

A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.

Client-side authentication is extremely weak and may be breached easily. Any attacker may read the source code and reverse-engineer the authentication mechanism to access parts of the application which would otherwise be protected.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-602
CWE-287
CWE-300
CWE-656

 

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Do not rely on client side data. Always perform server side authentication.

CVE References

  • CVE-2006-0230
    • Client-side check for a password allows access to a server using crafted XML requests from a modified client.
CWE

CWE-605 – Multiple Binds to the Same Port

Read Time:41 Second

Description

When multiple sockets are allowed to bind to the same port, other services on that port may be stolen or spoofed.

On most systems, a combination of setting the SO_REUSEADDR socket option, and a call to bind() allows any process to bind to a port to which a previous process has bound with INADDR_ANY. This allows a user to bind to the specific address of a server bound to INADDR_ANY on an unprivileged port, and steal its UDP packets/TCP connection.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-675
CWE-666

 

Consequences

Confidentiality, Integrity: Read Application Data

Packets from a variety of network services may be stolen or the services spoofed.

 

Potential Mitigations

Phase: Policy

Description: 

Restrict server socket address to known local addresses.

CVE References

CWE

CWE-606 – Unchecked Input for Loop Condition

Read Time:21 Second

Description

The product does not properly check inputs that are used for loop conditions, potentially leading to a denial of service or other consequences because of excessive looping.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1284
CWE-834

 

Consequences

Availability: DoS: Resource Consumption (CPU)

 

Potential Mitigations

Phase: Implementation

Description: 

Do not use user-controlled data for loop conditions.

Phase: Implementation

Description: 

Perform input validation.

CVE References

CWE

CWE-607 – Public Static Final Field References Mutable Object

Read Time:20 Second

Description

A public or protected static final field references a mutable object, which allows the object to be changed by malicious code, or accidentally from another package.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-471

 

Consequences

Integrity: Modify Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

Protect mutable objects by making them private. Restrict access to the getter and setter as well.

CVE References

CWE

CWE-608 – Struts: Non-private Field in ActionForm Class

Read Time:26 Second

Description

An ActionForm class contains a field that has not been declared private, which can be accessed without using a setter or getter.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Integrity, Confidentiality: Modify Application Data, Read Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

Make all fields private. Use getter to get the value of the field. Setter should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided.

CVE References

CWE

CWE-609 – Double-Checked Locking

Read Time:1 Minute, 6 Second

Description

The program uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.

Double-checked locking refers to the situation where a programmer checks to see if a resource has been initialized, grabs a lock, checks again to see if the resource has been initialized, and then performs the initialization if it has not occurred yet. This should not be done, as is not guaranteed to work in all languages and on all architectures. In summary, other threads may not be operating inside the synchronous block and are not guaranteed to see the operations execute in the same order as they would appear inside the synchronous block.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-667
CWE-367

 

Consequences

Integrity, Other: Modify Application Data, Alter Execution Logic

 

Potential Mitigations

Phase: Implementation

Description: 

While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the “volatile” keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references.

CVE References