M3-不安全的通信
- 直接参考挂官网
实践
- 最简单的一种就是拦截app请求,然后对接口进行篡改
- 没有进行实际的实践,把一些不错的文章记录下
- 这文章有一些详细的实践说明,可以参考下,我大概总结如何避免:
使用https
1 | URL url = new URL("https://example.com"); |
更新加密包
- 一些敏感重要的东西,在使用第三方提供的加密服务时,需要时常关注是否有漏洞,以及版本信息
1 | implementation 'com.google.android.gms:play-services-safetynet:15.0.1' |
证书和公钥的锁定
如何CertificatePinning
1.首先服务器端使用RSA算法生成一对公钥私钥对,服务器端持有私钥,线下将公钥传给客户端。App中将这个值硬编码到本地。
2.App端可以自己实现一个X509TrustManager接口,在其中的CheckServerTrusted()方法里通过证书链拿到PublicKey,
3.比较1和2中进行md5的值,如果匹配则服务器验证通过,否则立即终止与此服务器的通信
更多介绍来自这里
异常过滤和验证
就是常见的一些异常验证和过滤,比如正则、特殊字符过滤等,下面就是典型的异常验证
1 | if (editText.getText().toString().length() <= 48) |
和其他App通信
和其他app通信时,有些情况下,开发人员留下了共享文件或实现了套接字来交换敏感信息,建议使用Intents
端到端加密
一个很好的例子是一个加密聊天应用程序,其中两个移动设备通过服务器相互通信;只有发送者和接收者才能阅读对方的信息。
M4-不安全的身份验证
糟糕的身份验证方案允许攻击者在移动应用或该应用使用的服务器上匿名执行任何用户操作。由于移动设备的输入形式因素,弱应用认证是一个非常常见的问题
app在和服务器通信时,可以拦截请求,对这些请求进行参数篡改,这里就懒得验证了,有兴趣的可以自行操作
M5-弱加密
加密容易被破解
- 常见类型:
- 内置代码加密
- 硬编码密钥
- 不安全或过时的算法(
RC2/MD4/MD5/SHA1
)
M6 - 不安全的授权
M4-不安全的身份验证
风险通常与M6混淆,因为两者都与用户凭据有关。M6是关于使用授权以合法用户身份登录。M4是攻击者试图以匿名用户身份登录以绕过身份验证过程的情况,通常由如下问题:
- 不安全的应用程序权限设置
- 冗余授予的权限
- 存在不安全的直接对象引用(IDOR)漏洞
测试方法
来自这里
使用的
Android Killer
,因为这个工具会把权限这块明显的列出来
- 上面标色的权限部分,根据业务需要分别check一下,看一下是不是真的是必须的。
- 冗余授权也可以在这边找到,但也可以用另外一个工具
drozer
查看
- 抓包
M7-客户端代码质量
M7的风险源于糟糕或不一致的编码实践,即开发团队的每个成员都遵循不同的编码实践,并在最终代码中造成不一致。
M7对应用程序安全没有威胁。尽管患病率很高,但这一风险区域很难发现。对于黑客来说,了解糟糕编码的模式并不容易。这个过程通常需要复杂的人工分析。
在获得源码情况下,可以参考这里的测试方法
M8 -代码篡改
测试点:
- 修改代码
- 修改资源
- 修改API
具体测试方法参考这里
M10-无关功能
测试点:
- 开发人员包括隐藏的后门功能或其他不打算发布到生产环境中的内部开发安全控件
- URL 修改
- 应用程序可以在被 root 或越狱手机中使用
- Back-and-Refresh 攻击
- 应用程序中包含过时的文件
- 没有显示最近登录信息
- 到期后或释放的资源操作
- ASLR没有被使用
- 剪切板未禁用
- 缓存粉碎未激活
- Android备份检查
- 未实行可信任发布
- 允许所有 Hostname Verifier
- 弱自定义 Hostname Verifier
测试方法来源这里
其他
- 安全测试思维导图