程式碼嘗試在 Android SQLite 資料庫處理常式已被解除後使用該處理常式。若在未重新建立資料庫連線的情況下參照該處理常式，便會拋出異常，並在未能捕捉異常時造成應用程式當機。

範例：以下程式碼可能是來自將使用者值暫時快取於記憶體中，但可以呼叫 flushUpdates() 以將變更交付至磁碟的程式。該方法會在將更新寫入至資料庫後正確關閉資料庫處理常式。然而，若再次呼叫 flushUpdates()，便會在重新初始化資料庫物件前再次參照該物件。

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

硬體和裝置專用識別碼在資料掃除和原廠重設後仍然存在。我們不應該依靠這些識別碼來產生用來授權或驗證使用者的唯一識別碼。

此外，通用唯一識別碼可能與個人資訊有關連性，因此洩漏通用唯一識別碼會對使用者隱私和安全性造成威脅。

Android Class Loading Hijacking 弱點有以下兩種形式：

- 攻擊者可以變更程式為載入類別而搜尋的目錄名稱，從而指向處於其控制下之某個目錄的路徑：攻擊者明確控制應該從其中搜尋類別的路徑。

- 攻擊者可以篡改載入類別的環境：攻擊者間接控制路徑名稱代表的意義。

在此案例中，我們著重於第一種情況，即攻擊者可以控制為要載入之類別而搜尋的目錄的可能性。在以下情況下，會發生此類型的 Android Class Loading Hijacking 弱點：

1. 資料從不可信賴的來源進入應用程式。



2. 資料用作代表程式庫目錄的整個字串或一部分字串，以便搜尋要載入的類別。



3. 藉由從程式庫路徑執行程式碼，應用程式會給予攻擊者不應該擁有的權限或能力。

範例 1：以下程式碼使用使用者可變更的 userClassPath 來決定搜尋要載入的類別所在的目錄。

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

此程式碼能夠透過修改 userClassPath 的結果來指向所控制的其他路徑，從而讓攻擊者利用應用程式的提升權限，載入程式庫並潛在地執行任意程式碼。因為程式不會驗證從環境讀取的值，所以如果攻擊者可以控制 userClassPath 的值，則攻擊者便可使用與原始應用程式相同的權限，愚弄應用程式，讓應用程式指向他們所控制的目錄，從而載入他們所定義的類別。

範例 2：以下程式碼使用使用者可變更的 userOutput 來決定應寫入最佳化 DEX 檔案的目錄。

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

此程式碼可讓攻擊者指定最佳化 DEX 檔案 (ODEX) 的輸出目錄。然後，此程式碼還會讓惡意使用者將 userOutput 值變更為他們所控制的目錄，如外部儲存裝置。一旦完成竄改，便只需將輸出的 ODEX 檔案替換為惡意 ODEX 檔案，就可以使用與原始應用程式相同的權限執行該動作。

Android 應用程式可設定為產生除錯二進位程式。這些二進位程式提供了詳細的除錯訊息，不應該在生產的環境中使用。<application> 標籤的 debuggable 屬性定義編譯後的二進位程式是否應包含除錯資訊。

使用除錯二進位程式會使應用程式提供許多有關其本身的資訊給使用者。除錯二進位程式只能用於開發或測試的環境中，如果將它們部署在生產的環境中，會有安全上的風險。攻擊者可能利用這些從除錯輸出得到的額外資訊，來發動針對架構、資料庫或應用程式所使用的其他資源的攻擊。

Apache Axis 2 提供開發人員一組公用程式，監視透過 Java applet 內送與外寄的 SOAP 訊息。SOAP 監視器會顯示所有可叫用 Web 服務的 SOAP 訊息。攻擊者可能利用此公用程式，竊聽 Web 服務與其用戶端之間的流量。

如果一個服務將訊息傳遞至其他服務，則訊息會暴露在轉送點之間最脆弱的傳輸機制中。由於 REST 本身並未包含任何安全性機制，因此該服務會依賴傳輸層檢查訊息的完整性和機密性。

以下組態會啟用 REST：

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

如果處理敏感資訊的應用程式並未使用訊息層級加密，則只能在加密的傳輸通道進行通訊。