Node.js allows developers to assign callbacks to IO-blocked events. This allows better performance as the callbacks run asynchronously such that the main application isn't blocked by IO. However, this in turn may lead to race conditions when something outside the callback relies upon code within the callback to be run first.

Example 1: The following code checks a user against a database for authentication.

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

In this example we're supposed to be calling to a backend database to confirm a user's credentials for login, and if confirmed we set a variable to true, otherwise false. Unfortunately, since the callback is blocked by IO, it will run asynchronously and may be run after the check to if (authenticated), and since the default was true, it will go into the if-statement whether the user is actually authenticated or not.

When a Java class is initialized, it calls the initializers for static fields declared in the class prior to the class constructor. This means that a constructor assigned to this will be called prior to other code, and if this constructor is then dependent on other fields or variables being initialized, it may lead to partially initialized objects, or objects initialized with incorrect values.

Example 1: The following class declares a static field and assigns it to a new object.

  ...
  public class Box{
    public int area;
    public static final int width = 10;
    public static final Box box = new Box();
    public static final int height = (int) (Math.random() * 100);

    public Box(){
        area = width * height;
    }
    ...
  }
  ...

In Example 1, the developer would expect that box.area would be a random integer that happens to be a multiple of 10, due to width being equal to 10. In reality however, this will always have a hardcoded value of 0. Static final fields declared with a compile-time constant are initialized first, and then each one is executed in order. This means that since height is not a compile-time constant, it is declared after the declaration of box, and therefore the constructor is called prior to the field height being initialized.

Example 2: The following classes declare static fields that rely on each other.

  ...
  class Foo{
    public static final int f = Bar.b - 1;
    ...
  }
  ...
  class Bar{
    public static final int b = Foo.f + 1;
    ...
  }

This example is perhaps easier to identify, but would be dependent on which class is loaded first by the JVM. In this example Foo.f could be either -1 or 0, and Bar.b could be either 0 or 1.

The RoamingFolder and RoamingSettings properties get a container in the roaming app data store, which can then be used to share data between two more devices. By writing and reading objects stored in the roaming app data store, the developer increases the risk of compromise. This includes the confidentiality, integrity, and availability of the data, applications, and systems which share those objects through the roaming app data store.

Developers should refrain from using this functionality without first implementing the necessary technical controls.

The Android activity allocates a Camera instance that is not released in onPause(), onStop(), or onDestroy() callback. The Android OS invokes these callbacks whenever it needs to send the current activity to the background, or when it needs to temporarily destroy the activity when system resources are low. By failing to release the Camera object properly, the activity prevents other applications (or even future instances of the same application) from accessing the camera. Furthermore, maintaining possession of the Camera instance while the activity is paused can negatively impact the user's experience by unnecessarily draining the battery.

Example 1: The following code describes an Android activity that does not override the base onPause() method, which should be used to release the Camera object, nor does it properly release it during its shutdown sequence.

public class UnreleasedCameraActivity extends Activity {
  private Camera cam;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      cam.stopPreview();
  }
}

The Android activity allocates a media object that is not released in onPause(), onStop(), or onDestroy() callback. The Android OS invokes these callbacks whenever it needs to send the current activity to the background, or when it needs to temporarily destroy the activity when system resources are low. By failing to release the media object properly, the activity causes subsequent accesses to Android's media hardware (by other applications or even the same application) to fall back to the software implementations, or even fail altogether. Leaving too many unreleased media instances open can lead Android to throw exceptions, effectively causing a denial of service. Furthermore, maintaining possession of the media instance while the activity is paused can negatively impact the user's experience by unnecessarily draining the battery.

Example 1: The following code describes an Android activity that does not override the base onPause() method, which should be used to release the media object, nor does it properly release it during its shutdown sequence.

public class UnreleasedMediaActivity extends Activity {
  private MediaPlayer mp;

  @Override
  public void onCreate(Bundle state) {
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      mp.stop();
  }
}

The Android activity maintains an Android SQLite database handler that is not closed in onPause(), onStop(), or onDestroy() callback. The Android OS invokes these callbacks whenever it needs to send the current activity to the background, or when it needs to temporarily destroy the activity when system resources are low. By failing to close the database properly, the activity can potentially exhaust the device of available cursors if the activity is constantly restarted. In addition, depending on the implementation, the Android operating system can also throws DatabaseObjectNotClosedException, which crashes the application if the exception is not caught.

Example 1: The following code describes an Android activity that caches user data and writes the data to disk when the activity is stopped. Note that does not override the base onPause(), which should be used to release the database object, nor does it properly release it during its shutdown sequence.

public class MyDBHelper extends SQLiteOpenHelper {
  ...
}

public class UnreleasedDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }

  @Override
  public void onRestart() {
      ...
  }

  @Override
  public void onStop() {
      db.insert(cached_data);     // flush cached data
  }
}

The cursor can potentially be used to access unauthorized information.
Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

In SQL, cursors have the privileges associated with the code that created them. If a less privileged user can capture the leaked cursor, it can be used to view unauthorized records.

In addition, most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service by depleting the resource pool.

Example 1: The PWD_COMPARE procedure can be used by code that does not have access to sys.dba_users to check a user's password.

CREATE or REPLACE procedure PWD_COMPARE(p_user VARCHAR, p_pwd VARCHAR)
  AUTHID DEFINED
IS
  cursor INTEGER;
  ...
BEGIN
  IF p_user != 'SYS' THEN
    cursor := DBMS_SQL.OPEN_CURSOR;
    DBMS_SQL.PARSE(cursor, 'SELECT password FROM SYS.DBA_USERS WHERE username = :u', DBMS_SQL.NATIVE);
    DBMS_SQL.BIND_VARIABLE(cursor, ':u', p_user);
    ...
  END IF;
END PWD_COMPARE;

If the attacker may cause an exception, they can capture the cursor and gain access to unauthorized information, such as the sys password. One way to cause an exception is to pass an overly long argument to p_user. After the attacker knows that the cursor has leaked, they just have to guess the cursor and assign new bind variables.

DECLARE
  x VARCHAR(32000);
  i INTEGER;
  j INTEGER;
  r INTEGER;
  password VARCHAR2(30);
BEGIN
  FOR i IN 1..10000 LOOP
    x:='b' || x;
  END LOOP;
  SYS.PWD_COMPARE(x,'password');
EXCEPTION WHEN OTHERs THEN
  FOR j IN 1..10000
    DBMS_SQL.BIND_VARIABLE(j, ':u', 'SYS');
    DBMS_SQL.DEFINE_COLUMN(j, 1, password, 30);
    r := DBMS_SQL.EXECUTE(j);
    IF DBMS_SQL.FETCH_ROWS(j) > 0 THEN
      DBMS_SQL.COLUMN_VALUE(j, 1, password);
      EXIT;
    END IF;
  END LOOP;
  ...
END;

The program can potentially fail to release a file handle.

Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example 1: The following method never closes the file handle it opens. The finalize() method for ZipFile eventually calls close(), but there is no guarantee as to how long it will take before the finalize() method will be invoked. In a busy environment, this can result in the JVM using up all of its file handles.

public void printZipContents(String fName) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException {
  ZipFile zf = new ZipFile(fName);
  Enumeration<ZipEntry> e = zf.entries();

  while (e.hasMoreElements()) {
    printFileInfo(e.nextElement());
  }
}

Example 2: Under normal conditions, the following fix properly closes the file handle after printing out all the zip file entries. But if an exception occurs while iterating through the entries, the zip file handle will not be closed. If this happens often enough, the JVM can still run out of available file handles.

public void printZipContents(String fName) throws ZipException, IOException, SecurityException, IllegalStateException, NoSuchElementException {
  ZipFile zf = new ZipFile(fName);
  Enumeration<ZipEntry> e = zf.entries();

  while (e.hasMoreElements()) {
    printFileInfo(e.nextElement());
  }
  zf.close();
}

A handle is a reference that represents a system resource such as a portion of memory or a file. In this case, the code fails to reliably release a handle by insecurely invoking a dangerous method without its corresponding counterpart.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, they can try to launch a denial of service by depleting the resource pool.

Example 1: The following code creates a new instance of SafeEvpPKeyHandle, but calls the DangerousAddRef method without a corresponding call to DangerousRelease.

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
bool success = false;

try {
    safeEvpHandle.DangerousAddRef(ref success);
    var handle = safeEvpHandle.DangerousGetHandle();
} catch (ObjectDisposedException ex) { 
    //...
} finally {
    safeEvpHandle.close();
}

Example 2: The following code creates a new instance of SafeEvpPKeyHandle, but calls the DangerousRelease method without a corresponding call to DangerousAddRef.

var pkey = NativeMethods.ENGINE_LOAD_SSL_PRIVATE_KEY(...);
var safeEvpHandle = new SafeEvpPKeyHandle(handle: handle, ownsHandle: true);
bool success = false;

try {
    var handle = safeEvpHandle.DangerousGetHandle();
} catch (ObjectDisposedException ex) { 
    //...
} finally {
    safeEvpHandle.DangerousRelease();
    safeEvpHandle.close();
}

The program can potentially fail to release an LDAP resource.

Resource leaks have at least two common causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for releasing the resource.

Most unreleased resource issues result in general software reliability problems. However, if an attacker can intentionally trigger a resource leak, the attacker may be able to launch a denial of service attack by depleting the resource pool.

Example 1: Under normal conditions the following code executes an LDAP query, processes the results returned by the Active Directory, and closes the allocated DirectoryEntry object. But if an exception occurs while executing the LDAP query or processing the results, the DirectoryEntry object will not be closed. This will introduce a memory leak in the application, since DirectoryEntry internally uses COM APIs to query the Active Directory server.

  ...
  DirectoryEntry entry = new DirectoryEntry("LDAP://CN=users,DC=fabrikam,DC=com");
  DirectorySearcher mySearcher = new DirectorySearcher(entry);
  SearchResultCollection result = mySearcher.FindAll();
  CheckUsers(result);
  mySearcher.Dispose();
  entry.Close();
  ...

The program fails to properly dispose of a managed object that uses unmanaged system resources.
Failure to properly dispose of a managed object that uses unmanaged system resources has at least two common causes:

- Error conditions and other exceptional circumstances.
- Confusion over which part of the program is responsible for releasing the resource.

A small subset of managed .NET objects use unmanaged system resources. .NET's Garbage Collector may not free the original managed objects in a predictable way. As such, the application may run out of available memory as the Garbage Collector is unaware of the memory consumed by the unmanaged resources. Most unmanaged resource leak issues result in general software reliability problems, but if an attacker can intentionally trigger an unmanaged resource leak, the attacker may be able to launch a denial of service attack by depleting the unmanaged resource pool.

Example 1: The following method creates a managed Bitmap Object from an incoming stream incomingStream. The Bitmap is manipulated and persisted to the outgoing stream outgoingStream. The Dispose() method of incomingBitmap and outgoingBitmap is never explicitly called.

Normally, one can safely rely upon the Garbage Collector to do this at a safe time for managed objects that do not use unmanaged system resources. The Garbage Collector calls Bitmap.Dispose() when it sees fit. However, the Bitmap object utilizes scarce, unmanaged system resources. The Garbage Collector may fail to call Dispose() before the unmanaged resource pool is depleted.

private void processBitmap(Stream incomingStream, Stream outgoingStream, int thumbnailSize)
{
	Bitmap incomingBitmap = (Bitmap)System.Drawing.Image.FromStream(incomingStream);

	bool validBitmap = validateBitmap(incomingBitmap);
	if (!validBitmap)
		throw new ValidationException(incomingBitmap);

	Bitmap outgoingBitmap = new Bitmap(incomingBitmap, new Size(thumbnailSize, thumbnailSize));
	outgoingBitmap.Save(outgoingStream, ImageFormat.Bmp);
}

Use after free errors occur when a program continues to use a pointer after it has been freed. Like double free errors and memory leaks, use after free errors have two common and sometimes overlapping causes:

- Error conditions and other exceptional circumstances.

- Confusion over which part of the program is responsible for freeing the memory

Use after free errors sometimes have no effect and other times cause a program to crash. While it is technically feasible for the freed memory to be re-allocated and for an attacker to use this reallocation to launch a buffer overflow attack, we are unaware of any exploits based on this type of attack.

Example 1: The following code illustrates a use after free error:

char* ptr = (char*)malloc (SIZE);
...
if (err) {
    abrt = 1;
    free(ptr);
}
...
if (abrt) {
    logError("operation aborted before commit", ptr);
}

To protect access to various resources, web servers might be configured to prevent the usage of specific HTTP verbs. However, some web frameworks provide a way to override the HTTP verb by using HTTP request headers. This feature is typically used when a web or proxy server restricts certain verbs, but the application needs to use them, especially in RESTful services. However, it is possible for a malicious user to take advantage of this feature. Doing so can enable the attacker to perform unintended actions on protected resources in the web application.

The attack works by using a trusted HTTP verb such as GET or POST, but adds request headers such as X-HTTP-Method, X-HTTP-Method-Override, or X-Method-Override to provide a restricted verb such as PUT or DELETE. Doing so forces the request to be interpreted by the target application using the verb in the request header instead of the actual HTTP verb. In certain cases, the restricted verb might also be used in query or post parameters instead of a request header.

Attackers may be able to deny service to legitimate users by flooding the application with requests, but flooding attacks can often be defused at the network layer. More problematic are bugs that allow an attacker to overload the application using a small number of requests. Such bugs allow the attacker to specify the quantity of system resources their requests will consume or the duration for which they will use them.

Example 1: The following code allows a user to specify the amount of time for which a thread will sleep. By specifying a large number, an attacker may tie up the thread indefinitely. With a small number of requests, the attacker may deplete the application's thread pool.

  int usrSleepTime = Integer.parseInt(usrInput);
  Thread.sleep(usrSleepTime);

Example 2: The following code reads a String from a zip file. Because it uses the readLine() method, it will read an unbounded amount of input. An attacker may take advantage of this code to cause an OutOfMemoryException or to consume a large amount of memory so that the program spends more time performing garbage collection or runs out of memory during some subsequent operation.

  InputStream zipInput = zipFile.getInputStream(zipEntry);
  Reader zipReader = new InputStreamReader(zipInput);
  BufferedReader br = new BufferedReader(zipReader);
  String line = br.readLine();

It is never appropriate to use an empty string as a password. It is too easy to guess.

It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:

...
private static String encryptionKey = "";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.

There are a number of technologies that provide the capacity to maneuver through JSON documents using a tree-like access syntax. Using this type of document traversal, an adversary can query parts of a JSON document to which they should not have access.

Example 1: The following code uses a user-defined keyword to access a JSON document that contains public user details, such as name and address, but the JSON document also contains private details such as their password.

    $userInput = getUserIn();
    $document = getJSONDoc();
    $part = simdjson_key_value($document, $userInput);
    echo json_decode($part);

Because userInput is user-controllable, a malicious user can leverage this to access any sensitive data in the JSON document.

Multiple catch blocks can get repetitive, but "condensing" catch blocks by catching a high-level class such as Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

Example 1: The following code excerpt handles three types of exceptions in an identical fashion.

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows:

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

A return statement inside a finally block will cause any exception that might be thrown in the try block to be discarded.

Example 1: In the following code excerpt, the MagicException thrown by the second call to doMagic with true passed to it will never be delivered to the caller. The return statement inside the finally block will cause the exception to be discarded.

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

A trust boundary can be thought of as line drawn through a program. On one side of the line, data is untrusted. On the other side of the line, data is assumed to be trustworthy. The purpose of validation logic is to allow data to safely cross the trust boundary--to move from untrusted to trusted.

A trust boundary violation occurs when a program blurs the line between what is trusted and what is untrusted. The most common way to make this mistake is to allow trusted and untrusted data to commingle in the same data structure.

Example 1: The following Java code accepts an HTTP request and stores the usrname parameter in the HTTP session object before checking to ensure that the user has been authenticated.

usrname = request.getParameter("usrname");
if (session.getAttribute(ATTR_USR) != null) {
    session.setAttribute(ATTR_USR, usrname);
}

Without well-established and maintained trust boundaries, programmers will inevitably lose track of which pieces of data have been validated and which have not. This confusion eventually allows some data to be used without first being validated.