Safari URL重定向漏洞（CVE-2016-4585）利用分析

本文翻译自：http://www.mbsd.jp/blog/20160921.html ,有改动

原作者：プロフェッショナルサービス事業部　寺田 健

译者：Holic (知道创宇404安全实验室)

0x00 漏洞概述

漏洞简介

URL重定向漏洞有时会造成与上下文变量有关的漏洞，其导致的XSS便是常见的例子之一。本文所描述的漏洞在一年前提交至苹果官方，对应CVE-2016-4585，下面介绍这个漏洞的相关细节。

漏洞利用点

  1. 操纵请求中的Host头
  2. Origin Confusion XSS 此外还可以盗取敏感信息和展开钓鱼攻击。

受影响的组件

Safari < v9.1.2、iOS < v9.3.3、tvOS <v9.2.2

0x01 漏洞详情

1.操纵Host头

在服务端返回302或者307状态码的情况下，我们可以构造如下请求：

Location: http://example.com:abc<'">()foo/

注意上面URL的端口号不是数字。Safari在处理的时候会访问example.com:80 ，并将请求头转换成下面这样：

Host: example.com:abc'%3C%26%22%3E()foo

Host头的端口是无效的，这意味着可以操纵浏览器的Host头访问任何位置。

漏洞利用有两点限制：

下面来探索一些攻击利用的技巧

闭合单引号导致的XSS

上面看到一些字符是受限的，比如"'"和"&"。 一些XSS攻击在Safari下是受限的：

Safari的XSS过滤机制对Host头反射型同样生效。当然下面的这种情况是可以触发XSS的。

可操纵hostname的XSS

Host头可以影响类似于以下的部分的代码：

<script src="http://(HOST)/js/jquery.js">
<link href="http://(HOST)/css/style.css" rel="stylesheet" type="text/css">

当server中有类似代码的时候会触发漏洞。

在Github上能找到很多类似的代码，我在本地也进行了一系列验证。

我们看下<script src=标签这儿，假如Host头中的“example.com”修改为“example.com:abc"：

<script src="http://example.com:abc/js/jquery.js">

这种情况下，Safari并不会加载此畸形的URL（URL不合法），而攻击者是想要在Safari加载他自己服务器上面的JS。

经过一系列实验，想出以下思路：

攻击者服务器上的响应：

此时对目标服务器上的请求：

在接收到Location之后，Safari连接至example.jp:80,发送的Host头如下

Host: example.jp:evil

开始部分的a@被当做了基础认证信息。

目标服务器返回的内容： （原图） 后面包括@的部分被再次去掉了。由此可见，JS从攻击者的host获取，成功执行了XSS攻击。

攻击实例(加载了外部网站的js)：

信息窃取

上面所说的技巧同样可以用来窃取信息。假设一些web服务会重定向的URL包含了一些私密信息：

Location: http://(HOST)/foo?token=fj0t9wj958...

在这种情况下，攻击者还是可以通过@大法操纵Host头。

这种情景其实非常普遍，因为Location header是服务端对Host头的反馈最常见的地方。这可能因为不是web app的开发者这么写的，而是使用了相同的web平台，把相对URL处理成绝对路径的时候是基于Host头的。比如Java 的 HttpServletResponse#sendRedirect()方法。

顺便说下协议背景，路径绝对化的格式按照 HTTP/1.1 标准，RFC2616 是禁止 Location header 中使用相对 但是 RFC7231允许这么做 )。

如果header的值受到hostname的影响，除了Location header，HTML的URI属性像<form action= 和 <a href=同样可以造成信息窃取漏洞。

2.域混淆XSS

根据原文作者的例子，他在使用:非数字的方法测试目标链接的时候，像http://www.mbsd.jp:xyz/在加载外部资源的时候会出现以下情况。 明显采用相对路径的URL资源没有正确加载。 我们可以在浏览器console下面可以进行验证：

此页面的域是损坏的，这便是为什么采用相对路径加载资源会失败了。cookie也因此无法获取。同源策略在一定程度上抑制了攻击者的行为，不过如果能够好好利用的话这个故事就会变得截然不同。

想到的最好的利用方法便是iframe了，我们可以找个在header中"X-Frame-Options"限制宽松的站进行测试。

原作者的示例如下：

我们发现经过一系列混淆，浏览器会加载以iframe的父页面为baseURL的资源，导致了加载错误。

同样我也在线上验证了这种情况： 同理，相对路径加载资源导致这种情况。

造成的影响

加载的JS是在加载损坏内容的情况下进行的，因此不能通过XHR的方式获取同站点的cookie。但是依然可以对自身的document内容进行操作，这意味着攻击者可以修改页面内容。使用Cookie验证的页面也是可以进行攻击利用的，因为请求中带有cookie。

漏洞要点

0x02 修复建议

升级Safari至 2016 年 7 月 18日以后的版本

官方修复：加强验证，不合法URL会显示错误

0x03 参考

源链接

Hacking more

...