Category Archives: CWE

CWE

CWE-591 – Sensitive Data Storage in Improperly Locked Memory

Read Time:1 Minute, 16 Second

Description

The application stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external actors.

On Windows systems the VirtualLock function can lock a page of memory to ensure that it will remain present in memory and not be swapped to disk. However, on older versions of Windows, such as 95, 98, or Me, the VirtualLock() function is only a stub and provides no protection. On POSIX systems the mlock() call ensures that a page will stay resident in memory but does not guarantee that the page will not appear in the swap. Therefore, it is unsuitable for use as a protection mechanism for sensitive data. Some platforms, in particular Linux, do make the guarantee that the page will not be swapped, but this is non-standard and is not portable. Calls to mlock() also require supervisor privilege. Return values for both of these calls must be checked to ensure that the lock operation was actually successful.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-413

 

Consequences

Confidentiality: Read Application Data, Read Memory

Sensitive data that is written to a swap file may be exposed.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms.

Phase: Implementation

Description: 

Check return values to ensure locking operations are successful.

CVE References

CWE

CWE-593 – Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

Read Time:48 Second

Description

The software modifies the SSL context after connection creation has begun.

If the program modifies the SSL_CTX object after creating SSL objects from it, there is the possibility that older SSL objects created from the original context could all be affected by that change.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-666
CWE-287

 

Consequences

Access Control: Bypass Protection Mechanism

No authentication takes place in this process, bypassing an assumed protection of encryption.

Confidentiality: Read Application Data

The encrypted communication between a user and a trusted host may be subject to a sniffing attack.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Use a language or a library that provides a cryptography framework at a higher level of abstraction.

Phase: Implementation

Description: 

Most SSL_CTX functions have SSL counterparts that act on SSL-type objects.

Phase: Implementation

Description: 

Applications should set up an SSL_CTX completely, before creating SSL objects from it.

CVE References

CWE

CWE-594 – J2EE Framework: Saving Unserializable Objects to Disk

Read Time:58 Second

Description

When the J2EE container attempts to write unserializable objects to disk there is no guarantee that the process will complete successfully.

In heavy load conditions, most J2EE application frameworks flush objects to disk to manage memory requirements of incoming requests. For example, session scoped objects, and even application scoped objects, are written to disk when required. While these application frameworks do the real work of writing objects to disk, they do not enforce that those objects be serializable, thus leaving the web application vulnerable to crashes induced by serialization failure. An attacker may be able to mount a denial of service attack by sending enough requests to the server to force the web application to save objects to disk.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-710

 

Consequences

Integrity: Modify Application Data

Data represented by unserializable objects can be corrupted.

Availability: DoS: Crash, Exit, or Restart

Non-serializability of objects can lead to system crash.

 

Potential Mitigations

Phase: Architecture and Design, Implementation

Description: 

All objects that become part of session and application scope must implement the java.io.Serializable interface to ensure serializability of containing objects.

CVE References

CWE

CWE-595 – Comparison of Object References Instead of Object Contents

Read Time:38 Second

Description

The program compares object references instead of the contents of the objects themselves, preventing it from detecting equivalent objects.

For example, in Java, comparing objects using == usually produces deceptive results, since the == operator compares object references rather than values; often, this means that using == for strings is actually comparing the strings’ references, not their values.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-1025

 

Consequences

Other: Varies by Context

This weakness can lead to erroneous results that can cause unexpected application behaviors.

 

Potential Mitigations

Phase: Implementation

Description: 

In Java, use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor.

CVE References

CWE

CWE-596 – DEPRECATED: Incorrect Semantic Object Comparison

Read Time:15 Second

Description

This weakness has been deprecated. It was poorly described and difficult to distinguish from other entries. It was also inappropriate to assign a separate ID solely because of domain-specific considerations. Its closest equivalent is CWE-1023.

Modes of Introduction:

 

 

Related Weaknesses

 

Consequences

 

Potential Mitigations

CVE References

CWE

CWE-597 – Use of Wrong Operator in String Comparison

Read Time:44 Second

Description

The product uses the wrong operator when comparing a string, such as using “==” when the .equals() method should be used instead.

In Java, using == or != to compare two strings for equality actually compares two objects for equality rather than their string values for equality. Chances are good that the two references will never be equal. While this weakness often only affects program correctness, if the equality is used for a security decision, the unintended comparison result could be leveraged to affect program security.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-595
CWE-595
CWE-480

 

Consequences

Other: Other

 

Potential Mitigations

Phase: Implementation

Effectiveness: High

Description: 

Within Java, use .equals() to compare string values.
Within JavaScript, use == to compare string values.
Within PHP, use == to compare a numeric value to a string value. (PHP converts the string to a number.)

CVE References

CWE

CWE-598 – Use of GET Request Method With Sensitive Query Strings

Read Time:53 Second

Description

The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.

The query string for the URL could be saved in the browser’s history, passed through Referers to other web sites, stored in web logs, or otherwise recorded in other sources. If the query string contains sensitive information such as session identifiers, then attackers can use this information to launch further attacks.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-201

 

Consequences

Confidentiality: Read Application Data

At a minimum, attackers can garner information from query strings that can be utilized in escalating their method of attack, such as information about the internal workings of the application or database column names. Successful exploitation of query string parameter vulnerabilities could lead to an attacker impersonating a legitimate user, obtaining proprietary data, or simply executing actions not intended by the application developers.

 

Potential Mitigations

Phase: Implementation

Description: 

When sensitive information is sent, use the POST method (e.g. registration form).

CVE References

CWE

CWE-599 – Missing Validation of OpenSSL Certificate

Read Time:1 Minute, 14 Second

Description

The software uses OpenSSL and trusts or uses a certificate without using the SSL_get_verify_result() function to ensure that the certificate satisfies all necessary security requirements.

This could allow an attacker to use an invalid certificate to claim to be a trusted host, use expired certificates, or conduct other attacks that could be detected if the certificate is properly validated.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-295

 

Consequences

Confidentiality: Read Application Data

The data read may not be properly secured, it might be viewed by an attacker.

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

Trust afforded to the system in question may allow for spoofing or redirection attacks.

Access Control: Gain Privileges or Assume Identity

If the certificate is not checked, it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data under the guise of a trusted host. While the attacker in question may have a valid certificate, it may simply be a valid certificate for a different site. In order to ensure data integrity, we must check that the certificate is valid, and that it pertains to the site we wish to access.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Ensure that proper authentication is included in the system design.

Phase: Implementation

Description: 

Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications.

CVE References

CWE

CWE-6 – J2EE Misconfiguration: Insufficient Session-ID Length

Read Time:1 Minute, 35 Second

Description

The J2EE application is configured to use an insufficient session ID length.

If an attacker can guess or steal a session ID, then they may be able to take over the user’s session (called session hijacking). The number of possible session IDs increases with increased session ID length, making it more difficult to guess or steal a session ID.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-334

 

Consequences

Access Control: Gain Privileges or Assume Identity

If an attacker can guess an authenticated user’s session identifier, they can take over the user’s session.

 

Potential Mitigations

Phase: Implementation

Description: 

Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks.

Phase: Implementation

Description: 

A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.) With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes. Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

CVE References