webview它是一个系统组件，webview资源将基于web的内容嵌入到android应用程序中，它允许直接在应用程序内部显示来自web的内容，从而创建混合的android应用程序。
webview它就是将加载本地或外部web内容的本机应用程序，它将使用HTML5、javaScript和CSS进行实现。在android5.0系统之后，webview它就可以独立于操作系统进行更新。
它虽然在android的功能开发带来许多非常大的功能，但是同样它也可能存在一个很大的安全风险。
这里就谈谈webview常见6大安全风险。
在目前的APP安全合规政策下，会对明文数据存储有一定制限制的要求，但是也避免不了在android的webview中会出现加载明文的内容，包括在不加密流量的情况下加载web内容，这种情况下非常容易受到中间人攻击。通过中间人攻击就可能导致敏感信息泄露和流量违规操作。
如果在中间人攻击期间获得凭据，则攻击者可以假设该特定网站的受害者身份。除了可能收集的其他信息（例如电子邮件地址）之外，后果可能会更糟，因为众所周知，用户会为多种不同的服务重复使用相同的密码。
在下图中，可以看到从登录网页加载的明文内容示例，其中凭据很容易被截获：
在不通过 SSL/TLS 强制加密的情况下，攻击者还可以对截获的流量进行更改，例如，在HTTP响应中注入键盘记录器，然后从用户那里收集更多信息。
下图中是容易受攻击的Java代码片段。HTTP 协议的使用应该被 HTTPS 取代。使用 SSL/TLS 需要在 Web 服务器上安装正确签名的证书，这是个相对安全的方案。
在android中，从API 23版本开始，可以在 Manifest配置文件上上将“android:usesCleartextTraffic”标志设置为 false，以防止加载明文内容。这个标志的默认值为真。
SSL（Secure Socket Layer）安全套接层是Netscape公司率先采用的网络安全协议。它是在传输通信协议（TCP/IP）上实现的一种安全协议，采用公开密钥技术。
在SSL中的错误处理会导致严重的安全漏洞。默认情况下，如果在 SSL/TLS 通信协商期间检测到错误，WebView 将不会加载 Web 内容。发生这些错误的最常见情况是服务器证书未由公认的权威机构签署。
许多开发者没有获得正确签名的证书，而是选择实施忽略证书错误的绕过机制。使用这种方法，不需要有效的证书，但应用程序容易受到中间人攻击，呈现与上述情况相同的风险。借助自制的无效证书，攻击者能够拦截和操纵流量。
在下面的示例中，实现了一个 WebView 来加载网页https://github.com。执行了中间人攻击，受害设备中的结果是一个空白屏幕，因为 WebView 检测到无效证书并且没有建立与 GitHub 服务器的连接。
调试器上显示以下错误：
如果实现了绕过 SSL 错误的机制，攻击者就能够完成攻击。如下图所示，攻击者在实现绕过机制后执行了流量拦截和 HTML 代码注入。现在已加载 GitHub 页面并执行注入的代码。
如前所述，默认行为是阻止不正确的 SSL/TLS 连接。获取和安装由公认机构签署的证书应该始终是采用的方法，这种是一个相对安全的方案。
WebViews 默认是禁用JavaScript 执行。不过只要调用setJavaScriptEnabled函数可以更改此行为，如果不需要客户端脚本，建议是保持默认行为。通过这种方式，应用程序变得能够抵御跨站点脚本(XSS) 攻击，并减少中间人 (MitM) 攻击的后果。
在android的应用程序中常见攻击媒介就是广告。来自外部来源的广告通常会加载到 WebView 中，阻止 JavaScript 执行是防止恶意代码被注入和保护应用程序用户的好方法。
在强制使用 JavaScript 的情况下，应清理所有输入以防止XSS 攻击。必须实施其他措施来加强应用程序，XSS它会导致非常严重的后果。如果可能，直接禁用 JavaScript的执行。
WebView在默认情况下是可以访问本地资源，尽管强制执行了一些限制。这些限制可能因所使用的 API 而异。
以下是可用于更改 WebView 默认权限的方法列表：
setAllowContentAccess函数，它的默认值为“true”并允许 WebView 访问内容提供者。通常创建内容提供程序以允许应用程序之间的安全数据共享。
setAllowFileAccess函数，它的默认值为“true”并允许 WebView 从文件系统加载内容。
setAllowFileAccessFromFileURLs函数，它是自API 16以来，其默认值为“false”，在此版本之前默认为“true”。它允许来自本地网页的 JavaScript 在 WebViews 中呈现并使用“file:///”模式调用来访问文件系统上的资源。
setAllowUniversalAccessFromFileURLs函数，它如果使用参数“true”调用该方法，则忽略此设置。
setAllowUniversalAccessFromFileURLs函数，它自 API 16以来其默认值为“false”；此版本之前默认为“true”。它允许来自本地网页的 JavaScript 在 WebViews 中呈现并使用“file:///”模式调用来访问来自任何来源的资源。
如上所述，WebView 默认可以加载本地资源，必须谨慎使用“file:///”模式，因为它可能导致未经授权的文件访问。
尽可能避免直接让 WebView 以动态方式访问本地文件。如果无法实现静态实现，
请可以用 setAllowFileAccessFromFileURLs
和setAllowUniversalAccessFromFileURLs.方法。
JavascriptInterfaces 允许在WebView 中呈现的 JavaScript 代码调用应用程序中实现的Java方法。这是一个非常强大的功能，因为它允许 WebView 中的网页与所有设备功能进行交互，例如摄像头、麦克风或 SMS 管理器。
尽管带来了很强大的功能，但它们也被认为是巨大的安全风险。这是因为如果实现功能，上述部分中提到的攻击可以通过与应用程序代码交互产生更大的影响。
在 API 17 也就是Android 4.2系统 之前，由于代码执行漏洞 (CVE-2012-6636)，JavascriptInterfaces 始终与关键风险级别直接相关。它们没有受到适当的限制，并允许执行 Java对象的任意方法，使用 WebView 中加载设计的 JavaScript 代码中的Java反射 API。
在API 17 到最新版本，必须使用“@JavascriptInterface”在暴露的本机函数上声明注释，并且只有那些带注释的方法才会暴露给 JavaScript 代码。
由于此安全实施，建议针对 Android API 级别 17 或更高版本编译应用程序。通过强制添加“@JavascriptInterface”注释，它可以防止通过 java.lang.Runtime 访问操作系统命令。
JavascriptInterfaces 可能允许跨站点脚本 (XSS) 和中间人 (MITM)攻击到达应用程序的公开方法。必须在这些方法中实施额外的安全措施，以防止在被恶意代码调用时造成损害。
WebView 通常容易受到跨站点脚本 (XSS) 和中间人(MITM)攻击，建议实施额外的安全限制，为应用程序的用户提供更安全的环境。
验证 WebView 正在加载的内容的来源是一个很好的安全预防措施。它可以通过覆盖 shouldOverrideUrlLoading 和 shouldInterceptRequest 函数方法来实现。
这 shouldOverrideUrlLoading与WebView 打开新网页有关。
该 shouldInterceptRequest 方法更具侵入性，允许控制加载在 WebView 中的网页访问的每个资源。
为了证明实施这些安全措施之一的有效性，可以使用前面给出的示例（启用 JavaScript）。它包含一个成功的 XSS 攻击，将 WebView 重定向到一个邪恶的页面。可以通过覆盖该 shouldOverrideUrlLoading 方法来阻止此重定向，如下图所示。
上面显示的代码将这个应用程序的 WebView 限制为仅从 baidu域加载网页。请注意，原始 URL“ http://webviewtest/login.php”将被正确加载。这是保护 WebView 的一种非常有效的方法。可以添加其它检测功能，并在检测到攻击时发出警报。
结束
本文作者：编码安全
本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/185553.html
如有侵权请联系:admin#unsafe.sh