程序与技术分享:Android应用安全之数据传输安全

简介: 程序与技术分享:Android应用安全之数据传输安全

使用md5加密,自己写逆加密的方法,在的AndroidApp上有一个公钥,而你服务器上也同时使用这个公钥就可以做到数据加密,你AndroidApp上比如有一个AppSecret="abcdefg",而你的服务器上面也有这个AppSecret="abcdefg",在AndroidApp上使用SHA1(自己百度找JAVA SHA1的工具类)加密,密钥使用AppSecret,数据发送到服务器上,服务器使用AppSecret="abcdefg"解密即可,这个前提是别人无法破解你的App获取到App里面的AppSecret,而做到这个则需要解开Android的App包,如果别人真做到了,那你任何安全性的保障都是无用的,所以以上的方法即可


Android软件通常使用WIFI网络与服务器进行通信。WiFi并非总是可靠的,例如,开放式网络或弱加密网络中,接入者可以监听网络流量;攻击者可能 //代码效果参考:http://www.jhylw.com.cn/521723255.html

自己设置WIFI网络钓鱼。此外,在获得root权限后,还可以在Android系统中监听网络数据。

不加密地明文传输敏感数据


  最危险的是直接使用HTTP协议登录账户或交换数据。例如,攻击者在自己设置的钓鱼网络中配置DNS服务器,将软件要连接的服务器域名解析至攻击者的另一台服务器在,这台服务器就可以获得用户登录信息,或者充当客户端与原服务器的中间人,转发双方数据。


早期,国外一些著名社交网站的Android客户端的登录会话没有加密,后来出现了黑客工具FaceNiff,专门嗅探这些会话并进行劫持(它甚至支持在WEP、WPA、WPA2加密的WIFI网络上展开攻击),这是目前我所知的唯一一个公开攻击移动软件漏洞的案例。


这类问题的解决方法很显然-----对敏感数据采用基于SSL/TLS的HTTPS进行传输。


SSL通信不检查证书有效性


  在SSL/TLS通信中,客户端通过数字证书判断服务器是否可信,并采用证书的公钥与服务器进行加密通信。


  然而,开发人员在开发过程中为了解决ssl证书报错的问题(使用了自己生成了证书后,客户端发现证书无法与系统可信根CA形成信任链,出现了CertificateException等异常),会在客户端代码中采用信任客户端中所有证书的方式:


1 public static HttpClient getWapHttpClient() {


2


3 try {


4


5 KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());


6


7 trustStore.load(null, null);


8


9 SSLSocketFactory sf = new MySSLSocketFactory(trustStore);


10


11 //代码效果参考:http://www.jhylw.com.cn/030837525.html

sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

12


13   //此处信任手机中的所有证书,包括用户安装的第三方证书


14


15 HttpParams params = new BasicHttpParams();


16


17 HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);


18


19 HttpProtocolParams.setContentCharset(params, HTTP.UTF_8);


20


21 SchemeRegistry registry = new SchemeRegistry();


22


23 registry.register(new Scheme(“http”, PlainSocketFactory.getSocketFactory(), 80));


24


25 registry.register(new Scheme(“https”, sf, 443));


26


27 ClientConnectionManager ccm = new ThreadSafeClientConnManager(params, registry);


28


29 return new DefaultHttpClient(ccm, params);


30


31 } catch (Exception e) {


32


33 return new DefaultHttpClient();


34


35 }


36


37 }


而在客户端中覆盖google默认的证书检查机制(X509TrustManager),并且在代码中无任何校验SSL证书有效性相关代码:


1 public class MySSLSocketFactory extends SSLSocketFactory {


2


3 SSLContext sslContext = SSLContext.getInstance(“TLS”);


4


5 public MySSLSocketFactory(KeyStore truststore) throws NoSuchAlgorithmException, KeyManagementException, KeyStoreException, UnrecoverableKeyException {


6


7 super(truststore);


8


9 TrustManager tm = new X509TrustManager() {


10


11 public void checkClientTrusted(X509Certificate【】 chain, String authType) throws CertificateException {


12


13 }


14


15 //客户端并未对SSL证书的有效性进行校验,并且使用了自定义方法的方式覆盖android自带的校验方法


16


17 public void checkServerTrusted(X509Certificate【】 chain, String authType) throws CertificateException {


18


19 }


20


21 public X509Certificate【】 getAcceptedIssuers() {


22


23 return null;


24


25 }


26


27 };


28


29 sslContext.init(null, new TrustManager【】 { tm }, null);


30


31 }


32 }


 如果用户手机中安装了一个恶意证书,那么就可以通过中间人攻击的方式进行窃听用户通信以及修改request或者response中的数据。


  在钓鱼Wifi网络中,同样地,攻击者可以通过设置DNS服务器使客户端与指定的服务器进行通信。攻击者在服务器上部署另一个证书,在会话建立阶段,客户端会收到这张证书,如果客户端忽略这个证书上的异常,或者接受这个证书,就会成功建立会话、开始加密通信。但攻击者拥有私钥,因此可以解密得到客户端发来数据的明文。攻击者还可以模拟客户端,与真正的服务器联系,充当中间人做监听。


手机应用中间人攻击过程:


1 客户端在启动时,传输数据之前需要客户端与服务端之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。


2 中间人在此过程中将客户端请求服务器的握手信息拦截后,模拟客户端请求给服务器(将自己支持的一套加密规则发送给服务器),服务器会从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给客户端。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。


3 而此时中间人会拦截下服务端返回给客户端的证书信息,并替换成自己的证书信息。


4 客户端得到中间人的response后,会选择以中间人的证书进行加密数据传输。


5 中间人在得到客户端的请求数据后,以自己的证书进行解密。


6 在经过窃听或者是修改请求数据后,再模拟客户端加密请求数据传给服务端。就此完成整个中间人攻击的过程。


防护办法:


  使用CA机构颁发证书的方式可行,但是如果与实际情况相结合来看的话,时间和成本太高,所以目前很少有用此办法来做。由于手机应用服务器其实是固定的,所以证书也是固定的,可以使用“证书或公钥锁定”的办法来防护证书有效性未作验证的问题。


具体实现:


1 公钥锁定


将证书公钥写入客户端apk中,https通信时检查服务端传输时证书公钥与apk中是否一致(实现X509TrustManager接口)。


1 public final class PubKeyManager implements X509TrustManager{


2 private static String PUB_KEY = "30820122300d06092a864886f70d0101" + "0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85" +"5a545b1f0cc8afb19e38213bac4d55c3f2f19df6dee82ead67f70a990131b6bc" + "ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657" +"2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8" + "609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50" +"c6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00" + "33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38" + "cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b" + "e0b7a5bc860966dc84f10d723ce7eed5430203010001";


3


4 //锁定证书公钥在apk中


5


6 public void checkServerTrusted(X509Certificate【】 chain, String authType) throws CertificateException


7


8 {


9


10 if (chain == null) {


11


12 throw new IllegalArgumentException("checkServerTrusted: X509Certificate array is null");


13


14 }


15


16 if (!(chain.length > 0)) {


17


18 throw new IllegalArgumentException("checkServerTrusted: X509Certificate is empty");


19


20 }


21


22 if (!(null != authType && authType.equalsIgnoreCase("RSA"))) {


23


24 throw new CertificateException("checkServerTrusted: AuthType is not RSA");


25


26 }


27


28 // Perform customary SSL/TLS checks


29


30 try {


31


32 TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509");


33


34 tmf.init((KeyStore) null);


35


36 for (TrustManager trustManager : tmf.getTrustManagers()) {


37


38 ((X509TrustManager) trustManager).checkServerTrusted(chain, authType);


39


40 }


41


42 } catch (Exception e) {


43


44 throw new CertificateException(e);


45


46 }


47


48 // Hack ahead: BigInteger and toString(). We know a DER encoded Public Key begins


49


50 // with 0×30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0×00 to drop.


51


52 RSAPublicKey pubkey = (RSAPublicKey) chain【0】.getPublicKey();


53


54 String encoded = new BigInteger(1 / positive /, pubkey.getEncoded()).toString(16);


55


56 // Pin it!


57


58 final boolean expected = PUB_KEY.equalsIgnoreCase(encoded);


59


60 if (!expected) {


61


62 throw new CertificateException("checkServerTrusted: Expected public key: " + PUB_KEY + ", got public key:" + encoded);


63


64 }


65


66 }


67


68 }


2 证书锁定:


即为客户端颁发公钥证书存放在手机客户端中(使用keystore),在https通信时,在客户端代码中固定去取证书信息,不是从服务端中获取。

相关文章
|
2月前
|
设计模式 算法 前端开发
Android面经分享,失业两个月,五一节前拿到Offer,设计思想与代码质量优化+程序性能优化+开发效率优化
Android面经分享,失业两个月,五一节前拿到Offer,设计思想与代码质量优化+程序性能优化+开发效率优化
|
27天前
|
安全 Java Android开发
05. 【Android教程】Android 程序签名打包
05. 【Android教程】Android 程序签名打包
18 1
|
3天前
|
Java Android开发
程序与技术分享:Android使用Dagger注入的方式初始化对象的简单使用
程序与技术分享:Android使用Dagger注入的方式初始化对象的简单使用
|
5天前
|
存储 安全 算法
Java中的加密与解密:实现安全的数据传输
Java中的加密与解密:实现安全的数据传输
|
2月前
|
SQL 分布式计算 监控
在数据传输服务(DTS)中,要查看每个小时源端产生了多少条数据
【2月更文挑战第32天】在数据传输服务(DTS)中,要查看每个小时源端产生了多少条数据
29 6
|
2月前
|
存储 SQL NoSQL
数据传输DTS同步问题之同步失败如何解决
数据传输服务(DTS)是一项专注于数据迁移和同步的云服务,在使用过程中可能遇到多种问题,本合集精选常见的DTS数据传输问题及其答疑解惑,以助用户顺利实现数据流转。
|
2月前
|
Cloud Native NoSQL 关系型数据库
数据传输DTS校验问题之校验报错如何解决
数据传输服务(DTS)是一项专注于数据迁移和同步的云服务,在使用过程中可能遇到多种问题,本合集精选常见的DTS数据传输问题及其答疑解惑,以助用户顺利实现数据流转。
|
2月前
DTS数据传输延迟可能有多种原因
【1月更文挑战第16天】【1月更文挑战第79篇】DTS数据传输延迟可能有多种原因
86 2
|
2月前
|
NoSQL Redis 数据库
数据传输DTS中金融云跨账号同步Redis,增量校验报错了
【1月更文挑战第16天】【1月更文挑战第80篇】数据传输DTS中金融云跨账号同步Redis,增量校验报错了
77 1
|
2天前
|
关系型数据库 MySQL 分布式数据库
PolarDB操作报错合集之当使用DTS(数据传输服务)同步的表在目标库中进行LEFT JOIN查询时遇到异常,是什么导致的
在使用阿里云的PolarDB(包括PolarDB-X)时,用户可能会遇到各种操作报错。下面汇总了一些常见的报错情况及其可能的原因和解决办法:1.安装PolarDB-X报错、2.PolarDB安装后无法连接、3.PolarDB-X 使用rpm安装启动卡顿、4.PolarDB执行UPDATE/INSERT报错、5.DDL操作提示“Lock conflict”、6.数据集成时联通PolarDB报错、7.编译DN报错(RockyLinux)、8.CheckStorage报错(源数据库实例被删除)、9.嵌套事务错误(TDDL-4604)。