352 (Compound Element Variant: Composite)

Session Riding

Cross Site Reference Forgery

XSRF

Could be resultant from XSS, although XSS is not necessarily required.

PLOVER - Cross-Site Request Forgery (CSRF)

All

Architecture and Design

384 (Compound Element Base: Composite)

Invalidate any existing session identifiers prior to authorizing a new user session

For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.

The following example shows a snippet of code from a J2EE web application where the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate().

Java Example:

In order to exploit the code above, an attacker could first create a session (perhaps by logging into the application) from a public terminal, record the session identifier assigned by the application, and reset the browser to the login page. Next, a victim sits down at the same public terminal, notices the browser open to the login page of the site, and enters credentials to authenticate against the application. The code responsible for authenticating the victim continues to use the pre-existing session identifier, now the attacker simply uses the session identifier recorded earlier to access the victim's active session, providing nearly unrestricted access to the victim's account for the lifetime of the session. Even given a vulnerable application, the success of the specific attack described here is dependent on several factors working in the favor of the attacker: access to an unmonitored public terminal, the ability to keep the compromised session active and a victim interested in logging into the vulnerable application on the public terminal. In most circumstances, the first two challenges are surmountable given a sufficient investment of time. Finding a victim who is both using a public terminal and interested in logging into the vulnerable application is possible as well, so long as the site is reasonably popular. The less well known the site is, the lower the odds of an interested victim using the public terminal and the lower the chance of success for the attack vector described above. The biggest challenge an attacker faces in exploiting session fixation vulnerabilities is inducing victims to authenticate against the vulnerable application using a session identifier known to the attacker. In the example above, the attacker did this through a direct method that is not subtle and does not scale suitably for attacks involving less well-known web sites. However, do not be lulled into complacency; attackers have many tools in their belts that help bypass the limitations of this attack vector. The most common technique employed by attackers involves taking advantage of cross-site scripting or HTTP response splitting vulnerabilities in the target site [12]. By tricking the victim into submitting a malicious request to a vulnerable application that reflects JavaScript or other code back to the victim's browser, an attacker can create a cookie that will cause the victim to reuse a session identifier controlled by the attacker. It is worth noting that cookies are often tied to the top level domain associated with a given URL. If multiple applications reside on the same top level domain, such as bank.example.com and recipes.example.com, a vulnerability in one application can allow an attacker to set a cookie with a fixed session identifier that will be used in all interactions with any application on the domain example.com [29].

The following example shows a snippet of code from a J2EE web application where the application authenticates users with a direct post to the <code>j_security_check</code>, which typically does not invalidate the existing session before processing the login request.

Other attack vectors include DNS poisoning and related network based attacks where an attacker causes the user to visit a malicious site by redirecting a request for a valid site. Network based attacks typically involve a physical presence on the victim's network or control of a compromised machine on the network, which makes them harder to exploit remotely, but their significance should not be overlooked. Less secure session management mechanisms, such as the default implementation in Apache Tomcat, allow session identifiers normally expected in a cookie to be specified on the URL as well, which enables an attacker to cause a victim to use a fixed session identifier simply by emailing a malicious URL.

7 Pernicious Kingdoms - Session Fixation

All

291 (Compound Element Variant: Composite)

High

Resultant (Weakness is typically related to the presence of some other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

Authentication: Malicious users can fake authentication information, impersonating any IP address.

Design: Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.

C/C++ Example:

Java Example:

As IP addresses can be easily spoofed, they do not constitute a valid authentication mechanism. Alternate methods should be used if significant authentication is necessary.

CLASP - Trusting self-reported IP address

All

Architecture and Design

120 (Compound Element Base: Composite)

Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow."

Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.

Memory Management

High to Very High

Resultant (Weakness is typically related to the presence of some other weaknesses)

Primary (Weakness exists independent of other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

Memory

Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Access control (instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.

Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

Pre-design: Use a language or compiler that performs automatic bounds checking.

Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.

Design: Use the <strsafe.h> library. This library has buffer overflow safe functions that will help with the detection of buffer overflows.

Pre-design through Build: Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.

Implementation: Programmers should adhere to the following rules when allocating and managing their applications memory: Double check that your buffer is as large as you specify. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if calling this function in a loop and make sure you are not in danger of writing past the allocated space. Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions

Operational: Use OS-level preventative functionality. Not a complete solution.

At the programmer level, stack-based and heap-based overflows do not differ significantly, so they are not distinguished here. Obviously, from the exploit perspective using shellcode, they can be quite different.

Buffer overflows are one of the best known types of security problem. The best solution is enforced run-time bounds checking of array access, but many C/C++ programmers assume this is too costly or do not have the technology available to them. Even this problem only addresses failures in access control -- as an out-of-bounds access is still an exception condition and can lead to an availability problem if not addressed. Some platforms are introducing mitigating technologies at the compiler or OS level. All such technologies to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is more common to make the workload of an attacker much higher -- for example, by leaving the attacker to guess an unknown value that changes every program execution.

PLOVER - Unbounded Transfer ('classic overflow')

7 Pernicious Kingdoms - Buffer Overflow

CLASP - Buffer overflow

C

C++

Implementation

A weakness where the code path includes a Buffer Write Operation such that:
1.        the expected size of the buffer is greater than the actual size of the buffer where expected size is equal to the sum of the size of the data item and the position in the buffer

Where Buffer Write Operation is a statement that writes a data item of a certain size into a buffer at a certain position and at a certain index

61 (Compound Element Variant: Composite)

Symlink following, symlink vulnerability.

High to Very High

Resultant (Weakness is typically related to the presence of some other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.

Follow the principle of least privilege when assigning access rights to files. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

Fault: filename predictability, insecure directory permissions, non-atomic operations, race condition.

These are typically reported for temporary files or privileged programs.

Symlink vulnerabilities are regularly found in C and shell programs, but all programming languages can have this problem.

"Second-order symlink vulnerabilities" may exist in programs that invoke other programs that follow symlinks. They are rarely reported but are likely to be fairly common when process invocation is used. Reference: [Christey2005]

PLOVER - UNIX symbolic link following

All