APP安全测评

转载自http://www.cnblogs.com/permanent2012moira/p/5271495.html
仅作学习之用

APP安全测评checklist

    

leader不要打我啊,我要借用一下我组app的安全测评检查方案,这些最基本的安全防范措施应该是每个app都要注意的吧:

对了,首先,你的app得先混淆啊~:AndroidStudio 混淆打包

先来个checklist:

编号

检查项目

测评结果

1

明文传输用户名、密码和验证码等敏感信息。

 

2

不安全的本地存储。

 

3

泄漏后台服务器地址,导致服务器可控

 

4

边信道信息泄漏

 

5

未使用有效的token机制,导致可以绕过鉴权

 

6

传输数据可修改,造成越权访问

 

7

登录设计缺陷,存在被暴力破解风险

 

8

利用业务逻辑缺陷制作短信炸弹

 

9

关键页面存在钓鱼劫持风险,导致用户信息泄露

 

10

可以重新编译打包

 

11

WebView漏洞

 

12

Web表单设计缺陷,存在SQL注入漏洞

 

13

组件Content Provider配置错误,导致数据泄漏

 

14

组件Activity配置错误,导致登录页面被绕过

 

15

组件Service配置错误,导致非法权限提升

 

16

组件Broadcast Receiver配置错误,导致拒绝服务、非法越权

 

17

开启allowbackup备份权限,存在备份数据泄露风险

 

18

开启Debuggable属性,存在应用信息篡改泄露风险

 

19

下载非官方开发工具,导致IOS版本APP被植入恶意代码

 

20

开发者证书不规范,导致开发者身份信息不明

 

具体的解释:

1、明文传输用户名、密码和验证码等敏感信息

问题描述:用户登录过程中,在与服务器端交互时明文传输用户名、密码或者验证码等,可导致用户敏感信息泄露。

检测结果:手机连接Fiddler代理,在Fiddler代理中抓包测试。APP登录操作: 账号、登录凭证不安全传输。

密码虽然是MD5散列后的数值,但是传输使用的是http协议,存在被嗅探窃取的可能性,一旦泄漏,黑客能够直接通过该用户名和Password登录。

整改建议:登录凭证信息需加密传输,建议使用自定义加密协议或使用https方式传输。

2、 不安全本地存储

问题描述:安卓开发者使用多种方法将数据存储在安卓应用中,而存储在本地的数据文件如果未加密,易造成敏感信息泄漏。

检测结果:Shared Preferences用户名和登录凭证明文存储在healthConfig.xml文件中。

SQLite 未发现敏感数据存储

SD卡敏感数据存储 未发现数据写入。

整改建议:对存储在本地的敏感数据进行加密。

3、泄漏后台服务器地址,导致服务器可控

问题描述:在使用BurpSuite等工具对应用进行监听的过程中,发现后台服务器地址。对后台服务器进行测试,若后台服务器存在漏洞,则可控制后台服务器。

检测结果:后台服务器地址为**********,未发现可导致服务器可控的安全漏洞。

4、边信道信息泄漏

问题描述:当APP处理用户或其它数据源输入的数据时,可能会把数据放在不安全的位置,容易导致边信道被攻击者利用造成信息泄露。

检查结果:用户登录凭证、设备ID等敏感数据出现在log中。

整改建议:对logcat的打印数据进行过滤,敏感数据不能出现在log中。

5、未使用有效的token机制,导致可以绕过鉴权

问题描述:如果被测应用没有使用有效的token机制,对登陆响应中的服务器返回的鉴权信息进行修改,即可绕过服务器鉴权,直接访问系统内部信息。

检测结果:从代理抓包分析,APP登录是会将一个deviceid和用户凭证一起提交,用户登录成功后,该deviceid将作为后续接口调用的凭证,即Token。

经查,该deviceid为设备中某些公开信息(IMEI、设备型号、操作系统版本等)的Base64编码结果,不具备隐私性,黑客可以通过获取这些公开信息伪造用户身份。

整改建议:在deviceid中加入随机数据。

6、传输数据可修改,造成越权访问

问题描述:利用已有的用户名密码登录应用,当应用访问某一模块时,使用BurpSuite等代理工具进行监听,对访问该模块时的关键信息进行替换,则可越权访问他人的应用模块。

检测结果:同第5条。

7、登录设计缺陷,存在被暴力破解风险

问题描述:用户登录过程中,未对同一用户的登录失败次数做限制,导致存在被暴力破解的风险。

问题详情:对登录接口进行暴力破解,错误50次后,输入正确用户名和密码仍然成功登录,表明没有对登录接口做暴力破解防护。

整改建议:限制账号登录错误次数,超过阀值时需要提供验证码机制。

8、利用业务逻辑缺陷制作短信炸弹

问题描述:如果在用户注册过程中存在逻辑设计缺陷,可对指定手机号码随意发送短信,造成短信炸弹攻击,可能造成用户投诉或恶意软件传播等。

测试结果:用户选择注册或忘记密码功能时,会触发短信验证码发送,多次调用验证码发送接口,每分钟能收到多条短消息,且没有发现总量限制。

整改建议:如果已经限制了每个用户每分钟的短信条数(如果没有限制,请做限制处理),建议进一步限制每个用户每天的短信条数。

9、关键页面存在钓鱼劫持风险,导致用户信息泄露

问题描述:劫持钓鱼,指恶意应用针对正常应用的特定界面进行仿冒替换,诱骗用户在仿冒界面操作,达到钓鱼目的。此类攻击,多针对APP的鉴权或支付场景,诱骗用户输入关键隐私信息,如账号、登陆密码和支付密码等,达到隐私窃取的目的。

检测结果:恶意应用可以通过监测进程机制实现对APP的劫持,当APP启动时,弹出伪造的登录Activity,实现钓鱼劫持。

整改建议:

  1. 建议在登录Activity的onpause方法中实现钓鱼劫持防护功能,如提示用户当前登录也已切换等。
  2. 使用HTML5架构或android+HTML5混合开发,实现登陆、支付等关键页面,降低被劫持的风险。

10、可以重新编译打包

问题描述:破解者通过反编译后得到程序源代码,修改后重新编译、签名并安装。在重新打包的过程中,破解者可能注入恶意代码,或者修改软件逻辑绕过鉴权等。

检测结果:通过反编译工具对APP进行反编译后,修改部分源代码后,可以重新打包安装,并成功安装在手机中运行。

整改建议:通过检查程序安装后classes.dex文件的Hash值,判断软件是否被重打包并进行提示。(这个具体使用时判断了打包keystore的SHA1值,不过前提是这个jks文件没被劫持啊)

11、WebView漏洞

问题描述:在WebView下有一个非常特殊的接口函数addJavascriptInterface,能实现本地java和js的交互。被测应用中存在WebView漏洞,没有对注册JAVA类的方法调用进行限制,导致攻击者利用addJavascriptInterface这个接口函数穿透webkit控制android本机。

检测结果:通过反编译源码发现BrowserActivity中存在WebView组件,并使用了addJavascriptInterface接口,但是对该接口使用@JavascriptInterface进行了保护,无需整改。(说实话这个不太熟悉)

12、Web表单设计缺陷,存在SQL注入漏洞

问题描述:开发过程中未对特殊字符进行过滤,攻击者可以通过把SQL命令插入到Web表单提交或者输入域名或者页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令的目的,这样攻击者就能够对内部数据库进行增删改操作。

检测结果:未发现SQL注入漏洞

13、组件Content Provider配置错误,导致数据泄漏

问题描述: Content Provider是安卓应用组件,以表格的形式把数据展现给外部的应用。每个Content Provider都对应一个以”content://”开头的特定URI,任何应用都可以通过这个URI操作Content Provider 应用的数据库。如果应用对权限控制不当就会造成信息泄露。

检测结果:使用drozer工具检测,未发现可被非法访问的URI。

14、组件Activity配置错误,导致登录页面被绕过

问题描述:Activity是安卓应用组件,提供与用户进行交互的界面。如果应用对权限控制不当,可以绕过登录界面直接显示该界面。

检测结果:使用drozer工具检测,发现多个可被外部应用直接调用的Activity组件,其中有的Activity可以跳过登录直接启动,存在安全风险。

整改建议:对风险Activity显式设置android:exported=false权限。

命令:dz> run app.activity.info -a    

15、组件Service配置错误,导致非法权限提升

问题描述:Service是Android中四大组件进行后台作业的主要组件,如果被测应用对权限控制不当,导致其他应用可以启动被测应用的Service。

检查结果:使用drozer工具检测,发现可被外部应用直接调用的Service组件,但未发现非法调用风险。

整改建议:请自确认暴露出来的两个Service是否存在非法调用风险,对风险Service显式设置android:exported=false权限。

命令:dz> run app.service.info -a  

16、组件Broadcast Receiver配置错误,导致拒绝服务、非法越权

问题描述:Broadcast Receiver是Android中四大组件用于处理广播事件的组件,若存在配置不当则其他应用可以伪装发送广播从而可造成信息泄露,拒绝服务攻击等。

检查结果:使用drozer工具检测,发现多个暴露的Broadcast组件,通过drozer发送这些自定义的Receiver对应的广播分别会造成系统弹框和程序奔溃,可能会被恶意应用利用,造成拒绝服务攻击。

整改建议:对外暴露的Broadcast组件显式设置android:exported=false权限。

命令:dz> run app.broadcast.send –component  

17、开启allowbackup备份权限,存在备份数据泄露风险

问题描述: 被测应用的AndroidManifest.xml文件中allowBackup属性值被设置为true,可通过adb backup对应用数据进行备份,在无root的情况下可以导出应用中存储的所有数据,造成用户数据泄露。

检测结果:反编译查看AndroidManifest.xml,发现allowBackup属性被设置为true

整改建议:如无特殊需求,将allowBackup设置为false

18、开启Debuggable属性,存在应用信息篡改泄露风险

问题描述:被测应用的AndroidManifest.xml文件中Debuggable属性值被设置为true,可以设置断点来控制程序的执行流程,在应用程序运行时修改其行为。

检测结果:未发现开启Debuggable属性

19、下载非官方开发工具,导致IOS版本APP被植入恶意代码

检查结果:此项仅针对IOS客户端。请项目组自检,确保开发工具为官方下载。

(Xcode后门事件影响不小啊)

20、开发者证书开发者证书不规范,导致开发者身份信息不明

问题描述: 被测应用的开发者证书不规范,导致被测应用的开发者身份信息不是与本公司相关的信息。

(这个在生成jks或者keystore的时候要填写公司或者个人合理的信息)

你可能感兴趣的:(#,Android-安全性)