All posts by rocco

CWE

CWE-581 – Object Model Violation: Just One of Equals and Hashcode Defined

Read Time:41 Second

Description

The software does not maintain equal hashcodes for equal objects.

Java objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.equals(b) == true then a.hashCode() == b.hashCode().

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-573
CWE-697

 

Consequences

Integrity, Other: Other

If this invariant is not upheld, it is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Map or Set, it is critical that equal objects have equal hashcodes.

 

Potential Mitigations

Phase: Implementation

Description: 

Both Equals() and Hashcode() should be defined.

CVE References

CWE

CWE-582 – Array Declared Public, Final, and Static

Read Time:1 Minute, 11 Second

Description

The program declares an array public, final, and static, which is not sufficient to prevent the array’s contents from being modified.

Because arrays are mutable objects, the final constraint requires that the array object itself be assigned only once, but makes no guarantees about the values of the array elements. Since the array is public, a malicious program can change the values stored in the array. As such, in most cases an array declared public, final and static is a bug.

Mobile code, in this case a Java Applet, is code that is transmitted across a network and executed on a remote machine. Because mobile code developers have little if any control of the environment in which their code will execute, special security concerns become relevant. One of the biggest environmental threats results from the risk that the mobile code will run side-by-side with other, potentially malicious, mobile code. Because all of the popular web browsers execute code from multiple sources together in the same JVM, many of the security guidelines for mobile code are focused on preventing manipulation of your objects’ state and behavior by adversaries who have access to the same virtual machine where your program is running.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Integrity: Modify Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

In most situations the array should be made private.

CVE References

CWE

CWE-583 – finalize() Method Declared Public

Read Time:37 Second

Description

The program violates secure coding principles for mobile code by declaring a finalize() method public.

A program should never call finalize explicitly, except to call super.finalize() inside an implementation of finalize(). In mobile code situations, the otherwise error prone practice of manual garbage collection can become a security threat if an attacker can maliciously invoke a finalize() method because it is declared with public access.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-668

 

Consequences

Confidentiality, Integrity, Availability: Alter Execution Logic, Execute Unauthorized Code or Commands, Modify Application Data

 

Potential Mitigations

Phase: Implementation

Description: 

If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access.

CVE References

CWE

CWE-546 – Suspicious Comment

Read Time:40 Second

Description

The code contains comments that suggest the presence of bugs, incomplete functionality, or weaknesses.

Many suspicious comments, such as BUG, HACK, FIXME, LATER, LATER2, TODO, in the code indicate missing security functionality and checking. Others indicate code problems that programmers should fix, such as hard-coded variables, error handling, not using stored procedures, and performance issues.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1078

 

Consequences

Other: Quality Degradation

Suspicious comments could be an indication that there are problems in the source code that may need to be fixed and is an indication of poor quality. This could lead to further bugs and the introduction of weaknesses.

 

Potential Mitigations

Phase: Documentation

Description: 

Remove comments that suggest the presence of bugs, incomplete functionality, or weaknesses, before deploying the application.

CVE References

CWE

CWE-547 – Use of Hard-coded, Security-relevant Constants

Read Time:52 Second

Description

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

If the developer does not find all occurrences of the hard-coded constants, an incorrect policy decision may be made if one of the constants is not changed. Making changes to these values will require code changes that may be difficult or impossible once the system is released to the field. In addition, these hard-coded values may become available to attackers if the code is ever disclosed.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1078

 

Consequences

Other: Varies by Context, Quality Degradation

The existence of hardcoded constants could cause unexpected behavior and the introduction of weaknesses during code maintenance or when making changes to the code if all occurrences are not modified. The use of hardcoded constants is an indication of poor quality.

 

Potential Mitigations

Phase: Implementation

Description: 

Avoid using hard-coded constants. Configuration files offer a more flexible solution.

CVE References

CWE

CWE-548 – Exposure of Information Through Directory Listing

Read Time:54 Second

Description

A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers.

A directory listing provides an attacker with the complete index of all the resources located inside of the directory. The specific risks and consequences vary depending on which files are listed and accessible.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-497

 

Consequences

Confidentiality: Read Files or Directories

Exposing the contents of a directory can lead to an attacker gaining access to source code or providing useful information for the attacker to devise exploits, such as creation times of files or any information that may be encoded in file names. The directory listing may also compromise private or confidential data.

 

Potential Mitigations

Phase: Architecture and Design, System Configuration

Description: 

Recommendations include restricting access to important directories or files by adopting a need to know requirement for both the document and server root, and turning off features such as Automatic Directory Listings that could expose private files and provide information that could be utilized by an attacker when formulating or conducting an attack.

CVE References

CWE

CWE-549 – Missing Password Field Masking

Read Time:19 Second

Description

The software does not mask passwords during entry, increasing the potential for attackers to observe and capture passwords.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-522

 

Consequences

Access Control: Bypass Protection Mechanism

 

Potential Mitigations

Phase: Implementation, Requirements

Description: 

Recommendations include requiring all password fields in your web application be masked to prevent other users from seeing this information.

CVE References

CWE

CWE-55 – Path Equivalence: ‘/./’ (Single Dot Directory)

Read Time:1 Minute, 0 Second

Description

A software system that accepts path input in the form of single dot directory exploit (‘/./’) without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-41

 

Consequences

Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories

 

Potential Mitigations

Phase: Implementation

Description: 

Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CVE References

  • CVE-2000-0004
    • Server allows remote attackers to read source code for executable files by inserting a . (dot) into the URL.
  • CVE-2002-0304
    • Server allows remote attackers to read password-protected files via a /./ in the HTTP request.
  • CVE-2004-0815
    • “/./////etc” cleansed to “.///etc” then “/etc”
  • CVE-2002-0112
    • Server allows remote attackers to view password protected files via /./ in the URL.
CWE

CWE-550 – Server-generated Error Message Containing Sensitive Information

Read Time:33 Second

Description

Certain conditions, such as network failure, will cause a server error message to be displayed.

While error messages in and of themselves are not dangerous, per se, it is what an attacker can glean from them that might cause eventual problems.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-209

 

Consequences

Confidentiality: Read Application Data

 

Potential Mitigations

Phase: Architecture and Design, System Configuration

Description: 

Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed.

CVE References