Privacy Violation 侵犯隱私

 

Abstract:

 

ManagerUtils.java 中的方法 send() 會使機密信息處理不當，從而危及到用戶的個人隱私，通常這是一種非法行為。

 

 

Explanation:

 

Privacy Violation 會在以下情況下發生：

 

1. 用戶私人信息進入了程序。

 

2. 數據被寫到了一個外部介質，例如控制台、file system 或網絡。

 

這種情況下，數據被傳遞給 ManagerUtils.java 的第 172 行中的 setRequestProperty()。

 

 

示例 1：以下代碼包含了一個日志記錄語句，該語句通過在日志文件中存儲記錄信息跟蹤添加到數據庫中的各條記錄信息。在存儲的其他數值中，getPassword() 函數可以返回一個由用戶提供的、與用戶帳號相關的明文密碼。

 

 

pass = getPassword();

...

dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

 

 

在以上示例中，代碼采用日志的形式將明文密碼記錄到了文件系統中。雖然許多開發人員認為文件系統是存儲數據的安全位置，但這不是絕對的，特別是在涉及到隱私問題時。

 

在移動世界中隱私是最令人擔心的問題之一，其原因有以下兩點。一是設備丟失的幾率較高。第二點與移動應用程序之間的進程間通信有關。移動平台的本質是從各種來源下載並在相同設備上運行的應用程序。因為惡意軟件在銀行應用程序附近運行的可能性很高，所以應用程序的作者需要注意消息所包含的信息，這些消息將會發送給在設備上運行的其他應用程序。移動應用程序之間的進程間通信不應包含敏感信息。

 

示例 2：以下代碼可讀取存儲在 Android WebView 上的給定站點的用戶名和密碼，並廣播給所有注冊的接收者。

 

...

webview.setWebViewClient(new WebViewClient() {

  public void onReceivedHttpAuthRequest(WebView view,

        HttpAuthHandler handler, String host, String realm) {

    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);

    String username = credentials[0];

    String password = credentials[1];

    Intent i = new Intent();

    i.setAction("SEND_CREDENTIALS");

    i.putExtra("username", username);

    i.putExtra("password", password);

    view.getContext().sendBroadcast(i);

  }

});

...

 

 

此示例存在多個問題。首先，WebView 憑證以明文的形式存儲且不經過 hash 處理。因此，如果用戶擁有 root 設備（或使用仿真器），他/她就能讀取存儲的給定站點的密碼。其次，明文憑證將被廣播給所有注冊的接收者，這就意味着任何使用 SEND_CREDENTIALS 收聽的注冊接收者都將收到消息。即使權限限制接收者人數，廣播也不會受到保護；既然這樣，我們也不建議將權限作為修復方式使用。

 

可以通過多種方式將私人數據輸入到程序中：

 

— 以密碼或個人信息的形式直接從用戶處獲取

 

— 由應用程序訪問數據庫或者其他數據存儲形式

 

— 間接地從合作者或者第三方處獲取

 

通常情況下，在移動世界的背景下，該私人信息將包括（以及密碼、SSN 和其他一般個人信息）：

 

- 位置

 

- 手機號碼

 

- 序列號和設備 ID

 

- 網絡運營商信息

 

- 語音信箱信息

 

 

有時，某些數據並沒有貼上私人數據標簽，但在特定的上下文中也有可能成為私人信息。比如，通常認為學生的學號不是私人信息，因為學號中並沒有明確而公開的信息用以定位特定學生的個人信息。但是，如果學校用學生的社會保障號碼生成學號，那么這時學號應被視為私人信息。

 

安全和隱私似乎一直是一對矛盾。從安全的角度看，您應該記錄所有重要的操作，以便日后可以鑒定那些非法的操作。然而，當其中牽涉到私人數據時，這種做法就存在一定風險了。

 

雖然不安全地處理私人數據有多種形式，但是常見的風險來自於盲目的信任。程序員通常會信任程序運行的操作系統，因此認為將私人信息存放在 file system、注冊表或者獲得局部控制的資源中是值得信任的。盡管已經限制了某些資源的訪問權限，但仍無法保證所有訪問這些資源的個體都是值得信任的。例如，2004 年，一個不道德的 AOL 員工把大約 9200 萬個客戶的私人電子郵件地址賣給了一個通過垃圾郵件進行營銷的賭博網站 [1]。

 

鑒於此類備受矚目的信息盜取事件，私人信息的收集與管理正日益規范化。要求各個組織應根據其經營地點、所從事的業務類型及其處理的私人數據性質，遵守下列一個或若干個聯邦和州的規定：

 

- Safe Harbor Privacy Framework [3]

 

- Gramm-Leach Bliley Act (GLBA) [4]

 

- Health Insurance Portability and Accountability Act (HIPAA) [5]

 

- California SB-1386 [6]

 

盡管制定了這些規范，Privacy Violation 漏洞仍時有發生。

此結果來自 Will Enck 提供的規則或研究成果。 http://www.enck.org/

 

 

 

Instance ID: BE53D4993994F6B5A441B54CE68A4F86

 

Priority Metadata Values:

 

            IMPACT: 4.0

 

            LIKELIHOOD: 2.8

 

Legacy Priority Metadata Values:

 

            SEVERITY: 3.0

 

            CONFIDENCE: 5.0

 

 

Remediation Effort: 2.0

 

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

 

 

Recommendations:

 

當安全和隱私的需要發生矛盾時，通常應優先考慮隱私的需要。為滿足這一要求，同時又保證信息安全的需要，應在退出程序前清除所有私人信息。

 

為加強隱私信息的管理，應不斷改進保護內部隱私的原則，並嚴格地加以執行。這一原則應具體說明應用程序應該如何處理各種私人數據。在貴組織受到聯邦或者州法律的制約時，應確保您的隱私保護原則盡量與這些法律法規保持一致。即使沒有針對貴組織的相應法規，您也應當保護好客戶的私人信息，以免失去客戶的信任。

 

保護私人數據的最好做法就是最大程度地減少私人數據的暴露。不應允許應用程序、流程處理以及員工訪問任何私人數據，除非是出於職責以內的工作需要。正如最小授權原則一樣，不應該授予訪問者超出其需求的權限，對私人數據的訪問權限應嚴格限制在盡可能小的范圍內。

 

對於移動應用程序，請確保它們從不與在設備上運行的其他應用程序進行任何敏感數據通信。存儲私人數據時，通常都應加密。對於 Android 以及其他任何使用 SQLite 數據庫的平台來說，SQLCipher 是一個好選擇 -- 對 SQLite 數據庫的擴展為數據庫文件提供了透明的 256 位 AES 加密。因此，憑證可以存儲在加密的數據庫中。

 

例 3：以下代碼演示了在將所需的二進制碼和存儲憑證下載到數據庫文件后，將 SQLCipher 集成到 Android 應用程序中的方法。

 

import net.sqlcipher.database.SQLiteDatabase;

...

  SQLiteDatabase.loadLibs(this);   File dbFile = getDatabasePath("credentials.db");   dbFile.mkdirs();   dbFile.delete();   SQLiteDatabase db = SQLiteDatabase.openOrCreateDatabase(dbFile, "credentials", null);   db.execSQL("create table credentials(u, p)");   db.execSQL("insert into credentials(u, p) values(?, ?)", new Object[]{username, password});

...

 

 

請注意，對 android.database.sqlite.SQLiteDatabase 的引用可以使用 net.sqlcipher.database.SQLiteDatabase 代替。

 

要在 WebView 存儲上啟用加密，需要使用 sqlcipher.so 庫重新編譯 WebKit。

 

例 4：以下代碼從 Android WebView 存儲讀取給定站點的用戶名和密碼，而不是將其廣播到所有注冊的接收器，它僅在內部廣播，以便廣播只能由同一應用程序的其他部分看到。

 

...

webview.setWebViewClient(new WebViewClient() {

  public void onReceivedHttpAuthRequest(WebView view,

        HttpAuthHandler handler, String host, String realm) {

    String[] credentials = view.getHttpAuthUsernamePassword(host, realm);

    String username = credentials[0];

    String password = credentials[1];

    Intent i = new Intent();

    i.setAction("SEND_CREDENTIALS");

    i.putExtra("username", username);

    i.putExtra("password", password);

    LocalBroadcastManager.getInstance(view.getContext()).sendBroadcast(i);

  }

});

...

 

 

 

Tips:

 

1. 要徹底審計所有的 Privacy Violation 漏洞，措施之一就是確保自定義的規則可以識別所有進入程序的私人或敏感信息。無法自動識別多數私人數據信息。若不使用自定義規則，您執行的 Privacy Violation 漏洞檢查可能是不完整的。

 

2. 可使用 Fortify Java Annotations、FortifyPassword、FortifyNotPassword、FortifyPrivate 和 FortifyNotPrivate 來指示哪些字段和變量代表密碼和私人數據。

 

3. 許多現代 Web 框架都提供對用戶輸入執行驗證的機制。其中包括 Struts 和 Spring MVC。為了突出顯示未經驗證的輸入源，HPE Security Fortify 安全編碼規則包會降低 HPE Security Fortify Static Code Analyzer（HPE Security Fortify 靜態代碼分析器）報告的問題被利用的可能性，並在使用框架驗證機制時提供相應的依據，以動態重新調整問題優先級。我們將這種功能稱之為上下文敏感排序。為了進一步幫助 HPE Security Fortify 用戶執行審計過程，HPE Security Fortify 軟件安全研究團隊提供了數據驗證項目模板，該模板會根據應用於輸入源的驗證機制，將問題分組到多個文件夾中。

 

 

 

References:

 

[1] J. Oates, AOL man pleads guilty to selling 92m email addies, The Register, 2005, http://www.theregister.co.uk/2005/02/07/aol_email_theft/

 

[2] Privacy Initiatives, U.S. Federal Trade Commission, http://www.ftc.gov/privacy/

 

[3] Safe Harbor Privacy Framework, U.S. Department of Commerce, http://www.export.gov/safeharbor/

 

[4] Financial Privacy: The Gramm-Leach Bliley Act (GLBA), Federal Trade Commission, http://www.ftc.gov/privacy/glbact/index.html

 

[5] Health Insurance Portability and Accountability Act (HIPAA), U.S. Department of Human Services, http://www.hhs.gov/ocr/hipaa/

 

[6] California SB-1386, Government of the State of California, 2002, http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

 

[7] M. Howard, D. LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, 2003

 

[8] SQLCipher., http://sqlcipher.net/

 

[9] FUNDAMENTALS-4: Establish trust boundaries, Oracle, http://www.oracle.com/technetwork/java/seccodeguide-139067.html#0

 

[10] CONFIDENTIAL-2: Do not log highly sensitive information, Oracle, http://www.oracle.com/technetwork/java/seccodeguide-139067.html#2

 

[11] INPUT-1: Validate inputs, Oracle, http://www.oracle.com/technetwork/java/seccodeguide-139067.html#5

 

[12] Standards Mapping - Common Weakness Enumeration, CWE ID 359

 

[13] Standards Mapping - OWASP Mobile Top 10 Risks 2014, M2 Insecure Data Storage

 

[14] Standards Mapping - OWASP Top 10 2007, A6 Information Leakage and Improper Error Handling

 

[15] Standards Mapping - OWASP Top 10 2013, A6 Sensitive Data Exposure

 

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1, Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4

 

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2, Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4

 

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0, Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4

 

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0, Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.2.1

 

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1, Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.2.1

 

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2, Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.2.1

 

[22] Standards Mapping - Security Technical Implementation Guide Version 3.1, APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I

 

[23] Standards Mapping - Security Technical Implementation Guide Version 3.10, APP3210.1 CAT II, APP3340 CAT I

 

[24] Standards Mapping - Security Technical Implementation Guide Version 3.4, APP3210.1 CAT II, APP3340 CAT I

 

[25] Standards Mapping - Security Technical Implementation Guide Version 3.5, APP3210.1 CAT II, APP3340 CAT I

 

[26] Standards Mapping - Security Technical Implementation Guide Version 3.6, APP3210.1 CAT II, APP3340 CAT I

 

[27] Standards Mapping - Security Technical Implementation Guide Version 3.7, APP3210.1 CAT II, APP3340 CAT I

 

[28] Standards Mapping - Security Technical Implementation Guide Version 3.9, APP3210.1 CAT II, APP3340 CAT I

 

[29] Standards Mapping - Security Technical Implementation Guide Version 4.1, APSC-DV-000650 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II

 

[30] Standards Mapping - Web Application Security Consortium 24 + 2, Information Leakage

 

[31] Standards Mapping - Web Application Security Consortium Version 2.00, Information Leakage (WASC-13)