iOS浏览器与UIWebview

iOS平台非常流行（根据StatCounter统计，它是第三大最受欢迎的平台）。移动浏览器约占市场份额的20%至25%。iOS提供与桌面浏览器和云的集成（因此攻击者可以获得相同的数据）。许多第三方iOS浏览器具有相似的弱点，这些弱点仍然被新浏览器复制…而且某些漏洞赏金计划也采用了iOS。

默认的iOS浏览器是Mobile Safari。根据iOS应用商店审核指南，“浏览网页的应用必须使用iOS WebKit框架和WebKit Javascript”。当然，Mobile Safari并非苹果商店中唯一的浏览器，其中一些也在桌面上使用。

浏览器使用UIWebView构建，这是一个允许您在应用程序中包含Web内容的组件。UIWebView与原生Mobile Safari之间的主要区别集中在UI上。它们都使用WebKit核心，但原生浏览器使用Viewport而不是UIWebView。UIWebView API相当简单直接。它允许您获取远程文件/HTML字符串/二进制数据，并且可以编程一些基本导航功能（goBack、goForward、stopLoading、reload）。stringByEvaluatingJavaScriptFromString函数允许您从字符串执行javascript，它将具有与来源页面相同的权限（request.mainDocumentURL）。远程Web服务器可以通过使用内容安全策略（CSP）来阻止javascript的执行。Javascript用于实现浏览器功能并覆盖原生函数，将它们与Objective-C代码桥接，例如实现多标签页。最后，UIWebViewDelegate API允许您响应加载文档中的某些事件。

演讲者解释说，他们的研究主要关注多标签页、地址栏、自动完成和密码管理器、下载、对不受信任SSL证书的支持以及其他功能（安全评级、恶意软件保护、云集成）的行为。他们解释说，他们受到“浏览器安全手册”（http://browsersec.googlecode.com）的启发，该手册提供了一组可以在浏览器上运行的测试用例。（参见http://browsersec.googlecode.com/files/browser_tests-1.03.tar.gz）。此外，他们从Web角度进行了黑盒测试，审查了Javascript代码并进行了一些逆向工程/调试。他们准备了一些跨浏览器测试用例，并在https://ios.browsr-tests.com上提供。

此外，他们还重新测试了一些以前的Mobile Safari漏洞（CVE-2011-3426等），并发现一些修复不完整。

UXSS（通用跨站脚本）

Lukasz说，在UXSS中，攻击者利用浏览器中的漏洞。在报告一些漏洞时，浏览器开发人员通常回应“WebKit应该处理同源策略，对吧”，将责任归咎于iOS。他们发现这并不总是正确的假设/反应。通常人们只关注功能而不是考虑安全性。CVE-2013-6893、CVE-2013-7197和CVE-2012-2899是各种浏览器（Mercury、Yandex、Google）中UXSS漏洞的几个例子。在大多数情况下，问题是由于浏览器支持多标签页的使用，并且您可以指定在子窗口/标签页中显示/执行什么。在iOS上，WebKit并没有真正的多标签页，这意味着浏览器开发人员需要自己实现所有必需的功能和特性。在桌面浏览器上使用的技术相当安全，但在iOS浏览器上并非如此。他们解释说，父窗口/标签页使用原生UIWebView同源策略。要创建新标签页，必须使用Objective-C中的“桥接”，开发人员需要记住更新地址栏和其他UI元素。为了完成所有这些，需要自定义同源策略。最终的子窗口/标签页再次使用原生SOP。

此外，由于移动浏览器没有真正的原生文件下载方式，它们通常加载文件，然后使用本地file://源写入文件。在某些情况下，文件（通过Content-Disposition: attachment）显示在托管站点的源中。在iOS 5+中实现了一个新的“隔离附件源”，但它并未解决所有问题。玩弄Content-Type也产生了一些有趣的结果。text/plain可以作为HTML执行（< iOS 7，现已修复），application/octet-stream也可以作为HTML执行，而使用application/other打开页面会触发Mobile Safari询问您使用什么应用程序打开文件（并可能获得本地跨源权限）。无论如何，如果您能够执行JS，破坏同源策略，您可以窃取cookie、访问内部网站等。他们解释说，窃取密码并不那么容易。为了以适当的方式处理本地HTML文件，开发人员应将文件作为text/plain打开，应用内容安全策略标头，使用HTML5沙盒，或使用Quick Look而不是UIWebView（因为Quick Look不支持Javascript）。

从攻击角度来看，要利用UXSS，如果您还能够欺骗地址栏，成功的机会将会增加。事实上，有时您甚至不需要UXSS漏洞，仅仅能够欺骗地址栏就足够了。事实上，您不能真正使用框架，通常只能攻击移动浏览器的父/顶部窗口，您不能真正将窗口隐藏在另一个窗口下…因此UXSS漏洞的成功可能相对有限。

ABS（地址栏欺骗）

Marek解释说，地址栏是移动浏览器开发人员编程的一部分。它不是UIWebView的一部分。能够更改网站内容而不更新地址栏，显然是一件坏事。一种可能的方法是使用超时函数来更新当前页面的内容。“初始化和中断”技术是实现ABS的另一种方式。您的代码不会等待页面加载，而是中断加载并加载其他内容。您还可以告诉浏览器回退到某个页面。在Kaspersky Safe Browser和F-Secure Safe browse中发现了漏洞。在某些情况下，即使您使用自签名证书加载页面，浏览器甚至可能保持绿色的“证书正常”图标。

一些浏览器容易受到以下场景的影响：首先加载无效页面，然后重定向到最终的钓鱼页面，而不更新地址栏。在循环中加载页面，并首先连接到未监听的端口，然后再连接到实际页面/端口，也可能允许您控制地址栏中的URL（因为端口通常不显示）。

要修复这些问题，重要的是显示当前在UIWebView中加载的URL，而不是您认为会在那里的URL。此外，在每个事件上更新地址栏，包括webView::didFailLoadWithError。最后，如果有实际成功且有效的SSL连接，显示SSL锁是有意义的。在此之前不要显示。

其他常见弱点

他们还研究了一些其他漏洞，包括URI方案（影响下载、发送未经身份验证的推文和绕过弹出窗口阻止程序）和URL处理（Mobile Safari中的格式字符串内存损坏漏洞，允许您泄漏堆栈内容，甚至在使用代理渲染时访问服务器文件系统）。

密码管理器功能也由Web浏览器开发人员实现。在一个场景中（Kaspersky Safe Browser），研究人员能够通过MITM漏洞从密码管理器中窃取密码（通过插入自动接收用户名/密码的隐藏框架）。地址栏将非常短暂地更新（除非您将其与ABS结合使用），但演示的攻击是成功的。

最后，SSL的处理方式很重要。默认情况下，对于iOS UIWebView https请求的无效证书会在没有用户交互的情况下被拒绝。通过某些漏洞，可以改变此行为（因此用户将接受自签名证书）。Opera Coast 3.0是容易受到简单MITM攻击的浏览器之一。

关于演讲者

Lukasz Pilorz - 此前是国际电子商务平台的应用程序安全专家，现在在一家最大的英国银行担任渗透测试员。OWASP波兰会议的常任演讲者，并在波兹南发起分会。他的Web安全职业生涯始于2006年的sla.ckers.org。

Marek Zmyslowski在渗透测试方面拥有多年经验，包括多家波兰银行和金融机构的银行系统和电子银行。目前，他在世界上最大的银行之一担任首席渗透测试专家，测试内部系统。持有Offensive Security的OSCP和OSCE证书。他也是OWASP波兰董事会成员。Marek毕业于华沙理工大学电子与信息技术学院。