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)