The identified function writes data to the general pasteboard without excluding it from Universal Clipboard synchronization across devices via Handoff.

Content written to the general pasteboard is persistently stored across device restarts, app uninstalls, and app restores. Using the general pasteboard with the Universal Clipboard feature enabled increases the risk of stolen or modified pasteboard data as part of a Clipboard Hijacking attack by a malicious application running on another device.

Furthermore, because Universal Clipboard is compatible with devices running either iOS 10 and later or macOS Sierra and later, an increased threat is introduced by compatible devices running an older operating system that does not contain more recent privacy and security updates aimed to protect unauthorized clipboard access.

Example 1: In the following code, data is written to the general pasteboard setting the items property that shares pasteboard content between the user's devices by default via Universal Clipboard.

...
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
NSDictionary *items = @{
    UTTypePlainText : sensitiveDataString,
    UTTypePNG : [UIImage imageWithData:medicalImageData]
};
[pasteboard setItems: @[items]];
...

Example 2: In the following code, data is written to the general pasteboard by calling the setObjects:localOnly:expirationDate: method with Universal Clipboard behavior explicitly enabled by setting the localOnly parameter to NO.

...
UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
[pasteboard setObjects:@[sensitiveDataString, [UIImage imageWithData:medicalImageData]] 
            localOnly:NO 
            expirationDate:[NSDate distantFuture]];
...

When storing data into the Keychain, an accessibility level needs to be set up which defines when it will be possible to access the item. The possible accessibility levels include:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAlways:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device.
This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute never migrate to a new device. After a backup is restored to a new device, these items are missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode causes all items in this class to be deleted.
Available in iOS 8.0 and later.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlocked:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
This is the default value for Keychain items added without explicitly setting an accessibility constant.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

When Keychain protections were first introduced, the default value was kSecAttrAccessibleAlways, which created a security problem since someone that can get access or steal your device will be able to read the contents of the Keychain. Currently, the default attribute is kSecAttrAccessibleWhenUnlocked, which is a reasonably restrictive default. However, Apple's public documentation disagrees about what the default attribute is supposed to be, so just in case, you should set this attribute explicitly on all Keychain items.

Example 1: In the following example the Keychain item is stored without clearly specifying an accessibility level which may behave differently on different iOS versions:

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure Keychain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

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.

All communication over HTTP, FTP, or gopher is unauthenticated and unencrypted. It is therefore subject to compromise, especially in the mobile environment where devices frequently connect to unsecured, public, wireless networks using WiFi connections.

Example 1: The following example reads data using the HTTP protocol (instead of using HTTPS).

   URL url = new URL("http://www.android.com/");
   HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
   try {
     InputStream in = new BufferedInputStream(urlConnection.getInputStream());
     readStream(in);
     ...
   }

The incoming stream,instream, may have been compromised as it is delivered over an unencrypted and unauthenticated channel.

Transport layer protections are essential in addition to secure coding and program configuration to fully secure the application against compromises. Enforcing SSL/TLS access to sensitive application resources and functionality is a crucial transport security control that protects applications against unauthorized access. In addition to configuring secure access, it is equally important to disallow connections to these resources that are established over non secure channels.

Allowing both HTTP and HTTPS connections to the server leaves the application susceptible to the same degree of compromise as when secure access is disabled. An attacker can use this weakness to potentially intercept sensitive data including usernames and passwords, customer account information, or similar information.

Cipher suites are a set of algorithms used to establish secure communications. While establishing a connection between a server and a client, the server determines which of the mutually supported cipher suites to use. The server and clients can have different sets of supported cipher suites. Older cipher suites are generally not recommended and might introduce security vulnerabilities in the application. Strong cipher suites, with no known security vulnerabilities, are generally recommended for use.

The Config.PreferServerCipherSuites field controls whether the server follows the client or server's cipher suite preference. Using the client's preferred cipher suite might introduce security vulnerabilities if the chosen cipher suite has known weaknesses.

Example 1: The following code sets the PreferServerCipherSuites field to false.

conf := &tls.Config{
    PreferServerCipherSuites: false,
}

The application communicates with its database server over unencrypted channels and may pose a significant security risk to the company and users of that application. In this case, an attacker can modify the user entered data or even execute arbitrary SQL commands against the database server.

Example 1: The following code causes the application to communicate with its database server over unencrypted channels:

  ...
  Using(SqlConnection DBconn = new SqlConnection("Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;"))
  {
    ...
  }
  ...

App Transport Security (ATS) enforces best practices for secure network connections such as TLS 1.2 and forward secrecy and will be updated in the future to reflect Apple's network best practices.

App Transport Security (ATS) is enabled by default when using NSURLSession, NSURLConnection, or CFURL in iOS 9 or OS X El Capitan which enforces the application to use HTTPS with TLS 1.2 for all the network communications with the back end server.

The application is configured to partially or entirely opt-out of App Transport Security (ATS) which leaves the application at risk of suffering man-in-the-middle attacks and other network-based attacks.

Example 1: The following entries in the application Info.plist will entirely disable App Transport Security:

<key>NSAppTransportSecurity</key>
<dict>
  <!--Include to allow all connections (DANGER)-->
  <key>NSAllowsArbitraryLoads</key>
  <true/>
</dict>

Example 2: The following entries in the application Info.plist will disable App Transport Security for yourserver.com:

<key>NSAppTransportSecurity</key>
<dict>
  <key>NSExceptionDomains</key>
  <dict>
    <key>yourserver.com</key>
    <dict>
      <!--Include to allow subdomains-->
      <key>NSIncludesSubdomains</key>
      <true/>
      <!--Allow plain HTTP requests-->
      <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
      <true/>
      <!--Downgrades TLS version-->
      <key>NSTemporaryExceptionMinimumTLSVersion</key>
      <string>TLSv1.1</string>
    </dict>
  </dict>
</dict>

Ensure that hyperlinks on your web pages only link to secure locations to prevent any user-compromise when navigating around your website. Even if the link redirects from an insecure protocol (such as HTTP) to a secure protocol (such as HTTPS), the initial connection over an unencrypted channel enables an attacker to perform a man-in-the-middle (MiTM) attack. This enables the attacker to control the page the resulting landing page.

Example 1: Consider the following hyperlink:

<a href="http://www.example.com/index.html"/>

If an attacker is listening to the network traffic between the user and the server, the attacker can imitate or manipulate www.example.com to load their own web page.

Links to third-party websites might not initially be considered important to secure, but any compromise can appear to a user as coming from a link on your web page and can therefore lower user trust in using your platform.

Using Google Remote Procedure Call (gRPC) channel security settings that are specified as to not be encrypted, do not support authentication, or lack the capacity of connection identity leaves the channel open to many forms of attack. Data sent with this insecure channel cannot be trusted.

Example 1: The following code shows a gRPC channel setup with insecure channel credentials

...
ManagedChannel channel = Grpc.newChannelBuilder("hostname", InsecureChannelCredentials.create()).build();
...

Using Google Remote Procedure Call (gRPC) server security settings that are specified as not be encrypted, or do not have the capacity of connection identity leaves the server open to many forms of attack. Data sent to and from this insecure server cannot be trusted.

Example 1: The following code shows a gRPC server setup with insecure server credentials

...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links that reference HTTPS and replaces them with HTTP ones. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.

HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site that returning the HSTS headers over SSL/TLS during a period specified within the header. Any connection to the server over HTTP is automatically replaced with an HTTPS connection, even if the user types a URL with http:// in the browser's URL bar.

Example 1: The following code configures a Spring Security protected application to disable HSTS for subdomains:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts include-sub-domains="false" />
        </headers>
	</http>

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links that reference HTTPS and replaces them with HTTP versions. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.


HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site that returning the HSTS headers over SSL/TLS during a period specified within the header. Any connection to the server over HTTP is automatically replaced with an HTTPS connection, even if the user types a URL with http:// in the browser's URL bar.

Example 1: The following code configures a Spring Security protected application to disable HSTS headers:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts disabled="true" />
        </headers>
	</http>

Diffie-Hellman key exchange algorithm uses fixed primes as a base for computing the secret key to secure the communication channel. The size of the prime number deployed dictates the security level of the generated key, which defines the effective security the Diffie-Hellman key exchange algorithm provides.

Example 1:The following Node.js application uses the predefined modp2 group to initialize a Diffie-Hellman key exchange protocol, which uses a 1024-bit prime:

const dh = getDiffieHellman('modp2');
dh.generateKeys();
...

Communication channels secured with this key exchange implementation are vulnerable to man-in-the-middle attacks. This vulnerability affects all anonymous, ephemeral and fixed Diffie-Hellman key exchange algorithms, except for Elliptical-Curve Diffie-Hellman (ECDHE) key exchange.

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links that reference HTTPS and replaces them with HTTP versions. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.

HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site that returning the HSTS headers over SSL/TLS during a period specified within the header. Any connection to the server over HTTP is automatically replaced with an HTTPS connection, even if the user types a URL with http:// in the browser's URL bar.

Example 1: The following code configures a Spring Security protected application to use a short expiration time:

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        ...
        http.headers(headers ->
                headers.httpStrictTransportSecurity(hstsConfig ->
                    hstsConfig.maxAgeInSeconds(300)
                )
            );
        ...
    }

Sensitive data sent over the wire unencrypted is subject to be read/modified by any attacker that can intercept the network traffic.

Example 1: The following Spring Mailer is configured incorrectly, not using SSL/TLS to communicate with an SMTP server:

<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
    <property name="host" value="smtp.acme.com" />
    <property name="port" value="25" />
    <property name="javaMailProperties">
        <props>
            <prop key="mail.smtp.auth">true</prop>
        </props>
    </property>
</bean>

Syntactical or typographical mistakes such as missing double quotes around pins and missing proper delimiters between attributes might result in either browsers ignoring the header or behaving unexpectedly. Other misconfigurations, such as insufficient max-age value, selection of cryptographically weak hash algorithm for pins and report URI that points to an external domain, can lead to security compromises as detailed in RFC7469 about the header.

Perfect Forward Secrecy (PFS) preserves the secrecy of previous encrypted communications between two parties over a secure communication channel, even if the private key necessary to decrypt communications for a given session is compromised. It is implemented via a function of key exchange protocols used to establish a shared secret between the client and server. [1] In public key encryption schemes without PFS, as message decryption operations are performed using a static long-term private key, if that private key is compromised at a given point in time, all previous communications can be decrypted. Vulnerabilities such as "Heartbleed" (CVE-2014-0160) [5] in the OpenSSL library [6] that can allow an attacker to steal a server's static long-term private key demonstrate the danger in using cipher suites that do not implement PFS.

PFS mitigates this issue by only using a static long-term private key for authentication, while random short-term private keys are used for session data encryption. PFS is commonly implemented using a Diffie-Hellman key exchange in ephemeral-static mode (DHE) or an Elliptic Curve Diffie-Hellman key exchange scheme with ephemeral keys (ECDHE). [2, 3, 4] For every TLS session established with DHE or ECDHE as the key exchange algorithm for a given cipher suite, the server is required to use a new Diffie-Hellman public/private key for the generation of the TLS master secret. [7] The server then signs this Diffie-Hellman public key using its static long-term private key to guarantee its authenticity. The server's static long-term private key is not used for the encryption of session data.

While a stolen ephemeral private key can enable an attacker to decipher some encrypted communications, the scope of the compromise is limited to the specific session for which the ephemeral key is associated. As such, do not log ephemeral keys.

The application should configure the Public-Key-Pins response header to provide effective protection against man-in-the-middle attacks that take advantage of rogue or compromised certificate authorities.

The header takes the following format:

Public-Key-Pins: pin-sha256="base64"; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"]

User-agents, upon encountering the header, would remember to inspect the trusted chain for presence of the public key pinned via this header for the duration specified in max-age. Chain is rejected as trusted if pin is not present. Applications can select either leaf node or a trusted intermediary CA's public key to be pinned. Failure may be reported to host at location specified in report-uri.

The OAuth protocol enables a user to leverage a third-party application (a consumer) to access their resources on a provider application without sharing credentials from the provider to the consumer. Instead of traditional authentication tokens such as a username and password pair, the consumer uses a token and a shared secret to identify itself to the provider. After the channel between the consumer and provider is established, the individual users are authorized through that channel using an access key token and a shared secret provisioned by the provider.
The transmission and storage of these tokens and secrets should be performed as carefully as other credentials are in traditional web applications. In the absence of Secure Sockets Layer (SSL) or Transport Layer Security (TLS), these tokens and secrets are sent in plain text over HTTP and can be seen by anyone eavesdropping on the traffic.