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.

All web forms in the application must be protected against automated submissions. An attacker can automatically submit fill and submit registration forms to create fake accounts or overwhelm the database. Contact and messaging forms that do not prevent automated form submissions can be used to spam the application administrators or users. Automated password cracking programs can target login forms with ineffective anti-automation mechanisms. Programmers must always assume that all user interfaces will be abused by attackers in order to find weaknesses.

Integer overflow errors occur when a program fails to account for the fact that an arithmetic operation can result in a quantity either greater than a data type's maximum value or less than its minimum value. These errors often cause problems in memory allocation functions, where user input intersects with an implicit conversion between signed and unsigned values. If an attacker can cause the program to under-allocate memory or interpret a signed value as an unsigned value in a memory operation, the program might be vulnerable to a buffer overflow.

Example 1: The following code excerpt from OpenSSH 3.3 demonstrates a classic case of integer overflow:

nresp = packet_get_int();
if (nresp > 0) {
 response = xmalloc(nresp*sizeof(char*));
 for (i = 0; i < nresp; i++)
  response[i] = packet_get_string(NULL);
}

If nresp has the value 1073741824 and sizeof(char*) has its typical value of 4, then the result of the operation nresp*sizeof(char*) overflows, and the argument to xmalloc() will be 0. Most malloc() implementations will allow for the allocation of a 0-byte buffer, causing the subsequent loop iterations to overflow the heap buffer response.

Example 2: This example processes user input comprised of a series of variable-length structures. The first 2 bytes of input dictate the size of the structure to be processed.

 char* processNext(char* strm) {
 char buf[512];
 short len = *(short*) strm;
 strm += sizeof(len);
 if (len <= 512) {
  memcpy(buf, strm, len);
  process(buf);
  return strm + len;
 } else {
  return -1;
 }
}

The programmer has set an upper bound on the structure size: if it is larger than 512, the input will not be processed. The problem is that len is a signed integer, so the check against the maximum structure length is done with signed integers, but len is converted to an unsigned integer for the call to memcpy(). If len is negative, then it will appear that the structure has an appropriate size (the if branch will be taken), but the amount of memory copied by memcpy() will be quite large, and the attacker will be able to overflow the stack with data in strm.

An intent manipulation issue occurs when the following two conditions are met:

1. An attacker is able to specify the action, classname, or component of an Android Intent.

For example, an attacker may be able to specify the classname or the component to handle the intent.

2. By specifying the action, classname, or component, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to transmit sensitive information to a third-party software on the device.

Example 1: The following code uses an argument read from an HTTP request to set the classname of an intent.

String arg = request.getParameter("arg");
...
Intent intent = new Intent();
...
intent.setClassName(arg);
ctx.startActivity(intent);
...

An internal Intent uses a custom action as defined by an internal component. Implicit intents can facilitate the calling of intents from any given external component without knowledge of the specific component. Combining the two allows for an application to access intents specified for a specific internal use from outside of the desired application context.

The ability to process an internal Intent from an external application can enable for a wide variety of man-in-the-middle exploits ranging in severity from information leakage and denial of service to remote code execution, depending on the capacity of the internal action specified by the Intent.

Example 1: The following code uses an implicit internal Intent.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android Intents are used to bind applications and application components together by providing instruction on actions that a given component performs. Pending intents are created to deliver the Intent at a later time. Implicit intents facilitate the calling of intents from any given external component, using a general name and filter to determine execution.

When an implicit Intent is created as a PendingIntent, this might allow for the Intent to be sent to an unintended component that runs outside of the intended temporal context, leaving the system vulnerable to exploit vectors such as denial of service, private and system information leakage, and privilege escalation.

Example 1: The following code uses an implicit PendingIntent.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

Allowing modification of the underlying Intent of a PendingIntent after its creation can leave a system open to attack. This mostly depends on the overall capability of the underlying Intent. In most cases, it is best practice to prevent potential issues by setting the PendingIntent flag to FLAG_IMMUTABLE.

Example 1: The following includes a PendingIntent created with a flag value of FLAG_MUTABLE.

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

A redirection intent manipulation issue occurs when the following conditions are met:
1. An exported component accepts an arbitrary Intent nested in the extras bundle of an externally provided Intent.

2. The exported component uses the arbitrary Intent to launch a component by calling startActivity, startService, or sendBroadcast.

An attacker can possibly gain a capability that would not otherwise be permitted when these conditions exist.
Example 1: The following code accepts a nested Intent from an external source and uses that Intent to start an activity.

...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...

The J2EE standard requires that applications use the container's resource management facilities to obtain connections to resources.

For example, a J2EE application should obtain a database connection as follows:

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();

and should avoid obtaining a connection in this way:

conn = DriverManager.getConnection(CONNECT_STRING);

Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard.

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 common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

The most common example of forgotten debug code is a main() method appearing in a web application. Although this is an acceptable practice during product development, classes that are part of a production J2EE application should not define a main().

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);
   }
}

The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues, including:

- In-band versus out-of-band signaling

- Compatibility between protocol versions

- Channel security

- Error handling

- Network constraints (firewalls)

- Session management

Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems.

Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers.

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.