Monthly Archives: May 2022

CWE

CWE-551 – Incorrect Behavior Order: Authorization Before Parsing and Canonicalization

Read Time:45 Second

Description

If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection.

For instance, the character strings /./ and / both mean current directory. If /SomeDirectory is a protected directory and an attacker requests /./SomeDirectory, the attacker may be able to gain access to the resource if /./ is not converted to / before the authorization check is performed.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-863
CWE-696

 

Consequences

Access Control: Bypass Protection Mechanism

 

Potential Mitigations

Phase: Architecture and Design

Description: 

URL Inputs should be decoded and canonicalized to the application’s current internal representation before being validated and processed for authorization. Make sure that your application does not decode the same input twice. Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked.

CVE References

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

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-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-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-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-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-544 – Missing Standardized Error Handling Mechanism

Read Time:44 Second

Description

The software does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.

If the application handles error messages individually, on a one-by-one basis, this is likely to result in inconsistent error handling. The causes of errors may be lost. Also, detailed information about the causes of an error may be unintentionally returned to the user.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-755

 

Consequences

Integrity, Other: Quality Degradation, Unexpected State, Varies by Context

 

Potential Mitigations

Phase: Architecture and Design

Description: 

define a strategy for handling errors of different severities, such as fatal errors versus basic log events. Use or create built-in language features, or an external package, that provides an easy-to-use API and define coding standards for the detection and handling of errors.

CVE References

CWE

CWE-543 – Use of Singleton Pattern Without Synchronization in a Multithreaded Context

Read Time:46 Second

Description

The software uses the singleton pattern when creating a resource within a multithreaded environment.

The use of a singleton pattern may not be thread-safe.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-820
CWE-662
CWE-662

 

Consequences

Other, Integrity: Other, Modify Application Data

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use the Thread-Specific Storage Pattern. See References.

Phase: Implementation

Description: 

Do not use member fields to store information in the Servlet. In multithreading environments, storing user data in Servlet member fields introduces a data access race condition.

Phase: Implementation

Effectiveness: Limited

Description: 

Avoid using the double-checked locking pattern in language versions that cannot guarantee thread safety. This pattern may be used to avoid the overhead of a synchronized call, but in certain versions of Java (for example), this has been shown to be unsafe because it still introduces a race condition (CWE-209).

CVE References