Mac OSX Safari 8.0.5 UXSS vulnerability technical analysis-vulnerability warning-the black bar safety net

Vulnerability description:
The vulnerability affects version 6. 2. 6,7. 1. 6,8. 0. 6[1]before the Apple Safari browser, the attacker can be through carefully constructed URLs to bypass the same origin policy any read the file.
Vulnerability description:
In the Safari browser, similar http://localhost:1 2 3 4 5(the port should be no open)of the address, will appear an error page. In the console input window. location. the href is displayed:
> the window. location. href
“file:///Applications/Safari. app/Contents/Resources/”
Therefore, the error page via file URL to render. This in itself is no problem. However, it allows arbitrary web pages can be obtained file:// the window reference. Although not in the embedded iframe to display the error page, but can open a new window(so that it can appear the error page, of course, will need to induce users to click operation-automatically pop-up window will usually be intercepted), such as:
window. onclick = function() {
var fileWin = window. open(‘http://localhost:12345’, ‘_blank’);
}
In this case the variable fileWin is file://url corresponding to the window of a reference. Under normal circumstances, since the same-origin Policy, we can not directly to the cross-domain form in the injected script. And Safari, a form can access to the cross-domain form some of the limited attributes, including location,postMessage, and history. Such as:
> console. log(fileWin. history)
[Object Object]
> fileWin. history. replaceState({},{},‘/’);
SecurityError
Even though it can access to the history object, but we are not able to access the history object’s pushState and replaceState properties, then use the current history object for replaceState and the role of the cross-domain of the history of the object, what happens?
history. replaceState. call(fileWin. history, {}, {}, ‘file:///’);
Because only the state has changed, and not send a new page request, and therefore did not display the changes. Re-loading is as follows:
history. replaceState. call(fileWin. history, {}, {}, ‘file:///’);
fileWin. location. reload();
To reproduce load after safari crashes. Crash, Safari in access to the document will navigate to the file://URL. Safari for can directly use the file://URL for viewing the file://URL there is a white list. If the URL is not in the white list, or not allow the URL of the subdirectory, the browser will crash(If the desired URL is not on the list, or is not in a subdirectory of a URL on the list, the browser crashes on an assertion.)
To bypass the URL white list
Browser through back(history. back())operation to access the page allow is file://url type address. The features for the browser after a crash or exit after the repair(repair when these Windows of history state will also repair)so you can use this feature to access the user session before the end of the visited file://URL of the page.
history. replaceState. call(fileWin. history, {}, {}, ‘file:///’);
fileWin. location = ‘about:blank’;
fileWin. history. back();
The above code will open a link to“/”in the Finder window. Because the root directory file:///exists in the history, the attacker can apply it to access any valid file URL.
Safari under the file://URL use
file://URL of the html document can read the file system of any file, and can inject a javascript script to any of the domains. However, there is a limit is if the html file has Apple’s Quarantine attribute(to download the file, mount the file system are automatically set on the attribute), the html will be allowed in the sandbox environment. At this point you can use. webarchive files[2]。
Reference link:
【1】https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1155
【2】http://joevennix.com/2013/04/25/Abusing-Safaris-webarchive-file-format.html
【3】http://joevennix.com/2015/06/24/Adventures-in-Browser-Exploitation-Part-II-Safari-8-UXSS.html(translation of the article source)