阿里Android开发手册-安全

《阿里Android开发手册》中关于安全部分的说明

    1. 【强制】 禁止使用常量初始化矢量参数构建 IvParameterSpec，建议 IV 通过随机方 式产生。

说明：
使用常量初始化向量，密码文本的可预测性会高得多，容易受到字典式攻击。 iv 的 作用主要是用于产生密文的第一个 block，以使最终生成的密文产生差异（明文相同 的情况下），使密码攻击变得更为困难。
正例：

byte[] rand = new byte[16];
SecureRandom r = new SecureRandom();
r.nextBytes(rand);
IvParameterSpec iv = new IvParameterSpec(rand);

反例：

IvParameterSpec iv_ = new IvParameterSpec("1234567890".getBytes());
System.out.println(iv.getIV());

    2. 【强制】 将 android:allowbackup 属性必须设置为 false，阻止应用数据被导出。

说明：
android:allowBackup 原本是 Android 提供的 adb 调试功能，如果设置为 true， 可以导出应用数据备份并在任意设备上恢复。这对应用安全性和用户数据隐私构成 极大威胁，所以必须设置为 false，防止数据泄露。
正例：

<application
    android:allowBackup="false"
    android:largeHeap="true"
    android:icon="@drawable/test_launcher"阿里巴巴 Android 开发手册
    android:label="@string/app_name"
    android:theme="@style/AppTheme" >

    3. 【强制】 如果使用自定义 HostnameVerifier 实现类，必须在 verify()方法中校验服务 器主机名的合法性，否则可能受到中间人攻击。

说明：
在与服务器建立 https 连接时，如果 URL 的主机名和服务器的主机名不匹配，则 可通过该回调接口来判断是否应该允许建立连接。如果回调内实现不恰当，没有有 效校验主机名，甚至默认接受所有主机名，会大大增加安全风险。
反例：

HostnameVerifier hnv = new HostnameVerifier() {
@Override
public boolean verify(String hostname, SSLSession session) {
    // 不做校验，接受任意域名服务器
    return true;
    }
};
HttpsURLConnection.setDefaultHostnameVerifier(hnv);

 4. 【强制】 如果使用自定义 X509TrustManager 实现类，必须在 checkServerTrusted() 方法中校验服务端证书的合法性，否则可能受到中间人攻击。

说明：
常见误区是 checkServerTrusted()方法根本没有实现，这将导致 X509TrustManager 形 同 虚 设 。 该 方 法 中 需 要 实 现 完 备 的 校 验 逻 辑 ， 对 于 证 书 错 误 抛 出 CertificateException 。
正例：

HostnameVerifier hnv = new HostnameVerifier() {
    @Override
    public boolean verify(String hostname, SSLSession session) {
    if("yourhostname".equals(hostname)){
        return true;
    } else {
        HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier();
        return hv.verify(hostname, session);
        }
    }
};

反例：

TrustManager tm = new X509TrustManager() {
    public void checkClientTrusted(X509Certificate[] chain, String authType)
    throws CertificateException {
    //do nothing，接受任意客户端证书
}
    public void checkServerTrusted(X509Certificate[] chain, String authType)
        throws CertificateException {
        //do nothing，接受任意服务端证书
}
    public X509Certificate[]         getAcceptedIssuers() {
        return null;
    }
};
sslContext.init(null, new TrustManager[] { tm }, null);

    5. 【强制】 在 SDK 支持的情况下，Android 应用必须使用 V2 签名，这将对 APK 文 件的修改做更多的保护。

    6. 【强制】 所有的 Android 基本组件（Activity、 Service、 BroadcastReceiver、阿里巴巴 Android 开发手册 ContentProvider 等）都不应在没有严格权限控制的情况下，将 android:exported 设 置为 true。

    7. 【强制】 WebView 应设置 WebView#getSettings()#setAllowFileAccess(false)、 WebView#getSettings()#setAllowFileAccessFromFileURLs(false) 、 WebView#getSettings()#setAllowUniversalAccessFromFileURLs(false)，阻止 file scheme URL 的访问。

    8. 【强制】 不要把敏感信息打印到 log 中。

说明：
在开发过程中，为了方便调试，通常会使用 log 函数输出一些关键流程的信息，这些信息中通常会包含敏感内容，让攻击者更加容易了解 APP 内部结构，方便破解和攻击，甚至直接获取到有价值的敏感信息。
反例：

String username = "log_leak";
String password = "log_leak_pwd";
Log.d("MY_APP", "usesname" + username);
Log.v("MY_APP", "send message to server ");

以上代码使用 Log.d Log.v 打印程序的执行过程的 username 等调试信息，日志没有关闭，攻击者可以直接从 Logcat 中读取这些敏感信息。所以在产品的线上版本中关闭调试接口，不要输出敏感信息。

    9. 【强制】 确保应用发布版本的 android:debuggable 属性设置为 false。

    10. 【强制】 本地加密秘钥不能硬编码在代码中，更不能使用 SharedPreferences 等本地持久化机制存储。应选择 Android 自身的秘钥库（KeyStore）机制或者其他安全 性更高的安全解决方案保存。

说明：
应用程序在加解密时，使用硬编码在程序中的密钥，攻击者通过反编译拿到密钥可 以轻易解密 APP 通信数据。

    11. 【 建议】 addJavascriptInterface() 可以添加 JS 对本地 Java 方法的调用，但这本身 会导致恶意代码的攻击。在 Android 4.2（API Level 17）以下，不应再使用这样的 调用方式。在 Android 4.2 及以上，需要对本地被远程调用的方法显式添加 @JavascriptInterface annotation。

    12. 【强制】 使用 Android 的 AES/DES/DESede 加密算法时，不要使用 ECB 加密模式， 应使用 CBC 或 CFB 加密模式。

说明：
加密模式有 ECB、 CBC、 CFB、 OFB 等，其中 ECB 的安全性较弱，如果使用固定的密钥，相同的明文将会生成相同的密文，容易受到字典攻击，建议使用 CBC、CFB 或 OFB 等模式。
    1. ECB：Electronic codebook，电子密码本模式
    2. CBC：Cipher-block chaining，密码分组链接模式
    3. CFB：Cipher feedback，密文反馈模式
    4. OFB：Output feedback，输出反馈模式

    13. 【强制】 Android APP 在 HTTPS 通信中，验证策略需要改成严格模式。 说明： Android APP 在 HTTPS 通信中，使用 ALLOW_ALL_HOSTNAME_VERIFIER，表 示允许和所有的 HOST 建立 SSL 通信，这会存在中间人攻击的风险，最终导致敏感 信息可能会被劫持，以及其他形式的攻击。

反例：
SSLSocketFactory sf = new MySSLSocketFactory(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
ALLOW_ALL_HOSTNAME_VERIFIER 关闭 host 验证，允许和所有的 host建立SSL通信，BROWSER_COMPATIBLE_HOSTNAME_VERIFIER 和浏览器兼容的验证策略，即通配符能够匹配所有子域名 ，STRICT_HOSTNAME_VERIFIER 严格匹配模式，hostname 必须匹配第一个 CN 或者任何一个 subject-alts，以上例子使用了 ALLOW_ALL_HOSTNAME_VERIFIER，需要改成 STRICT_HOSTNAME_ VERIFIER。

    14. 【推荐】 在 Android 4.2 （API Level 17）及以上，对安全性要求较高的应用可在 Activity 中，对 Activity 所关联的 Window 应用 WindowManager.LayoutParams.FLAG_ SECURE，防止被截屏、录屏。但要注意的是，一个 Activity 关联的 Window 可 能不止一个，如果使用了 Dialog / DialogFragment 等控件弹出对话框，它们本身 也会创建一个新的 Window，也一样需要保护。

    15. 【推荐】 zip 中不要包含 ../../file 这样的路径，可能被篡改目录结构，造成攻击。

说明：
当 zip 压缩包中允许存在"../"的字符串，攻击者可以利用多个"../"在解压时改变 zip 文 件存放的位置，当文件已经存在是就会进行覆盖，如果覆盖掉的文件是 so、 dex 或 者 odex 文件，就有可能造成严重的安全问题。
正例：
对路径进行判断，存在".."时抛出异常。

//对重要的 Zip 压缩包文件进行数字签名校验，校验通过才进行解压
String entryName = entry.getName();
if (entryName.contains("..")){
    throw new Exception("unsecurity zipfile!");
}

反例：

BufferedOutputStream dest = null;
try {
    ZipInputStream zis = new ZipInputStream(new BufferedInputStream(new FileInputStream("/Users/yunmogong/Documents/test/test.zip")));
    ZipEntry entry;
    while ((entry = zis.getNextEntry()) != null){
        int count;
        byte data[] = new byte[BUFFER];
        String entryName = entry.getName();
        FileOutputStream fos = new FileOutputStream(entryName);
        //System.out.println("Extracting:" + entry);
        dest = new BufferedOutputStream(fos, BUFFER);
        while ((count=zis.read(data,0,BUFFER)) != -1){
            dest.write(data, 0, count);
        }
        dest.flush();
    }
} catch (IOException e) {
    e.printStackTrace();
} finally {
    try {
        dest.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

    16. 【推荐】 MD5 和 SHA-1、SHA-256 等常用算法是 Hash 算法，有一定的安全性， 但不能代替加密算法。敏感信息的存储和传输，需要使用专业的加密机制.