sidazujian

可以看一下这些文章哦 https://www.freebuf.com/articles/web/165466.html
https://blog.csdn.net/nextdoor6/article/details/52211117

Activity组件：界面组件，通常用来展示一个可视化的用户界面。劫持攻击中就是测试这个界面

• 对于程序中的每一个界面都是一个Activity， 每一个Activity有不同的功能，比如登录、注册、 注册码验证、手势密码等，Activity之间的切换需 要满足一定的条件。
• 一个activity通常就是一个单独的屏幕，它在上面可以显示一些控件也可以监听并处理用户的事件作出响应。
• activity之间通过intent进行通信。intent是指意图。是组件之间通信的信息对象，用于启动组件和传输数据。
• intent分为显式意图和隐式意图。显式意图就比如说是点击一个按钮，跳转的另外的界面。隐式意图尝尝是用于计划其他应用程序的组件。

Activity组件测试

1. activity劫持
   • 打开Hijack_Activity，后台运行，再打开测试的app，查看是否弹出Hijack_Activity劫持
     安全的情况下，当在app打开另外的界面时，app应用需要提示用户应用在后台运行中

 
也可以使用测试命令：（使用命令的方式启动测试程序）
  1. 打开cmd
     adb shell
     su
     am start com.hijack_activity/.MyLogin

2. activity组件导出

• Activity组件可导出，则会造成Activity组件本地拒绝服务
• 漏洞描述：Activity 组件的属性 exported 被设置为 true 或是未设置 exported 值 但 IntentFilter 不为空时，activity 被认为是导出的，可通过设置相 应的 Intent 唤起 activity。黑客可能构造恶意数据针对导出 activity 组件实施越权攻击。
• 修复建议：组件安全。应合理设置APP组件的exported属性，防止APP自身不必要的组件暴露，对需要设置成导出的组件，对传入的Intent的参数做严格的检查和过滤。

测试方法：
1、adb forward tcp:31415 tcp:31415

2、drozer console connect

3、查看可导出的activity（run app.activity.info -a 包名）

4、开启新的cmd，进入adb 掉起activity（am start -n 包名/activity名），观察页面是否黑屏、闪退等其他异常

a. 查询四大组件的基本信息：

dz> run app.package.attacksurface com.cpic.jkfwglesit
Attack Surface:
  2 activities exported
  1 broadcast receivers exported
  0 content providers exported
  1 services exported

b. 查看activity组件

dz> run app.activity.info -a com.cpic.jkfwglesit
Package: com.cpic.jkfwglesit
  com.cpic.jkfwglesit.MainActivity
    Permission: null
  cn.jpush.android.ui.PushActivity
    Permission: null



c. 开启新的cmd，进入adb 掉起activity（am start -n 包名/activity名
C:\Users\syjiang>adb shell
shell@trltechn:/ $ am start -nncom.cpic.jkfwglesit/cn.jpush.android.ui.PushActivity
rt -n com.cpic.jkfwglesit/cn.jpush.android.ui.PushActivity                    <
Starting: Intent { cmp=com.cpic.jkfwglesit/cn.jpush.android.ui.PushActivity }


如果此时APP界面存在异常，则可导出。
这时候需要手机正在运行app.

• 自动化测试
  使用自动化测试，导出app的配置文件AndroidManifest.xml，可以通过查看配置文件来看。

  
  AndroidManifest.xml文件

• 我们主要介绍的是activity通过exported属性来对activity进行的安全控制。首先讲下默认情况，如果activity没有设置intent-filter，则exported默认的属性为false,就是这个组件仅仅能被自身内部程序调用。如果activity设置了intent-filter,则android:exported默认为true。这时如果我们对这个值进行控制就会导致一系列安全问题。所以组件安全也主要针对配置了意图过滤的组件。

• 这时我们把组件分为公有组件和私有组件，公有组件就是activity组件可以被外部程序调用，私有组件就是不能被其他程序启动或调用。因此在创建组件时，如果是私有的组件，android:exported属性一律设置为false.如果是公有的，就设置android:exported为true。不管公有的还是私有的组件，处理接收的intent时都应该进行验证的数据验证。公有组件防止信息泄露和接收外部数据时进行严格的处理。如果对私有组件没有进行相应的配置，可能导致组件被其他程序调用，敏感信息泄露，拒绝服务器攻击和权限绕过等漏洞。

• 其中. MainLoginActivity是app启动时的主界面，必须可以导出，但其他activity正常情况下是不能导出的

漏洞组件：

Service组件

• 无用户界面，但是它会在后台一直执行
• Service服务是伴随着程序启动，一直运行在后台，主要起检测作用的执行代码。服务一般用于时刻检测客户端的更新状态、时刻检测是否异地登录、时刻上传用户的操作信息
• 很多情况下，一些与用户很少需要产生交互的应用程序，我们一般让它们在后台运行就行了，而且在它们运行期间我们仍然能运行其他的应用。为了处理这种后台进程，Android引入了Service的概念。
  测试方法：

1、adb forward tcp:31415 tcp:31415

2、drozer console connect

3、run app.service.info -a 包名

4、am startservice -a INTENT -n 包名/组件名

还是主要看配置文件吧，还是不太懂四大组件的测试，好多是需要手动注入的，还需要再了解一下！

Broadcast组件

• 广播是当程序检测到外界的某种运行环境发生变化时，而执行的逻辑代码，比如程序的自启、网络变化变化、实时消息(打车软件)
• 在Android中，Broadcast是一种广泛运用的在应用程序之间传输信息的机制。而BroadcastReceiver是对发送出来的Broadcast进行过滤接受并响应的一类组件。广播接收者（BroadcastReceiver）用于接收广播Intent的, 广播Intent的发送是通过调用sendBroadcast/sendOrderedBroadcast来实现的。通常一个广播Intent可以被订阅了此Intent的多个广播接收者所接收
  测试方法：

1、adb forward tcp:31415 tcp:31415

2、drozer console connect

3、run app.broadcast.info -a 包名

4、进入adb shell

5、am  broadcast -a INTENT_ACTION -n 包名/actvivity名 //观察是否有闪退现象

6、找到INTENT_ACTION（1、java -jar AXMLPrinter2.jar  xml地址 > AndroidManifest.txt） //可以在文本中查看具体情况，是否设置了exportd属性为false


java -jar AXMLPrinter2.jar  C:\Users\LM\Desktop\AndroidManifest.xml > C:\Users\LM\Desktop\AndroidManifest.txt

ContentProvider组件

• ContentProvider用于保存和获取数据，并使其对所有应用程序可见。 这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。比如通讯录数据。
• 内容提供者是应用程序之间共享数据的接口，使用ContentProvider共享数据的好处是统一了数据访问方式。
  测试方法：

1、adb forward tcp:31415 tcp:31415

2、drozer console connect

3、run scanner.provider.finduris -a 包名

4、获取各个URI的数据（查询到数据说明存在漏洞）：run app.provider.query 

run app.provider.query [URI] –selection “1=1”

dz> SQL注入（报错则说明存在SQL注入）：run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* from sqlite_master wh ere 1=1; --"

检查是否存在遍历文件的漏洞
dz> run scanner.provider.injection -a com.mwr.example.sieve

dz> run scanner.provider.traversal -a com.mwr.example.sieve

还有一种，就是去看配置文件。是否为false

• 感觉这个比较难，给几个图

  
  测试案例

需要自己写攻击payload

• 测试方法

检测sql注入和目录遍历：
dz> run scanner.provider.injection -a com.mwr.example.sieve

dz> run scanner.provider.traversal -a com.mwr.example.sieve

遍历下载文件：
dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts

dz> run app.provider.download content://com.mwr.example.sieve.FileBackupProvider/data/data/com.mwr.example.sie
ve/databases/database.db /home/user/database.db

调试信息未关闭

• 查看配置文件xml,看debuggable属性值被设置为false则为安全，true为存在风险。

二次打包

• 所谓的二次打包的概念，即对已经编译发布的apk文件，即已经使用签名文件进行正式签名的应用文件进行自己的修改之后，再次签名打包发布的过程称为二次打包

这里面是详细步骤
https://www.jianshu.com/p/6bcc42542997

• 二次打包，就是把apk文件压缩之后，把里面的东西改动之后，再重新编译，打包，看看能不能正常运行。如果可以的话，那么攻击者就可以随意改动app，存在风险呀~