Privacy Violation: Heap Inspection

Storing sensitive data in an insecure manner makes it possible to extract the data via inspecting the heap.

Certain patterns in programming causes sensitive data to be stored in an insecure manner, making it possible to extract the data via inspecting the heap.

Example 1: The following method returns a password from the console and stores it in an insecure String object.

public static String getPassword() {
    String inputPassword = "";
    ConsoleKeyInfo nextKey = Console.ReadKey(true);
    while (nextKey.Key != Console.ReadKey(true)) {
        inputPassword.AppendChar(nextKey.KeyChar);
        Console.Write("*");
        nextKey = Console.ReadKey(true);
    }
    return inputPassword;
}

Because String is an immutable object, the contents cannot be nullified, meaning that the sensitive data is open to anyone able to inspect the heap prior to garbage collection.

Storing sensitive data in a String object makes it impossible to reliably purge the data from memory.

Sensitive data (such as passwords, social security numbers, credit card numbers, etc.) stored in memory can be leaked if memory is not cleared after use. Often, Strings are used to store sensitive data, however, since String objects are immutable, assigning a new value to them will create a new String and assign its reference to the one being assigned. The original value will be kept in memory until ARC (Automatic Reference Counting) deallocates the object and releases its memory. Swift makes no guarantee about the lifetime of an object until the end of the closest surrounding scope. If an attacker dumps the contents of memory before the object is deallocated, the contents can be read.

Example 1: The following code stores a password in memory by using a String.

    let password = passwordTextField.text!
    // use the password