水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > iOSのSafariがContent-Dispositionを無視する問題が修正された

iOSのSafariがContent-Dispositionを無視する問題が修正された

2011年10月17日(月曜日)

iOSのSafariがContent-Dispositionを無視する問題が修正された

公開: 2011年10月18日2時25分頃

既に「About the security content of iOS 5 Software Update (support.apple.com)」に出ていますが、JVNの方でも公開されました……「JVN#41657660 iOS 上の Safari におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」。

書いてあるまんまですが、iOS上のSafariがContent-Disposition: attachmentの指定を無視するという問題でした。

これを届け出たのは、2010年の8月のことです。9月のCSS Niteでしゃべることになっていたのですが、会場のアップルストアではWindowsマシンの持ち込みが原則禁止となっています。私はMacを持っていないのでどうしようかと思ったのですが、せっかくなので、当時話題だったiPadでプレゼンをしてみようかと思い立ちました。

そこで、まずbakera.jpにPDFファイルを置いて、会社のiPadで開けるかどうか見てみました。すると、特に支障なくSafari上で表示できました……が、これは変なのですね。bakera.jpではPDFのHTTP応答ヘッダにContent-Disposition: attachmentをつけているので、PDFはダウンロードになるはずなのです。

しかし、よく考えてみると、iPadにはファイルをダウンロードして保存する機能がないのですから、これで良いわけですね。

……とは行きません。さらによくよく考えてみると、問題があることに気付きます。

私は以前、「JVN#465742E4 Wiki クローンにおけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」とか「JVN#91706484「Trac におけるクロスサイトスクリプティングの脆弱性 (jvn.jp)」といったものを届け出ています。WikiもTracも、サイト利用者が自由にHTMLファイルを添付する機能を持ったアプリケーションですが、スクリプトを含むHTMLを添付されると、クロスサイトスクリプティング脆弱性の問題が生じます。

そのための対応策として採用されたのが、HTTP応答ヘッダでContent-Disposition: attachmentを指定するという方法です。この指定があると、ほとんどのHTMLはブラウザ上で開かれず、ダウンロードのダイアログが開きます。ダウンロードした後のHTMLを開いてもドメインが異なりますので、クロスサイトスクリプティング脆弱性の問題は生じません。

※怪しげなファイルをローカルで開いて良いのかどうかという問題は別にありますが、それは利用者の行動の問題で、脆弱性とはまたちょっと違う話になります。

ところが、iPadのSafariではこの対策が無視され、Safari上でファイルが開かれてしまいます。実際に上記の脆弱性の対応が行われたTracにHTMLを添付してiPadで開いてみたところ、あっさりとスクリプトが実行されました。

……ということで問題を発見したのですが、実はこれ、ブラウザの問題ではないと考えることもできます。そもそもRFC2616では、Content-Dispositionについて以下のように書かれています。

RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.

以上、RFC2616 15.5 Content-Disposition Issues より

広く実装されているという言及もありますが、HTTPの標準の一部ではないという扱いになっていますので、「Content-Dispositionが無視されるのはNG」とは簡単には言い切れません。逆に、「Content-Dispositionでダウンロードになるという挙動は仕様ではないので、そのような挙動に依存した対策はNG」、という考え方もできるわけです。そうすると、これはSafariの側の問題ではなく、Tracや多くのWikiの対応方法が間違っているということになります。

しかし、この対応方法が採用できないとなった場合、アプリケーション側では他にどんな対応ができるのでしょうか。

まず、すぐに思いつくのが「ファイル添付を一切行わない」という対応です。これは要するに機能を諦めているわけで、利便性を大幅に低下させてしまいますから、対策としては採用しにくいでしょう。

User-Agentを見て、iOSだったら添付ファイルにアクセスできないようにする、という方法も考えられます。しかし、どのUser-AgentがiOSのように振る舞うのかを把握するのは困難です。その手のブラウザが新しく現れるたびにUser-Agentのリストをメンテナンスする必要に迫られてしまいますし、漏れなく列挙しきれる保証もありません。これも採用しにくいでしょう。

アプリケーション側での対策がなかなか難しい一方で、ブラウザ側での対応としては以下のようなものが考えられます。

これらの対応は現実的ですし、大きなデメリットもないものと思います。

以上のことから、この問題はブラウザ側で対応することが望ましいと判断し、Safariの問題として届出を行いました。

ちなみに、実際のSafariの対応がどうなったかというと、スクリプトは実行され、しかしながら元のサイトとは異なるOriginとみなされるようです。TracやWikiなどにHTMLを添付して開くと、スクリプトは実行されますが、そのドメインのCookieを読み取ったりはできないようになっています。

これは「そのドメインに偽のフォームが作られる」といった類の問題を防げないので、若干微妙な感もあります。とはいえ、もとより自由に添付ファイルが置けるような環境が対象なので、その手の問題はそれほど大きな脅威ではないと考えることもできるでしょう。

そんなわけで、iOSの対応としてはひとまず良かったのではないかと思っています。

ただ、気になっているのは、Content-Dispositionを無視するのがiOSのSafariだけではないかもしれないという点で……。最近ではスマートフォンや携帯端末がたくさん出てきています。iOSと同じようなポリシーで作られているものもたくさんありそうに思うのですが、その辺りどうなのでしょうね。

関連する話題: セキュリティ / UA / Safari / Apple / モバイル / IPA / JPCERT/CC / 情報セキュリティ早期警戒パートナーシップ

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト