Android Intent Scheme URLs攻击
0x0 引言
我们知道，在Android上的Intent-based攻击很普遍，这种攻击轻则导致应用程序崩溃，重则可能演变提权漏洞。当然，通过静态特征匹配，Intent-Based的恶意样本还是很容易被识别出来的。
然而最近出现了一种基于Android Browser的攻击手段——Intent Scheme URLs攻击。这种攻击方式利用了浏览器保护措施的不足，通过浏览器作为桥梁间接实现Intend-Based攻击。相比于普通Intend-Based攻击，这种方式极具隐蔽性，而且由于恶意代码隐藏WebPage中，传统的特征匹配完全不起作用。除此之外，这种攻击还能直接访问跟浏览器自身的组件（无论是公开还是私有）和私有文件，比如cookie文件，进而导致用户机密信息的泄露。
0x1 Intent scheme URL的用法
看一下Intent Scheme URL的用法。
从用法上看，还是很好理解的，这里的代码等价于如下Java代码：
Intent intent = new Intent(“myaction”);
intent.setData(Uri.parse(“mydata”));
intent.setType(“text/plain”);再看一个例子：
intent://foobar/#Intent;action=myaction;type=text/plain;S.xyz=123;i.abc=678;end上面的语句，等价于如下Java代码：
Intent intent = new Intent(“myaction”);
intent.setData(Uri.pase(“//foobar/”));
intent.putExtra(“xyz”, “123”);
intent.putExtra(“abc”, 678);其中S代表String类型的key-value，i代表int类型的key-value。
源码中提供了Intent.parseUri(String uri)静态方法，通过这个方法可以直接解析uri，如果想更一步了解其中的语法，可以查看官方源码。
0x2 Intent scheme URI的解析及过滤
如果浏览器支持Intent Scheme URI语法，一般会分三个步骤进行处理：
- 利用Intent.parseUri解析uri，获取原始的intent对象；
- 对intent对象设置过滤规则，不同的浏览器有不同的策略，后面会详细介绍；
- 通过Context.startActivityIfNeeded或者Context.startActivity发送intent；
其中步骤2起关键作用，过滤规则缺失或者存在缺陷都会导致Intent Schem URL攻击。
下面是各大浏览器对Intent scheme URL的支持情况
可见，除了Firefox外其他的浏览器都支持Intent Scheme URL语法。
0x3 攻击示例
a.Opera mobile之cookie盗取
Opera上的intent过滤策略是完全缺失的，因此我们可以轻易调用Opera上的私有activity。比如下面这个攻击示例：
通过上面的脚本，我们可以直接调起AdMarvelActivity。AdMarvelActvity会从intent中获取url，并以HTML/JavaScript的方式解析cookies文件。
试想一下，如果我们预先构造一个恶意网站，并让用户通过浏览器访问。这时在恶意见面中，存在如下脚本：
当AdMarvelActivity解析cookies文件时，就会执行playload。
b.Chrome之UXSS
Chrome的UXSS漏洞利用相对复杂。介绍之前，我们需要先了解一下关于Intent Selector的用法，详情见。简而言之，Intent Selector机制提供一种main intent不匹配的情况下可以设置替补的方案。比如A是main intent, B是A的selector intent，当startActiviy时，系统发现A无法匹配则会尝试用B去匹配。
Chrome相比于Opera，在intent过滤的步骤中添加了安全策略，代码如下：
Intent intent = Intent.parseUri(uri);
intent.addCategory(“android.intent.category.BROWSABLE”);
intent.setComponent(null);
context.startActivityIfNeeded(intent, -1);
从代码中，可以看到Chrome为了防御Intent Based攻击，做了不少限制，比如把category强置为”android.intent.category.BROWSABLE”，把component强置为null，相对之后比Opera强多了。然而，Chrome忽略了Intent Selector的用法，比如下面的用法:
intent:#Intent;S.xxx=123; SEL;component=com.android.chrome/.xyz;end留意其中的关键字“SEL”，其实就是设置了一个component为com.android.chrome/.xyz的 selector intent，这种用法导致chrome的防御措施形同虚设。最后看一下Chrome UXSS的PoC：
这里的关键点是WebappActivity0对new intent的处理方式上。
第一次打开站点，并完成加载。第二次则是直接把javascript payload注入到目标网页。这个漏洞存在于在所有低于v.30.0.1599.92的chrome版本，而新版本修改WebappActivity对new intent的处理方式，会创建new tab，这样就避免了javascript inject。
然而在新版中，依然没有屏避intent selector的使用，因此依然存在Chrome的私有组件和文件被读取的安全隐患。
0x4 结论
通过上两个漏洞的描述，我们总结得出一种相对比较安全的Intent Filter方法，代码如下：
// convert intent scheme URL to intent object
Intent intent = Intent.parseUri(uri);
// forbid launching activities without BROWSABLE category
intent.addCategory("android.intent.category.BROWSABLE");
// forbid explicit call
intent.setComponent(null);
// forbid intent with selector intent
intent.setSelector(null);
// start the activity by the intent
context.startActivityIfNeeded(intent, -1);