Safari < 9.1.2 URL redirection vulnerability

This article translated from: http://www.mbsd.jp/blog/20160921.html ,there is changes

The original author: a PU ro Fu epolight ッ silicone ョ na Hikaru Cytec ー bldg su division Temple Tian Jian

Translator: Holic (know Chong Yu 404 security lab)

Part of the contents of the translation from MBSD, there are changes.

0x00 vulnerability overview

Vulnerability description

URL redirection vulnerability sometimes causes and context variables related to vulnerability, which leads to XSS is a common example. This article described the vulnerabilities in a year ago and submitted to Apple the official, corresponding to CVE-2016-4585, the following describes the vulnerability of the relevant details.

The exploit point

1. To manipulate the request Host header
2. Origin Confusion XSS In addition you can also steal sensitive information and expand the phishing attacks.

The affected component

Safari < v9. 1. 2, The iOS < v9. 3. 3, The tvOS <v9. 2. 2

0x01 vulnerability details

1. Manipulation of the Host header

On the service side return a 302 or 307 status code of the case, we can construct the following request: Location: http://example.com:abc<'">()foo/ Note that the above URL is the port number not a number. Safari at the time of treatment will access example. com:80, and the request header is converted into the following: Host: example. com:abc'%3C%26%22%3E()foo Host the head of the port is invalid, this means that you can manipulate the browser in the Host header to access any position.

Exploit there are two points restrictions:

• These characters have part of the is encoded;
• Only the":" behind the content can be modified

Below to explore some of the attack using the skills

The closing single quote leads to XSS

See above some of the characters is limited, such as"'“and”&"are. Some XSS attack on Safari is restricted:

Safari’s XSS filtering mechanisms of the Host header of the reflection type of the same effect. Of course following this case is can trigger XSS.

Steerable hostname XSS

The Host header can affect the similar to the following portion of code: javascript <script src="http://(HOST)/js/jquery.js"> <link href="http://(HOST)/css/style. css" rel="stylesheet" type="text/css"> When the server has a similar code will trigger the vulnerability.

In Github can find a lot of similar code, I was in the local also conducted a series of verification.

We look at<script src=tags in here, if the Host header“example.com”modifications to“example. com:abc": javascript <script src="http://example.com:abc/js/jquery.js"> In this case, Safari will not load the malformed URL, the URL is not legitimate, and the attacker is wanted in Safari to load his own server on top of JS.

After a series of experiments, came up with the following ideas:

The attacker on the server response:

In this case the target server of the request:

After receiving the Location after the Safari is connected to the example. jp:80,sending the Host header as follows Host: example. jp:evil The beginning part of a@is used as the basis of the authentication information.

The target server returns the content: （Original. The back including the@portion is again removed. Thus, the JS from the attacker’s host acquisition, the successful implementation of a XSS attack.

Attack example(load an external website of js): the

Theft

The above said skills can also be used to steal information. Assume that some web services will redirect a URL that contains some private information: Location: http://(HOST)/foo? token=fj0t9wj958... In this case, the attacker can still through the@Law of the manipulation of the Host head.

This scenario is actually very common, because the Location header is that the service end of the Host header of Feedback the most common place. This may be because not the web app developer wrote, but using the same web Platform, the relative URL is processed into an absolute path when it is based on the Host header. For example, Java’s HttpServletResponse#sendRedirect()method.

By the way, under the Agreement the background, the path to absolute format according to the HTTP/1.1 standard, RFC2616 is the prohibition of the Location header using a relative however RFC7231 allowed so to do).

If the header value is the hostname of the impact, in addition to the Location header, HTML URI attribute like<form action= and the <a href=can also be caused by information theft vulnerability.

2. Domain confused with XSS

According to the original author of the example, he used:a non-numeric method to test the target link, like http://www.mbsd.jp:xyz/in the loading of the external resource will appear when the following situations. Clear the use relative path of URL to resource is not loaded correctly. We can be in the browser console the following can be verified:

This page of the domain is corrupted, this is why using relative paths to load resources failed. cookies therefore can not obtain. The same-origin policy in a certain extent inhibits the attacker’s behavior, but if you can make good use of the words of this story will become very different.

Think of the best use of the method is the iframe, we can find in the header"X-Frame-Options"limit the relaxed standing test.

The original author of the example is as follows:

We found that after a series of confused, the browser will load in the iframe of the parent page to the baseURL of resources, resulting in a load error.

The same I also online to verify this situation: Similarly, the relative path to load resources lead to this situation.

The impact of

Loading the JS is in the loading damage to the contents of the case, and therefore can not pass the XHR way to get the same site cookie. But still can their own document, this means that an attacker can modify the page content. Use of Cookies the authentication of the page is also possible to attack the use of the AS request with a cookie.

Vulnerability points

• Safari in the handling of invalid ports when the use default ports 80 and 443）
• Malformations of the Host header as Host: hostname:xyz can be sent to Apache, WebLogic and Nginx and other Servers, Tomcat and IIS will not receive.
• You can use the GET and POST HTTP request method, use 302 or 307 to jump
• In the iframe, the base URL are inherited from the parent page, the strange is by far the<base href=is completely ignored.
• JS is in the blank under the domain of the Executive, with the iframe the parent page separation, in addition to the cookies, DOM objects can access
• The CSP (or the X-Frame-Options) may prevent the XSS attacks

0x02 repair recommendations

Upgrade Safari to 2016 7 May 18, the later versions

Official fix: strengthening verification, the illegal URL error will be displayed

0x03 reference

• http://paper.seebug.org/51/
• http://www.mbsd.jp/blog/20160921.html
• https://support.apple.com/HT206900