The code attempts to use the Android SQLite database handler after the it has already been closed. Any further references to the handler without re-establishing the database connection will throw an exception, and can cause the application to crash if the exception is not caught.

Example: The following code might be from a program that caches user values temporarily in memory, but can call flushUpdates() to commit the changes to disk. The method properly closes the database handler after writing updates to the database. However, when flushUpdates() is called again, the database object is referenced again before reinitializing it.

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

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

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Hardware and device specific identifiers persist across data wipes and factory resets. One should not rely on these to generate unique identifiers that are used to authorize or authenticate users.

Moreover, leakage of universally unique identifiers, that can be associated with personal information, pose a threat to user privacy and security.

Android Class Loading Hijacking vulnerabilities take two forms:

- An attacker can change the name of the directories that the program searches to load classes, thereby pointing the path to one that they have control over: the attacker explicitly controls the paths which should be searched for classes.

- An attacker can change the environment in which the class loads: the attacker implicitly controls what the path name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the directories searched for classes to load. Android Class Loading Hijacking vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.



2. The data is used as or as part of a string representing a library directory to search for classes to load.



3. By executing code from the library path, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses the user changeable userClassPath to determine the directory in which to search for classes to load.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

This code allows an attacker to load a library and potentially execute arbitrary code with the elevated privilege of the app by being able to modify the result of userClassPath to point to a different path, which they control. Because the program does not validate the value read from the environment, if an attacker can control the value of userClassPath, then they can fool the application into pointing to a directory that they control and therefore load the classes that they have defined, using the same privileges as the original app.

Example 2: The following code uses the user changeable userOutput to determine the directory the optimized DEX files should be written.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

This code allows an attacker to specify the output directory for Optimized DEX files (ODEX). This then allows a malicious user to change the value of userOutput to a directory that they control, such as external storage. Once this is achieved, it is simply a matter of replacing the outputted ODEX file with a malicious ODEX file to have this executed with the same privileges as the original application.

Android applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. The debuggable attribute of the <application> tag defines whether compiled binaries should include debugging information.

The use of debug binaries causes an application to provide as much information about itself as possible to the user. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production. Attackers may leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application.

Apache Axis 2 provides developers with a utility to monitor incoming and outgoing SOAP messages through a Java applet. The SOAP Monitor will show all SOAP messages used to invoke a Web Service. Attackers may use the utility to eavesdrop on traffic between a Web Service and its clients.

If a service relays messages to other services, the messages are exposed to the weakest transport mechanism used between relay points. REST by itself does not include any security mechanisms, so this service relies on the transport layer for message integrity and confidentiality.

The following configuration enables REST:

<axisconfig name="AxisJava2.0">
...
    <parameter name="disableREST" locked="true">false</parameter>
...
</axisconfig>

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.