IMCAFS

Home

an interesting apple xss (cve

Posted by millikan at 2020-03-10
all

Originally posted on Prophet Forum: https://xianzhi.aliyun.com/forum/read/755.html

At the request of CVE author, help to analyze this vulnerability. In fact, this is an interesting Apple XSS (cve-2016-7762). The author of the loophole is really good at trying and exploring, and he must praise one here!

The official safety notice issued on January 24, 2017 is as follows:

So is the vulnerability really resolved as described in the security bulletin? In fact, this is not the case.

Before analyzing, first understand what kind of loophole this is.

POC:

The renderings are as follows:

Looking back at the POC above, it is found that the vulnerability is not only in Safari, but also in apps using WebKit.

We all know that if IOS app wants to display web content like a browser, it must use WebKit. This is because WebKit provides a series of classes for web page presentation and browser functions. Wkwebview (or uiwebview) is used to display web content in app. When we use safari or WebKit app to open a URL, IOS will automatically use wkwebview / uiwebview to parse and render these pages or documents. When the victim clicks the link in the document on the web server, the JavaScript script inserted in the hyperlink will be executed, resulting in XSS. This is because wkwebview / uiwebview does not do a good input verification for the embedded content in the document when parsing and rendering the document file on the remote server.

From the perspective of exploitation alone, the vulnerability is weak, because the triggering of the vulnerability must depend on the user clicking the hyperlink in the document. The possible exploitation scenarios that the author can think of are as follows:

In fact, the XSS vulnerability itself does not have much technical content or skills, but it is very interesting and worth thinking in terms of mining ideas. The author did not insert JS directly into the web page itself, but cleverly used hyperlinks in some documents to bypass the input verification of WebKit. This also explains a basic principle of web security to a certain extent, that is, "all input is unsafe", whether it is direct input or indirect input. When we do application or product security design, we'd better be able to confirm various trust boundaries and input and output, and do a good job in verification, filtering and necessary coding, so as to effectively prevent the vulnerability caused by this indirect input.

https://support.apple.com/en-us/HT207422

https://developer.apple.com/reference/webkit

https://developer.apple.com/reference/webkit/wkwebview

https://developer.apple.com/reference/uikit/uiwebview