原文：
https://blog.csdn.net/woddle/article/details/71175140
在實際項目代碼審計中發現，目前很多手機銀行雖然使用了https通信方式，但是只是簡單的調用而已，並未對SSL證書有效性做驗證。在攻擊者看來，這種漏洞讓https形同虛設，可以輕易獲取手機用戶的明文通信信息。
手機銀行開發人員在開發過程中為了解決ssl證書報錯的問題（使用了自己生成了證書后，客戶端發現證書無法與系統可信根CA形成信任鏈，出現了 CertificateException等異常。），會在客戶端代碼中信任客戶端中所有證書的方式：
01 |
public static HttpClient getWapHttpClient() { |
02 |
try { |
03 |
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType()); |
04 |
trustStore.load(null, null); |
05 |
SSLSocketFactory sf = new MySSLSocketFactory(trustStore); |
06 |
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); |
07 |
//此處信任手機中的所有證書，包括用戶安裝的第三方證書 |
08 |
HttpParams params = new BasicHttpParams(); |
09 |
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1); |
10 |
HttpProtocolParams.setContentCharset(params, HTTP.UTF_8); |
11 |
SchemeRegistry registry = new SchemeRegistry(); |
12 |
registry.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80)); |
13 |
registry.register(new Scheme("https", sf, 443)); |
14 |
ClientConnectionManager ccm = new ThreadSafeClientConnManager(params, registry); |
15 |
return new DefaultHttpClient(ccm, params); |
16 |
} catch (Exception e) { |
17 |
return new DefaultHttpClient(); |
18 |
} |
19 |
} |
而在客戶端中覆蓋google默認的證書檢查機制（X509TrustManager），並且在代碼中無任何校驗SSL證書有效性相關代碼：
01 |
public class MySSLSocketFactory extends SSLSocketFactory { |
02 |
SSLContext sslContext = SSLContext.getInstance("TLS"); |
03 |
04 |
public MySSLSocketFactory(KeyStore truststore) |
05 |
throws NoSuchAlgorithmException, KeyManagementException, |
06 |
KeyStoreException, UnrecoverableKeyException { |
07 |
super(truststore); |
08 |
09 |
TrustManager tm = new X509TrustManager() { |
10 |
public void checkClientTrusted(X509Certificate[] chain, |
11 |
String authType) throws CertificateException { |
12 |
} |
13 |
14 |
//客戶端並未對SSL證書的有效性進行校驗，並且使用了自定義方法的方式覆蓋android自帶的校驗方法 |
15 |
public void checkServerTrusted(X509Certificate[] chain, |
16 |
String authType) throws CertificateException { |
17 |
} |
18 |
19 |
public X509Certificate[] getAcceptedIssuers() { |
20 |
return null; |
21 |
} |
22 |
}; |
23 |
24 |
sslContext.init(null, new TrustManager[] { tm }, null); |
25 |
} |
26 |
} |
問題出來了：
如果用戶手機中安裝了一個惡意證書，那么就可以通過中間人攻擊的方式進行竊聽用戶通信以及修改request或者response中的數據。
手機銀行中間人攻擊過程：
1 客戶端在啟動時，傳輸數據之前需要客戶端與服務端之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。
2 中間人在此過程中將客戶端請求服務器的握手信息攔截后，模擬客戶端請求給服務器（將自己支持的一套加密規則發送給服務器），服務器會從中選出一組加密算法與HASH算法，並將自己的身份信息以證書的形式發回給客戶端。證書里面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
3 而此時中間人會攔截下服務端返回給客戶端的證書信息，並替換成自己的證書信息。
4 客戶端得到中間人的response后，會選擇以中間人的證書進行加密數據傳輸。
5 中間人在得到客戶端的請求數據后，以自己的證書進行解密。
6 在經過竊聽或者是修改請求數據后，再模擬客戶端加密請求數據傳給服務端。就此完成整個中間人攻擊的過程。
以fiddler工具模擬中間人攻擊為例：
1 首先在手機中裝入fiddler根證書：
導出fiddler的根證書：
將fiddler根證書放入手機的SD卡中，然后在手機設置-安全中選擇從SD卡中安裝證書：
成功安裝fiddler根證書到手機上：
2 在PC端打開fiddler，將手機通信代理到PC端fiddler所監聽的端口上（可以在wifi中的高級設置中設置代理），這樣手機銀行的所有通信均會被fiddler監聽到。
3 啟動手機銀行客戶端，會在fiddler中查看到所有請求的明文數據，並且可以進行修改后轉發，成功將https加密繞過。
防護辦法：
使用CA機構頒發證書的方式可行，但是如果與實際情況相結合來看的話，時間和成本太高，所以目前很少有用此辦法來做。由於手機銀行服務器其實是固定的，所以證書也是固定的，可以使用“證書或公鑰鎖定”的辦法來防護證書有效性未作驗證的問題。
具體實現：
1 公鑰鎖定
將證書公鑰寫入客戶端apk中，https通信時檢查服務端傳輸時證書公鑰與apk中是否一致。
01 |
public final class PubKeyManager implements X509TrustManager { |
02 |
private static String PUB_KEY = "30820122300d06092a864886f70d0101" + |
03 |
"0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85"+ |
04 |
"5a545b1f0cc8afb19e38213bac4d55c3f2f19df6dee82ead67f70a990131b6bc"+ |
05 |
"ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657"+ |
06 |
"2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8"+ |
07 |
"609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50"+ |
08 |
"c6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00"+ |
09 |
"33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38"+ |
10 |
"cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b"+ |
11 |
"e0b7a5bc860966dc84f10d723ce7eed5430203010001"; |
12 |
13 |
//鎖定證書公鑰在apk中 |
14 |
public void checkServerTrusted(X509Certificate[] chain, String authType) |
15 |
throws CertificateException { |
16 |
if (chain == null) { |
17 |
throw new IllegalArgumentException( |
18 |
"checkServerTrusted: X509Certificate array is null"); |
19 |
} |
20 |
21 |
if (!(chain.length > 0)) { |
22 |
throw new IllegalArgumentException( |
23 |
"checkServerTrusted: X509Certificate is empty"); |
24 |
} |
25 |
26 |
if (!((null != authType) && authType.equalsIgnoreCase("RSA"))) { |
27 |
throw new CertificateException( |
28 |
"checkServerTrusted: AuthType is not RSA"); |
29 |
} |
30 |
31 |
// Perform customary SSL/TLS checks |
32 |
try { |
33 |
TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509"); |
34 |
tmf.init((KeyStore) null); |
35 |
36 |
for (TrustManager trustManager : tmf.getTrustManagers()) { |
37 |
((X509TrustManager) trustManager).checkServerTrusted(chain, |
38 |
authType); |
39 |
} |
40 |
} catch (Exception e) { |
41 |
throw new CertificateException(e); |
42 |
} |
43 |
44 |
// Hack ahead: BigInteger and toString(). We know a DER encoded Public Key begins |
45 |
// with 0?30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0?00 to drop. |
46 |
RSAPublicKey pubkey = (RSAPublicKey) chain[0].getPublicKey(); |
47 |
String encoded = new BigInteger(1 /* positive */, pubkey.getEncoded()).toString(16); |
48 |
49 |
// Pin it! |
50 |
final boolean expected = PUB_KEY.equalsIgnoreCase(encoded); |
51 |
52 |
if (!expected) { |
53 |
throw new CertificateException( |
54 |
"checkServerTrusted: Expected public key: " + PUB_KEY + |
55 |
", got public key:" + encoded); |
56 |
} |
57 |
} |
58 |
} |
2 證書鎖定：
即為客戶端頒發公鑰證書存放在手機客戶端中，在https通信時，在客戶端代碼中固定去取證書信息，不是從服務端中獲取。
關於證書或公鑰鎖定技術可參考下面鏈接：
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning