All posts by rocco

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

CWE-600 – Uncaught Exception in Servlet

Read Time:38 Second

Description

The Servlet does not catch all exceptions, which may reveal sensitive debugging information.

When a Servlet throws an exception, the default error response the Servlet container sends back to the user typically includes debugging information. This information is of great value to an attacker. For example, a stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-248
CWE-209
CWE-390

 

Consequences

Confidentiality, Availability: Read Application Data, DoS: Crash, Exit, or Restart

 

Potential Mitigations

Phase: Implementation

Description: 

Implement Exception blocks to handle all types of Exceptions.

CVE References

CWE-601 – URL Redirection to Untrusted Site (‘Open Redirect’)

Read Time:2 Minute, 59 Second

Description

A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.

An http parameter may contain a URL value and could cause the web application to redirect the request to the specified URL. By modifying the URL value to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts have a more trustworthy appearance.

Phishing is a general term for deceptive attempts to coerce private information from users that will be used for identity theft.

Modes of Introduction:

– Architecture and Design

 

Likelihood of Exploit: Low

 

Related Weaknesses

CWE-610
CWE-610

 

Consequences

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

The user may be redirected to an untrusted page that contains malware which may then compromise the user’s machine. This will expose the user to extensive risk and the user’s interaction with the web server may also be compromised if the malware conducts keylogging or other attacks that steal credentials, personally identifiable information (PII), or other important data.

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

The user may be subjected to phishing attacks by being redirected to an untrusted page. The phishing attack may point to an attacker controlled web page that appears to be a trusted web site. The phishers may then steal the user’s credentials and then use these credentials to access the legitimate web site.

 

Potential Mitigations

Phase: Implementation

Description: 

Phase: Architecture and Design

Description: 

Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Phase: Architecture and Design

Description: 

Phase: Architecture and Design

Description: 

Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330).

Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design, Implementation

Description: 

Phase: Operation

Effectiveness: Moderate

Description: 

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

CVE References

  • CVE-2005-4206
    • URL parameter loads the URL into a frame and causes it to appear to be part of a valid page.
  • CVE-2008-2951
    • An open redirect vulnerability in the search script in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL as a parameter to the proper function.
  • CVE-2008-2052
    • Open redirect vulnerability in the software allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the proper parameter.

CWE-565 – Reliance on Cookies without Validation and Integrity Checking

Read Time:1 Minute, 20 Second

Description

The application relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.

Attackers can easily modify cookies, within the browser or by implementing the client-side code outside of the browser. Reliance on cookies without detailed validation and integrity checking can allow attackers to bypass authentication, conduct injection attacks such as SQL injection and cross-site scripting, or otherwise modify inputs in unexpected ways.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-642
CWE-669
CWE-602

 

Consequences

Access Control: Gain Privileges or Assume Identity

It is dangerous to use cookies to set a user’s privileges. The cookie can be manipulated to escalate an attacker’s privileges to an administrative level.

 

Potential Mitigations

Phase: Architecture and Design

Description: 

Avoid using cookie data for a security-related decision.

Phase: Implementation

Description: 

Perform thorough input validation (i.e.: server side validation) on the cookie data if you’re going to use it for a security related decision.

Phase: Architecture and Design

Description: 

Add integrity checks to detect tampering.

Phase: Architecture and Design

Description: 

Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client.

CVE References

CWE-566 – Authorization Bypass Through User-Controlled SQL Primary Key

Read Time:38 Second

Description

The software uses a database table that includes records that should not be accessible to an actor, but it executes a SQL statement with a primary key that can be controlled by that actor.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-639

 

Consequences

Confidentiality, Integrity, Access Control: Read Application Data, Modify Application Data, Bypass Protection Mechanism

 

Potential Mitigations

Phase: Implementation

Description: 

Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an “accept known good” validation strategy.

Phase: Implementation

Description: 

Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly.

CVE References

CWE-567 – Unsynchronized Access to Shared Data in a Multithreaded Context

Read Time:39 Second

Description

The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.

Modes of Introduction:

– Architecture and Design

 

 

Related Weaknesses

CWE-820
CWE-662
CWE-662
CWE-488

 

Consequences

Confidentiality, Integrity, Availability: Read Application Data, Modify Application Data, DoS: Instability, DoS: Crash, Exit, or Restart

If the shared variable contains sensitive data, it may be manipulated or displayed in another user session. If this data is used to control the application, its value can be manipulated to cause the application to crash or perform poorly.

 

Potential Mitigations

Phase: Implementation

Description: 

Remove the use of static variables used between servlets. If this cannot be avoided, use synchronized access for these variables.

CVE References

CWE-568 – finalize() Method Without super.finalize()

Read Time:23 Second

Description

The software contains a finalize() method that does not call super.finalize().

The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize().

Modes of Introduction:

– Implementation

 

 

Related Weaknesses

CWE-573
CWE-459

 

Consequences

Other: Quality Degradation

 

Potential Mitigations

Phase: Implementation

Description: 

Call the super.finalize() method.

Phase: Testing

Description: 

Use static analysis tools to spot such issues in your code.

CVE References

CWE-57 – Path Equivalence: ‘fakedir/../realdir/filename’

Read Time:57 Second

Description

The software contains protection mechanisms to restrict access to ‘realdir/filename’, but it constructs pathnames using external input in the form of ‘fakedir/../realdir/filename’ that are not handled by those mechanisms. This allows attackers to perform unauthorized actions against the targeted file.

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-2001-1152
    • Proxy allows remote attackers to bypass denylist restrictions and connect to unauthorized web servers by modifying the requested URL, including (1) a // (double slash), (2) a /SUBDIR/.. where the desired file is in the parentdir, (3) a /./, or (4) URL-encoded characters.
  • CVE-2000-0191
    • application check access for restricted URL before canonicalization
  • CVE-2005-1366
    • CGI source disclosure using “dirname/../cgi-bin”