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.

Insecure RFCOMM sockets establish a communication channel which does not have an authenticated link key and so it will be subject to man-in-the-middle attacks. For Bluetooth 2.1 devices, the link key will be encrypted, as encryption is mandatory. For legacy devices (pre Bluetooth 2.1 devices) the link key will be not be encrypted.

Example 1: The following code uses insecure RFCOMM sockets:

    device.createInsecureRfcommSocketToServiceRecord(MY_UUID);

Any area of the website, or web application, that contains sensitive information or access to privileged functionality such as remote site administration requires that the pages under the secure section of the site should be made available only over SSL. Failure to conform with this guideline could expose sensitive content and functionality to unauthorized access either through interception during cleartext transmission or via unencrypted storage in log files. Programmer's must identify and isolate portions of the application designed to handle sensitive content and functionality and communicate it to the site administrator. The administrator must ensure that such sections are accessible over a SSL/TLS connection and HTTP requests to them are blocked.

Maintaining the confidentiality and integrity of information in transit is a primary function of the SSL/TLS protocol. Vulnerabilities in the protocol implementation could however severely compromise these guarantees. Failure to establish a cryptographic binding of a handshake to the enclosing session causes the SSL/TLS renegotiation protocol to fall victim to man-in-the-middle attacks that could allow an attacker to inject plaintext into the protocol stream. Renegotiation was developed to support long running sessions where encryption keys will need to be changed to ensure cryptographic security. However, the real problem manifests within the application using SSLv3/TLS. Since HTTP requests cannot be processed until they are complete, web servers cache the request until it is finished. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted. This indeterminate buffer state is the manifestation of the problem. Unfortunately, servers vulnerable to this attack are SSLv3/TLS enabled web servers that do NOT flush the request buffers prior to the renegotiation of SSL Keys. Thus an attacker can leverage this oversight to inject data into the beginning of the conversation between unsuspecting clients and the web server.

A server configured to use the vulnerable protocol implementation exposes the hosted application to malicious data injection exploits. An application that lacks appropriate input filters to reject incoming malicious requests can enable an attacker to steal the authentication credentials of users, which can lead to further compromises by using the stolen privileges.

Return Of Bleichenbacher's Oracle Threat (ROBOT) is an adaptive chosen-ciphertext attack on the RSA PKCS#1 v1.5 encryption standard. The vulnerability in the implementation of the RSA PKCS#1 v1.5 algorithm enables the attacker to decrypt and encrypt arbitrary ciphertext without access to the server's private key. This attack is a variation of the original Bleichenbacher's attack that exploited error messages from server during SSL handshake process for errors in the PKCS#1 v1.5 padding. An attacker can use specially crafted handshake messages that result in PKCS#1 v1.5 padding errors to perform an adaptive-chosen ciphertext attack. The various malformed PKCS#1 v1.5 ClientKeyExchange messages that results in different server responses are:
- M1 message contains a correctly formatted PKCS#1 v1.5 padding: 0x0002{padding}00{TLS version}{secret}
- M2 message contains two bytes padding prefix with incorrect value: 0x4117{padding}00{TLS version}{secret}
- M3 message contains padding termination zero byte at wrong position: 0x0002{padding}11{secret}0011
- M4 message does not contain padding termination zero byte: 0x0002{padding}111111{secret}
- M5 message contains wrong TLS version: 0x0002{padding}000202{secret}

An application that relies on SSL/TLS to ensure authenticity, confidentiality, and integrity of data transmissions might be vulnerable to compromise if it fails to choose sufficiently strong cryptographic algorithms. The protection mechanism strength is determined by the authentication, encryption, and hashing algorithms, collectively known as a cipher suite. A cipher suite is used for the transmission of sensitive information over the TLS/SSL channel.

When a server supports a range of cipher suites of varying strengths, using a weak cipher or an encryption key of insufficient length might allow an attacker to defeat the protection mechanism and steal or modify sensitive information. Attackers could manipulate applications that are deployed on an insecurely configured web server into choosing weak cipher suites. Weak cipher suites are vulnerable to brute force and man-in-the-middle attacks, which might result in interception and manipulation of sensitive data.

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions resulting in periodic version updates. Each new revision is designed to address the security weaknesses discovered in previous versions. Use of an insecure version of TLS/SSL weakens the data protection strength and might allow an attacker to compromise, steal, or modify sensitive information.

Weak versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing
- Use of weak cipher suites

The presence of these properties might allow an attacker to intercept, modify, or tamper with sensitive data.