Android APP常见风险及防护_android app安全防护

https://www.52pojie.cn/thread-1613856-1-1.html

        随着车联网智能化和网联化进程的不断推进，移动APP以及远程控制已经成为智能网联汽车的标配，实现远程开启空调、门锁，远程启动车辆等功能。然而，移动APP因其广泛应用及易于获取等特点成为黑客攻击的热点。移动APP作为与汽车交互的主要入口之一，如果移动APP出现安全漏洞，将会给汽车造成难以估量的安全威胁，严重危及用户的生命财产安全，必须高度重视可能随之而来的信息安全风险，提高防御网络攻击的能力。通过对智能网联汽车移动APP安全风险点进行梳理，发现移动APP主要面临来自客户端安全、数据安全、业务安全、通信安全等几个方面的安全威胁，根据风险点设计车联网APP安全防护可行性方案。

客户端安全：
1、签名校验
Android签名机制是对APK包完整性和发布机构唯一性的一种校验机制。Android系统在安装APK的过程中，需要对APK进行签名后才能后进行安装。大部分的Android APP没有对正盗版进行校验，重新签名后的APP在手机中安装后可以正常运行，这使APP面临被他人反编译、恶意篡改、二次打包的风险。
防护：
方法1：Java层代码校验
在程序入口处添加签名验证，通过调用系统函数获取APP软件发布时的签名信息，在代码中判断签名的MD5值，来检查APP是否被篡改过。如果在应用启动时获取应用的签名值与正确的签名值不同，说明APP被篡改过，就直接让APP中止运行。
方法2：nativie层代码校验
通过反射方法（native层通过反射调用JAVA层代码）获取APP签名信息，在应用启动时获取应用签名信息的MD5值和发布时签名信息MD5值做对比，如果不一致，则说明APP被篡改过，使APP立即退出程序。
2、未检测安全环境
（1）ROOT环境
APP在ROOT环境下运行可以随意访问任意应用储存的任何数据，造成数据泄露、数据非法篡改等风险。
（2）模拟器环境
模拟器具有经济成本低、高度可定制、易于开发、容易部署等特点，攻击者通过自己修改定制特定的模拟器来达到监控应用关键函数、获取应用敏感数据， 破解应用的目的
（3）Hook环境
Xposed/Substrate是常见的hook框架，黑客可使用hook手段对apk进行 脱壳、内存截取/修改等操作。
（4）代理环境
APP应用运行在代理环境下，通信过程能被中间人截获，造成用户请求伪造、重放攻击、敏感信息泄露等威胁。
防护：
1、在Root环境中运行APP，可能造成APP隐私数据被泄露，病毒侵入、系统运行不稳定等风险。
为了保证APP运行环境的安全性，在Java代码层中加入root环境检测代码，检测特征目录/system/bin/，/system/xbin/，/system/sbin/中是否写入su程序，如果写入了su程序，则APP及时退出程序或者弹出相应的提示框。
2、模拟器具有经济成本低、高度可定制、易于开发、容易部署等特点，攻击者通过自己修改定制特定的模拟器来达到监控应用关键函数、获取应用敏感数据，破解应用的目的。
为了保证APP运行环境的安全性，在Java代码层加入反模拟器运行代码，例如对ro.product.model、ro.kernel.qemu等属性值进行比对，如果判断APP是运行在模拟器中，及时退出程序。
3、Xposed/Substrate是市场上比较常见的hook框架，攻击者经常使用hook手段对apk进行脱壳，内存截取/修改、逻辑分析等操作。
为了保证APP运行环境的安全性，在Java代码中添加Hook工具的检测代码，当发现存在hook框架应用，APP应用停止运行，或者弹出提示框给与用户安全提示。
4、APP应用运行在代理环境下，通信过程能被中间人截获，造成用户请求伪造、重放攻击、敏感信息泄露等威胁。
3、配置安全
（1）allowbackup备份风险
使用apktool对APP客户端进行解包后，AndroidMainfest.xml 文件中的 allowBackup 属性值如果没有显式设置为 false 时，攻击者可通过 adb backup 和 adb restore 对 App 的应用数据进行备份和恢复，从而可能获取明文存储的用户敏感信息。
（2）Debug属性安全
使用apktool对APP客户端进行解包后， AndroidManifest.xml 中的 android:debuggable="true"标记如果开启，可被Java 调试工具例如 jdb 进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑。
（3）组件安全
使用apktool对app进行解包后，应用配置文件AndroidManifest.xml中，AndroidActivity/Broadcast Receiver/Service/Content Provider组件未按照“最小特权原则”进行设计，存在多余的android:export 声明，组件存在越权访问、信息泄露、拒绝服务等安全隐患。
防护：
1、在开发阶段时，在主配文件 AndroidManifest.xml 中，将allowBackup的属性值设置为false。
2、在开发阶段时，在主配文件 AndroidManifest.xml 中，一定要注意去掉 debuggable 属性，或设置为 false。
3、在开发阶段时，在主配文件AndroidManifest.xml中，不需要与外界进行数据交换的组件的 exported 属性要设置为 false。
4、代码安全
（1）反编译风险：使用Jeb、AndroidKiller对app进行反编译，反编译出的Java代码未做任何保护，致使客户端内几乎所有的逻辑流程都被暴露，使得攻击者能够完整地分析 APP 的运行逻辑，尤其是相关业务接口协议、和通信加密的实现，给主要的业务带来极大的风险。
（2）二次打包风险：
使用apktool对app进行解包，添加自定义的代码，回编译后，将APP重新安装到手机中可以正常运行。app被轻易的二次打包，很容易被攻击者添加恶意的代码或者添加广告，从而窃取登录账号密码、支付密码等，严重威胁用户隐私安全，也给公司的形象带来不利的影响。
   （3）so文件风险
Android中虽然So层安全性比Java层高，但可以通过破解工具来进行破解，如果so文件中代码明文显示，未经过任何保护，攻击者可以使用ida/gdb等调试工具对其动态调试，分析代码中的业务逻辑以及加密算法。
二进制字符串表未混淆的话，通过对字符串表进行分析，如果包含硬编码的连接字符串，包含到后端数据库的身份验证凭据，则存在风险。
（4）动态调试风险
移动应用在运行的过程中，攻击者通常会使用调试器对程序进行动态调试，如果移动应用未做防动态调试保护，则程序运行过程中，攻击者可以通过动态调试技术，利用gdb/ida等调试工具对程序进行内存调试跟踪，可以窃取目标进程的数据信息，从而获取用户的隐私数据信息。

（5）进程注入安全（待定）
如果程序本身对运行时的内存没有做任何的保护措施，攻击者通过反编译对源代码进行分析，定位到可以程序外 Hook 类似操作的关键位置，完全不需要修改程序本身，当程序运行到敏感的界面 Activity 时，从程序外获取用户输入的证件号、姓名、手机号和密码等敏感的信息，并从内存中进行修改，尤其是对于涉及到支付等操作时，将严重威胁用户的财产安全。
防护：
1、针对反编译风险，可以采用以下策略：
2、针对二次打包风险，可以采用以下策略：

• 
  程序运行时对应用包的 MD5 值进行合法性校验，发现盗版就异常退出；（进行完整性校验，程序运行时对apk包各个文件的MD5值进行合法性校验，发现盗版就异常退出。）
• 
  通过第三方加固或开发者自行对应用包的源代码进行隐藏，防止查看修改。
  

3、针对so文件风险，可以采用以下策略：

• 
  so文件加壳：对 C/C++源码编译出来的 so 文件进行加壳，隐藏so库外部函数，使加壳后的 so 文件无法通过 ida 反编译工具查看导出符号，使 so 文件无法正确反编译和反汇编。
• 
  so文件代码高级混淆
  

           a) 代码混淆：代码编译阶段，对so库文件进行代码的高级混淆，混淆后代码可读性大大降低。结合代码膨胀技术，使逆向人员无法进行代码分析。
           b) 代码膨胀：代码编译阶段，对so库文件进行代码逻辑膨胀。膨胀后，无法对代码逻辑进行跟踪分析。
           c) 字符串加密：对so库代码中存在的所有字符串类型数据进行加密处理，防止逆向人员通过字符串对代码进行定位分析。

4、针对动态调试风险，采用以下策略：

• 
  在代码中加入防动态调试代码，对主进程进行监控，防止第三方动态调试、附着APP进程，当APP处于被调试状态时，及时退出程序。
  

5、针对进程注入风险，采用以下策略：

• 
  由于程序内存的防护单纯从开发者的角度来防护难度比较大，所以建议使用靠谱的第三方加固厂商对 APP 进行加壳，从而防止内存数据的泄露
  

数据安全
1、不安全的数据存储
对于Android的每一个应用，Android系统会分配一个一个私有目录，用于存储应用的私有数据。此私有目录他通常位于“/data/data/应用名称/”，在root环境下，攻击者可以对该目录下的文件进行非法访问。
（1）SharePreferences数据明文储存
SharedPreferences存储方式是Android中存储轻量级数据的一种方式,内部以Map方式进行存储，保存的数据以xml格式存放在本地的/data/data/(packagename)/shared_prefs文件夹下。SharedPreference<key,value>value支持Java的基本操作类型，如Boolean、Int，Float等，文件轻量级数据要求保存数据value大小不能太大，数据太大会给系统GC、内存带来压力，甚至造成Activity程序卡顿。
SharePreferences目录下文件，如果明文存储用户登录密码、手机号等敏感信息，将有可能被攻击者非法利用。
（2）SQLite数据明文储存
SQLite 数据库文件，如果明文存储车辆VIN、安全码、车辆所有者等敏感信息，则存在信息泄露、资源被利用的风险。
【注】：android系统框架图，有一层是系统库层。在system/lib下存在一些android系统自带的系统库，比方说sqlite，可以直接使用这个自带的系统库来存储数据。
2、Logcat日志
        移动应用在运行的过程中，通过adb或者monitor查看实时打印日志，如果日志的输出没有做好等级控制，则存在用户名、密码等敏感信息泄露的风险。
3、密钥存储安全
密钥安全：避免硬编码密钥在代码中，可以本地分段加密存储，也考虑使用白盒密钥；
防护：
1、针对不安全的数据存储风险
在移动应用使用的过程中，客户端会存储相关的用户数据，为了防止攻击者通过root环境非法访问用户敏感数据。可以使用以下安全策略：
a)、对用户名、密码等敏感信息，不要存储在本地。
b)、如果确实需要存储，使用强加密算法对本地存储的数据进行加密处理。

【注】：采用加密的方式保护应用程序敏感数据，如利用SQLCipher加密SQLite数据库； 数据的安全性不应该依赖于算法的保密性，而是确保加密密钥的安全，只要我们的密钥位数足够长，密钥不被泄露，那我们加密的数据就是安全的。
2、针对Logcat日志风险
日志不要打印任何敏感信息、协议逻辑等，并且在程序发布时，一定要将日志的输出删
除掉，而不是仅仅的做输出控制。
通信安全
1、不安全的通信
移动APP与服务器进行交互时，使用不安全的HTTP协议，对数据进行明文传输，攻击者将有机会对当前网络环境中其他合法用户的通信内容进行窃听甚至篡改，进而影响数据的安全性。
2、未对通信双方身份进行鉴别（不安全的身份验证）
移动APP与服务器进行交互时，互相不验证证书，手机设置代理，使用Burpsuite等抓包工具可以捕获APP所有请求，造成中间人攻击、通信数据被泄露的风险。
3、未加密或加密不足
在数据传输的过程中，关键数据明文传输，未进行加密处理，存在被中间人攻击或嗅探的风险。如果使用弱加密算法对数据进行加密处理，存在被破解，造成数据泄露的风险。
防护：
（1）安全通信
移动端与云端通信时使用HTTPS安全协议，使用SSL/TLS加密算法实现数据的加密传输，保证数据传输过程的安全性，防止通信链路被监听、防止数据被窃取。
（2）证书校验机制
APP在进行网络传输时使用HTTPS安全协议，保证了通信链路的安全性，但是无法防止中间人攻击，手机设置代理，通过burpsuite抓包工具可以轻易的获取到通信数据信息。
为了防止传输过程中的数据被泄露，在Java代码中添加对通信链路中SSL证书合法性的校验的代码，例如：代码中可以实现X509TrustManager接口的checkServerTrusted方法，将服务器证书与客户端预存服务器端证书做对比，来完成客户端对服务器证书的强校验。此外，
服务器通过白名单方式验证客户端证书，实现客户端和服务器证书的双向验证。
业务安全
1、身份鉴别安全
（1）任意用户登录风险
当前移动应用大部分提供两种登录方式，一种是手机号+验证码，一种是手机号+登录密码。当使用手机号+验证码的方式进行登录时，如果没有对发送验证码手机号和下发验证码手机号一致性进行校验，则存在登录其他用户，造成其用户信息泄露的风险；当使用手机号+登录密码进行登录时，如果没有对手机号和登录密码的一致性进行校验，则可以存在同样的风险。
（2）用户名注册状态泄露
手机中安装移动应用登录时，当用户名、密码错误，用户名不存在时，弹出明确提示，泄露用户的注册状态。
（3）弱密码风险
在注册、修改密码时，如果可以设置像长度小于6位的纯数字，例如：123456，888888等，则存在被暴力破解风险。
（4）账户登录限制
用户在登录时，如果密码输入错误次数没有做任何的限制，则存在密码被暴力破解的风险。
（5）登录密码爆破风险
移动应用在登录时，如果没有对登录错误次数、请求时间进行校验，同时密码等敏感数据未进行加密处理，可以通过burpsuite等抓包工具，对登录请求数据包进行抓取，存在使用穷举法对密码进行暴力破解的风险。
（6）账号注销安全
如果APP退出登录后，没有向服务器端发送终止会话请求。注销成功后，cookie仍然可以使用，则存在信息泄露等风险。
防护：
1、针对任意用户登录风险
在开发的过程中，在登录代码要对发送验证码手机号和下发验证码手机号一致性进行校验，要对手机号和登录密码的一致性进行校验。2、针对用户名注册状态泄露风险
在登录时，当用户输错用户名或者密码采取模糊提示语，如：“您输入的账号或者密码错误”。
3、针对弱密码风险
代码中设置安全策略（密码使用数字和字母组成，至少为8位），当设置为弱秘钥时，弹出提示框：密码过于简单，请重新设置！
4、针对账户登录限制
代码中对登录时账号密码的错误次数做限制。
5、针对登录密码爆破风险

• 
  代码中对登录时账号密码的错误次数做限制。如在同一用户尝试登录的情况下，5 分钟内连续登录失败超过6次，则禁止此用户在3小时内登录系统。
• 
  加入图片验证码机制，登录失败一次，验证码变换一次。
• 
  对密码等敏感数据使用强加密算法进行加密处理。
  

6、针对账号注销安全
添加注销token的接口，在用户从客户端注销的时候，同时也从服务端让该token失效。
【注】：现在越来越多App取消了密码登录，而采用手机号+短信验证码的登录方式，采用这种登录方式有几种好处：

• 不需要注册，不需要修改密码，也不需要因为忘记密码而重置密码的操作了；
• 用户不再需要记住密码了，也不怕密码泄露的问题了；
• 相对于密码登录其安全性明显提高了。
  

2、验证码机制安全

（1）验证码爆破风险（短信轰炸）
用户使用手机号+验证码的方式进行登录时，短信验证码大部分情况下是由4～6位数字组成，如果没有对验证码的失效时间和尝试失败的次数做限制，攻击者就可以通过尝试这个区间内的所有数字来进行暴力破解攻击。
（2）验证码泄露风险
移动应用在执行【找回密码】操作时，输入手机号，获取验证码，服务器会向手机发送验证码，通过burpsuite抓包工具，查看返回的响应数据包中如果包含验证码，则可能导致用户密码恶意重置、绑定手机号被恶意更换等风险。
（3）验证码无限发送风险
移动应用在执行【获取验证码】相关操作时，如果没有对验证码的发送次数进行限制，可以对同一手机号或者不同手机号无限次发送，则可能给开发商的经济造成一定的损失，短信接收方受到骚扰，影响开发商形象。
      连续调用短信接口多次对不同手机号发送短信成功，存在恶意调用接口发送短信的风险，造成短信发送平台花费大量的短信费用，且易造成骚扰短信，影响用户的正常生活。
（4）万能验证码
万能密码的话主要是开发在业务未上线的时候为了方便测试用的,上线后忘记删除了,例如 8888 0000 1234等等 都可以去尝试
（5） 修改返回包绕过验证码找回密码
有些开发在返回包里设置一个参数，这个参数用于传递给前台以决定我们是否可以进入下一步。但我们可以通过拦截返回包修改里面的值欺骗前端绕过验证码,如false改成true error 1改为0，可以使用自己的账号走一遍流程记录下来正确的状态码然后替换做尝试。
修复建议:不要在前端利用服务端返回的值判断是否可以修改密码 要把整个效验环节交给服务端；
防护：
1、针对验证码爆破风险

• 
  设置验证码的失效时间，建议为180秒；
• 
  限制单位时间内验证码的失败尝试次数，如5分钟内连续失败5次即锁定该账号
  

15分钟。
2、验证码泄露风险

• 
  禁止验证码在本地客户端生成，应采用服务器端验证码生成机制；
• 
  设置验证码的时效性，如180秒过期；
• 
  验证码应随机生成，且使用一次即失效。
  

3、针对验证码无限发送风险

• 
  对同一手机号/不同手机号发送验证码的次数做校验；
• 
  在发送短信验证码时，使用图形滑动验证码进行校验。
  

3、支付机制安全
（1）支付密码爆破风险
目前大部分的车联网APP都具有支付功能，可以购买流量包、畅听包，如果没有对支付密码错误次数进行限制、支付密码等敏感数据未进行加密处理，则可以通过burpsuite等抓包工具，对支付请求数据包进行抓取，存在使用穷举法对支付密码进行暴力破解的风险。
（2）交易篡改风险
在操作支付功能时，如果服务器端未对用户提交的业务数据，例如商品支付金额、商品订购数量进行强制有效性校验，过度信赖客户端提交的业务数据，容易造成交易篡改风险。
（3）支付数据包重放风险
在操作支付功能时，如果完成一次购买操作，使用burpsuite抓取购买成功后的请求数据包，可以进行重放攻击，仍然可以支付成功。则给用户造成经济损失。
防护：
1、支付密码爆破风险

• 
  代码中对登录时账号密码的错误次数做限制。如在同一用户尝试登录的情况下，5 分钟内连续登录失败超过6次，则禁止此用户在3小时内登录系统。
• 
  加入图片验证码机制，登录失败一次，验证码变换一次。
  

2、交易篡改风险

• 
  对传输的数据进行加密处理，并加入 signature 等校验完整性参数，防止数据被篡改。数据的接收者可以通过验证数字签名来鉴别数据的来源和完整性，数字签名还可以保护数据不被篡改、伪造，保证数据的不可否认性。
• 
  商品信息，如金额、数量等原始数据的校验应来自于服务器端，例如：服务端在收到请求后必须检查商品价格和交易金额是否一致，若不一致则阻止该交易。
  

3、支付数据包重放风险
加入时间戳，服务器请求的一次性随机参数等，并对对应的参数进行校验，防止支付的数据包被重复利用。
4、越权检测
（1）水平/垂直越权
移动应用运行的过程中，执行查看个人信息操作，使用burpsuite抓包工具对该请求进行抓包，使用字典对账户身份ID进行暴力破解，可以查看其它用户的个人信息，造成信息泄露风险。
（2）任意文件/图片上传
如果移动应用具有上传功能，执行上传文件的时候，如果服务器对用户文件上传部分的控制不足或者处理缺陷，导致用户可以越过其本身权限向服务器上传可执行的动态脚本文件，就容易造成任意文件上传。例如：攻击者利用该漏洞可以直接向服务器上传ASP 木马、PHP 木马等，从而控制TSP服务器，造成重要数据的丢失。
防护：
1、针对水平/垂直越权
进行身份认证，验证身份的唯一性，在请求中添加token值，服务器端随机生成。
2、任意文件/图片上传

• 
  检查上传文件扩展名白名单，不属于白名单内，不允许上传；
• 
  设置权限限制，禁止上传目录的执行权限；
• 
  隐藏上传文件路径。
  

5、通用型Web漏洞检测
（1）SQL注入漏洞
在使用登录、查询等功能时，如果程序在编写时没有对用户提交至服务器的数据的合法性进行校验，可以将SQL命令插入到Web表单进行提交，从而达到欺骗服务器执行恶意SQL命令的目的，实现对数据的任意读写，造成核心机密数据被窃取和篡改的安全风险。
（2）XSS漏洞
在使用投诉、建议等功能时，如果在程序编写时没有对用户输入数据的合法性以及在将数据输出到网页时数据的合法性进行校验，攻击者可以向Web页面里面插入恶意JavaScript、HTML代码，并且将构造的恶意数据显示在页面，从而泄露客户端的cookie或者其他敏感信息。
（3）汽车控制指令重放
【注】：控车指令应按照重要程度进行等级划分，并在操作执行前采取不同的安全认证方式，如闪灯等没有进入到车内的操作采用口令认证，开锁等重要性较高操作采用双因子认证。应对控车指令内容采用安全的算法进行加密，应使用已经被充分验证过的加密算法，如SM4、AES256。同时，应对远程控车逻辑进行安全限制，远程控制的优先级低于本地控制。（参考标准，YD/T3737-2020《基于公众电信网的联网汽车的安全技术要求》）
防护：
1、针对SQL注入漏洞
对用户输入数据进行严格过滤。每个提交信息的客户端页面、、提交的表单（FORM）或发出的链接请求中包含的所有变量，必须对变量的值进行检查，过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符如下。
· SQL语句关键词：如and、or、select、declare、update；
· SQL语句特殊符号：’、”等。
使用预编译语句，不要将变量动态拼接到sql语句中，而是使用占位符进行数据库的增加、删除、修改、查询，这样可以有效地防御SQL注入。
2、针对XSS漏洞

• 
  使用黑名单限制，对输入数据中的特殊符号进行过滤和转义，如尖括号（<、>）、斜
  

杠（/）、半角圆括号（（、））、半角引号（”）、半角单引号（’）、等号（=）、半角空格等；

• 
  服务器端对输出到页面的数据进行编码转换，包括HTML代码、JavaScript代码等。