この機能バグは、あらゆるユーザーからFacebookにメッセージを送信することに関する話に似ています -既知ですが、広く知られていません。 私はそれを自分で見つけたので、インターネットでそれに関する情報を見つけました。 しかし、まず最初に...
＃イントロ
サンクトペテルブルクの暗くて寒い雨の夜、面白いバグを発見しました。これは、Facebook、Google、VKontakte、そしておそらく他の多くのメーカーのアプリケーションであることが判明しました。 それを説明するには、ちょっとした理論を知る必要があります。
1/2イデオロギーiOS
イデオロギー的に、iOSには原則があります。デバイスにファイルが残っていない、コンテンツに直接アクセスできない、ファイルマネージャーがありません。 私たち自身がすべてを異なるカテゴリに分散し、最も便利な形式でエンドユーザーに発行します。 その結果、iOSはデバイス上の任意のファイルのストレージを提供しません。 もちろん、アプリケーションが任意のデータタイプ（たとえば、都市地図、ゲームリソースなど）で追加のコンテンツをポンプアウトする場合は例外がありますが、それらはすべて互いに分離されており、アプリケーションのローカルストレージにすぎません。
2/2 Pro HTTP
HTTPプロトコルは非常に単純で、最も明白なモデルを使用します。 すべてがプレーンプレーンテキストで送信されます。 要求/応答には、ヘッダーと（場合によっては）ボディを含める必要があります。 それらは通常の改行（空行）で区切られます。 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
答えは：
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>
上記のように、答えには2つの部分があります-ヘッダーとコンテンツです。 だから、見出し。 ブラウザの動作に関する一般的な情報（応答ステータス（ページが見つかった、見つからない、許可が必要など）、フレーム内のコンテンツを表示するかどうかなど）を決定します。特別なヘッダーもあります
Content-Disposition: attachment
RFC 2183には次のように記載されています
2.2添付ファイルの処理タイプ
ボディパーツは「アタッチメント」と指定して、それらが
メールメッセージの本文とは別に、
表示は自動であってはなりませんが 、さらに条件に応じて
ユーザーのアクション。 MUAは代わりに、
添付ファイルのアイコン表示を備えたビットマップ端末、または
キャラクター端末では、添付ファイルのリストがあり、
ユーザーは表示またはストレージを選択できます。
典型的なブラウザでは、ファイルにアクセスしているように見え、（慣れているように） 表示されませんが、保存することを提案します（ 表示は自動であってはなりません ）。
＃エクスプロイト
次に、上記の2つのポイントを接続しましょう。 iOSデバイスでは、 Content-Disposition：attachmentを持つファイルにアクセスしています。 それは矛盾になります。 ファイルを保存する必要があるようです（通常、ユーザーはデバイスの保存ウィンドウを見ることに慣れています）が、これも不可能なので、これもできません。 Appleは何をしましたか？ モバイルSafariのContent-Dispositionを無視し、ブラウザにファイルを表示するだけです。
モバイルアプリについてはどうですか？ FB、Gmail、VKのクライアントでは、どこにでもメッセージへの添付ファイルがあります。 たとえば、htmlまたはsvgファイルを送信すると、webviewコンポーネント（Safariとして読み込まれます）が呼び出され、レンダリングされます。
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>
その結果、Appleはユーザーの生活を保護し、改善しようとして、iOS開発者にとっては明らかな瞬間を生み出しましたが、それでもセキュリティが低下しました。 このコンテンツがすぐに表示されるという通知はありません。 RFCに戻ると、「このコンテンツは保存する必要がありますが、ブラウザに表示されます」などの簡単な通知で十分ですが、そのようなものは表示されません。 例外はまだ1つのバージョン-Facebook、モバイルバージョンのみです。
＃デモ
| GMail |  |  |
| フェイスブック |  |  |
| VK |  |  |
＃インパクト
ご覧のとおり、javascriptはメインドメインとは異なるドメインで実行されます。 このドメインはメッセージへの添付のみを目的としており、メインサイトから完全に分離されています。 したがって、たとえば、これに対するGoogleの反応はそれだけです（つまり、いいえ）
XSSをトリガーするドメイン-googleuserconent.com-は、安全でない可能性のあるさまざまなタイプのユーザー制御コンテンツ用の区分化された「サンドボックス」として具体的に意図されています。 このドメインは、同一生成元ポリシーにより、機密コンテンツから隔離されています。
それは本当です。 たとえば、通常のブラウザでXSSを実行することもできます。
しかし、フィッシングやDoS（たとえば、すべての（？）IOSバージョンを傷つける0dayエクスプロイト-habrahabr.ru/company/dsec/blog/201602 ）といった他のベクトルがあります。 はい、すべての人が別々のドメインにコンテンツをアップロードするわけではありません（メインドメインの完全なxssから既に影響を受けています）。 サブドメインではなく、別個のドメインが必要なことに注意してください。
一般に、iOSデバイスで添付ファイルを開くとき、および添付ファイル付きのWebアプリケーションを開発するときは注意してください。 結局のところ、この機能バグはiOSブラウザーで完全に再現されます（結局のところ、これらはすべてSafariをベースとして使用しています）。