XSS'im iOS devices on the example of software from Facebook, Google, VKontakte
This feature-bug is similar to stories about sending messages to Facebook from any user - known, but not widely publicized. It turned out that I found it myself, and only then found information about it on the Internet. But first things first...
# intro
In the dark, cold and rainy St. Petersburg night, I discovered a funny bug, to which applications from Facebook, Google, VKontakte and most likely from many other manufacturers were exposed. To explain it, we just need to know a little theory.
1/2 Ideology iOS
Ideologically, iOS has a principle: no left files on the device, no direct access to the content, and no file managers. We ourselves will scatter everything in different categories and issue it to the end user in the most convenient format. As a result, iOS does not provide for saving arbitrary files to the device. Of course, there are exceptions when applications download additional content for themselves with an arbitrary data type (for example, city maps, game resources, etc.), but they are all isolated from each other and are only local storage for the application.
2/2 HTTP Pro
The HTTP protocol is very simple and uses the most obvious model. Everything is transmitted in plain plain text. The request / response must contain a header (header) and (possibly) a body (body). They are separated through the usual line break (empty line). Example of a request to open habrahabr.ru:
GET / HTTP/1.1 Host: habrahabr.ru User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Answer:
HTTP/1.1 200 OK Server: nginx Date: Tue, 19 Nov 2013 13:48:02 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive Keep-Alive: timeout=25 X-Powered-By: PHP/5.4.21 X-Frame-Options: SAMEORIGIN Content-Encoding: gzip <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <meta name = "viewport" content = "width = 1080"> <title> / / </title> ... </html> In the answer, as mentioned above, the two parts - the headlines and content. So, the headlines. They define general information, how to behave the browser (response status (page found, not found, authorization required, etc.), whether to show content in the frame and various other situations. There is also a special header
')
Content-Disposition: attachment Which is described in RFC 2183 as follows
2.2 The Attachment Disposition Type
Bodyparts can be designated `attachment 'to indicate that they are
separate from the body of the message
contingent upon some further
action of the user. The MUA might be
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the
user could select for viewing or storage.
In a typical browser, it looks like you are accessing a file, but it is not displayed (as you used to) but offers to save it ( their display should not be automatic ).
# exploit
And now let's connect the two points above. We are accessing an iOS device to a file with a Content-Disposition: attachment . It turns out a contradiction . It seems that the file should be saved (as usual, users are used to seeing the save window on the device), but you can’t do it, because there is no such possibility. What did Apple do? They simply ignore the mobile Safari Content-Disposition and display the file in the browser.
What with mobile apps? In clients FB, Gmail, VK, everywhere there are attachments to messages. If you send, for example, an html or svg file, the webview component is called (read as Safari) and it renders it.
xss.svg
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg"> <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/> <script type="text/javascript"> alert('Redirect to google.ru...'); document.location="http://google.ru"; </script> </svg> As a result, Apple, trying to protect and trying to improve the lives of its users has created an unobvious moment for iOS developers and, nevertheless, a decrease in security. No notification that this content will be shown instantly. Returning to the RFC, it would be enough to notice something like: “this content should be saved, but it will be shown in the browser,” but we don’t see anything like that. The only exception is one option - Facebook, a mobile version .
# demo
| GMail |  |  |
 |  | |
| VK |  |  |
# impact
As you can see, javascript is running on a different domain, different from the main one. This domain is intended only for attachments to messages and is completely isolated from the main site. Therefore, the reaction, for example, Google to this is exactly this (ie, none)
It is not exactly a googleuserconent.com - it is specifically meant to be a “sandbox”, it is a user-controlled content. This is the same.
That's right. For example, it can also perform XSS in a regular browser.
But there are other vectors - phishing or DoS (for example, with a 0day exploit that affects all (?) Versions of iOS - habrahabr.ru/company/dsec/blog/201602 ). And not everyone can upload content to individual domains (and here is the impact as from the full xss on the main domain). It is worth noting that we need a separate domain, and not a subdomain.
In general, be careful when opening attachments on IOS devices and when developing web applications with attachments. After all, this feature-bug will be perfectly reproduced in any iOS browser (after all, they all use Safari as a basis).
Source: https://habr.com/ru/post/202784/
All Articles