By default, ASP.NET servers store the HttpSessionState object, its attributes and any objects they reference in memory. This model limits active session state to what can be accommodated by the system memory of a single machine. In order to expand capacity beyond these limitations, servers are frequently configured to persistent session state information, which both expands capacity and permits the replication across multiple machines to improve overall performance. In order to persist its session state, the server must serialize the HttpSessionState object, which requires that all objects stored in it be serializable.

In order for the session to be serialized correctly, all objects the application stores as session attributes must declare the [Serializable] attribute. Additionally, if the object requires custom serialization methods, it must also implement the ISerializable interface.

Example 1: The following class adds itself to the session, but since it is not serializable, the session cannot be serialized correctly.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

If multiple threads are trying to obtain a lock on a resource, calling sleep() while holding a lock can cause all of the other threads to wait for the resource to be released, which can result in degraded performance and deadlock.

Example 1: The following code calls sleep() while holding a lock.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

Many talented individuals have spent a great deal of time pondering ways to make double-checked locking work in order to improve performance. None have succeeded.

Example 1: At first blush it may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization.

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

The programmer wants to guarantee that only one Fitzer() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called. This idiom is known as double-checked locking.

Unfortunately, it does not work, and multiple Fitzer() objects can be allocated. See The "Double-Checked Locking is Broken" Declaration for more details [1].

After a thread signals other threads waiting on a mutex, it must unlock the mutex by calling pthread_mutex_unlock() before another thread can begin running. If the signaling thread fails to unlock the mutex, the pthread_cond_wait() call in the second thread will not return and the thread will not execute.

Example 1: The following code signals another thread waiting on a mutex by calling pthread_cond_signal(), but fails to unlock the mutex the other thread is waiting on.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

A typographical error on an operation can lead to unexpected results. For example, if the intention is to add a number to a variable using += but it is written as =+, the operation is still valid. However, instead of carrying out the addition, it re-initializes the variable.

Example 1 The following code is intended to add a number to the variable numberOne. However, using the =+ operator actually re-initializes the variable to 1.

uint numberOne = 1;

function alwaysOne() public {
    numberOne =+ 1;
}

A call made to an external contract can fail, which might cause a Denial of Service inside the calling contract if the failure is not handled correctly. Which can leave the contract unavailable for further use.

This is especially relevant when the external call is executed inside a loop statement and even more when dealing with payments, where it is usually better to let users withdraw funds instead of pushing funds to them.

Example 1: The following code uses a for loop statement to refund all involved addresses by using the send external call.

function refundAll() public {
    for(uint x; x < refundAddresses.length; x++) {
        require(refundAddresses[x].send(refunds[refundAddresses[x]]));
    }
}

Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows(R) API. Most of these functions are vulnerable to various forms of attacks.
Example 1: The following code uses a temporary file for storing intermediate data gathered from the network before it is processed.

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

This otherwise unremarkable code is vulnerable to a number of different attacks because it relies on an insecure method for creating temporary files. The vulnerabilities introduced by this function and others are described in the following sections. The most egregious security problems related to temporary file creation have occurred on Unix-based operating systems, but Windows applications have parallel risks. This section includes a discussion of temporary file creation on both Unix and Windows systems.

Methods and behaviors can vary between systems, but the fundamental risks introduced by each are reasonably constant. See the Recommendations section for information about safe core language functions and advice regarding a secure approach to creating temporary files.

The functions designed to aid in the creation of temporary files can be broken into two groups based on whether they simply provide a filename or actually open a new file.

Group 1 - "Unique" Filenames:

The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess.

If a file with the selected name is created, then depending on how the file is opened the existing contents or access permissions of the file may remain intact. If the existing contents of the file are malicious in nature, an attacker may be able to inject dangerous data into the application when it reads data back from the temporary file. If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions.

Finally, in the best case the file will be opened with a call to open() using the O_CREAT and O_EXCL flags or to CreateFile() using the CREATE_NEW attribute, which will fail if the file already exists and therefore prevent the types of attacks described previously. However, if an attacker is able to accurately predict a sequence of temporary file names, then the application may be prevented from opening necessary temporary storage causing a denial of service (DoS) attack. This type of attack would not be difficult to mount given the small amount of randomness used in the selection of the filenames generated by these functions.

Group 2 - "Unique" Files:

The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp().

The tmpfile() style functions construct a unique filename and open it in the same way that fopen() would if passed the flags "wb+", that is, as a binary file in read/write mode. If the file already exists, tmpfile() will truncate it to size zero, possibly in an attempt to assuage the security concerns mentioned earlier regarding the race condition that exists between the selection of a supposedly unique filename and the subsequent opening of the selected file. However, this behavior clearly does not solve the function's security problems. First, an attacker may pre-create the file with relaxed access-permissions that will likely be retained by the file opened by tmpfile(). Furthermore, on Unix based systems if the attacker pre-creates the file as a link to another important file, the application may use its possibly elevated permissions to truncate that file, thereby doing damage on behalf of the attacker. Finally, if tmpfile() does create a new file, the access permissions applied to that file will vary from one operating system to another, which can leave application data vulnerable even if an attacker is unable to predict the filename to be used in advance.

Finally, mkstemp() is a reasonably safe way to create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used.

The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer session timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: Code in the following example sets a negative value for the maximum inactive interval resulting in a session that remains active indefinitely.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

It is never a good idea for a web application to attempt to shut down the application container. A call to a termination method is probably part of leftover debug code or code imported from a non-J2EE application.

A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application.

In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface.

Example 1: The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

Thread management in a web application is forbidden by the J2EE standard in some circumstances and is always highly error prone. Managing threads is difficult and is likely to interfere in unpredictable ways with the behavior of the application container. Even without interfering with the container, thread management usually leads to bugs that are hard to detect and diagnose like deadlock, race conditions, and other synchronization errors.

JWT is a standard used to create a URL-safe means of transferring data between two parties. JWT provides protection against data tampering because the information it contains is digitally signed with either the HMAC or the RSA algorithm. The server typically generates JWT after successful authentication by the client. This JWT accompanies future client requests to the server for stateless authentication. These tokens are often targeted by malicious users for impersonation attacks. The JWT specification includes various protection mechanisms to prevent the tokens against such attacks. The jti claim provides a unique identifier for the JWT. It can be used to prevent the JWT from being replayed. The application "signs out" the user from all devices by deleting all JWTs in the backend store associated with that user. In addition, the developer should use exp (expiration time) to expire the JWT.

An authorization server generates multiple valid access tokens with the same authorization code is susceptible to impersonation attacks.
The OAuth2 API makes it possible for users to grant access to their accounts with an authorization server. When a user has denied access for an application, all access tokens are revoked and become invalid. However, if the associated authorization token is not revoked, a malicious application can exploit it to restore access to user's account after access revocation.

Authorization servers that do not verify the client_id and client_secret when refreshing the access_token are susceptible to impersonation and unauthorized access attacks. Authorization servers might issue refresh tokens to web application clients and native application clients. The authorization server must verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, the authorization server should deploy other means to detect refresh token abuse such as redirecting the user to repeat the authorization process after an expiration date is reached.

OAuth2 protocol implementations that do not use the state parameter value with sufficient entropy are susceptible to a CSRF vulnerability that might give an attacker the ability to login to the victim's current application account using a third-party account without any restrictions.
In authorization code type and implicit grant type, the OAuth2 protocol is vulnerable to a CSRF attack if the state parameter value is predictable. An attacker can perform a normal OAuth2 process and get the redirection URL that contains the authorization code for the third-party. The attacker can bind their own account to the victim's account for the vulnerable application by enticing a victim to access this URL. If the state parameter is set in the redirection URL but without sufficient entropy, then an attacker can predict the user's state parameter and forge a reliable redirection URL to persuade the victim to access and then implement a CSRF attack.

Values associated with block.timestamp or block.number are often used by developers to trigger time-dependent events, however, these values often give a sense of time that is generally not safe to use.

Due to the decentralized nature of blockchain, nodes can synchronize time only to a certain degree. Using block.timestamp is unreliable at best, and at worst, malicious miners can alter the timestamp of their blocks if they see an advantage to do so.

As for block.number, even though it is possible to predict the time between blocks (approximately 14 seconds), block times are not constant and can vary depending on network activity. This makes block.number unreliable for time-related calculations.

Example 1: The following code uses block.number to unlock funds after a certain period of time.

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores a condition, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores an error condition that might happen during a CICS transaction.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

If a transaction were to ever fail with this error condition, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

A ColdFusion application might inadvertently display detailed error messages to the user. These error messages might contain sensitive information that can enable an attacker to conduct more targeted or damaging attacks.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code excerpt ignores a rarely-thrown exception from doExchange().

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code ignores several exceptions that could be thrown while executing the insert statement.

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

An exception could be thrown because the table does not exist, a required value is not provided, or some other reason. If a failure occurs, there is no way to tell because the procedure will not report the failure or record what type of failure has occurred.