![multipart な MIME コンテンツの仕様
(RFC2046)
Content-type: multipart/*; boundary=”boundary text”
と書くと
[CRLF]--boundary text(スペース)* [CRLF]
がボディの各パートの区切りとなる
各パートはこの区切を含んではいけない(MUST NOT)。](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Recently uploaded
Recently uploaded (8)
Featured
Featured (20)
MIMEデリミタ注入攻撃
- 1. マルチパート MIME を返す Web アプリケー ションにおける脆弱性 マルチパート MIME 境界注入攻撃とその対策 Vulnerability on web application returns multipart MIME content Attack and defense method for Multipart MIME delimiter Injection
- 2. multipart な MIME コンテンツの仕様 (RFC2046) Content-type: multipart/*; boundary=”boundary text” と書くと [CRLF]--boundary text(スペース)* [CRLF] がボディの各パートの区切りとなる 各パートはこの区切を含んではいけない(MUST NOT)。
- 3. 含んでいるとどうなるのか Content-type: multipart/x-mixed-replace; boundary=AAA --AAA Content-type: text/plain; charset=UTF-8 プレーンテキスト部 その１ --AAA Content-type: text/plain; charset=UTF-8 プレーンテキスト部 その２ --AAA--
- 4. ここで 「その２」を 「--AAA[CRLF] Content-type: text/html; charset=UTF-8 [CRLF][CRLF] <html><script>alert(1)</script></html>[CRLF]」 に変えたら？
- 5. こうなります。 Content-type: multipart/x-mixed-replace; boundary=AAA --AAA Content-type: text/plain; charset=UTF-8 プレーンテキスト部 その１ --AAA Content-type: text/plain; charset=UTF-8 プレーンテキスト部 --AAA Content-type: text/html; charset=UTF-8 <html><script>alert(1)</script></html> --AAA--
- 6. 2 パート目が分割されて JavaScript 入りの HTML が注入され てしまいました。 Content-type: text/plain; charset=UTF-8 プレーンテキスト部 Content-type: text/html; charset=UTF-8 <html><script>alert(1)</script></html>
- 7. これがマルチパート MIME デリミタの注入によるコンテンツ の改竄です。 これは、Web サーバのレスポンスで発生すれば HTTP レスポン ス分割、E メールに使用すればメールの改竄となります。
- 8. 問題への対策 (1)エスケープやサニタイズは本質的な対策ではない ・コンテンツの各パートの種類によってはエスケープする 方法がない(text/plain など)。 ・ Content-Transfer-Encoding: base64 や US-ASCII の上 位互換ではないエンコーディングを使えば HTML 等の エスケープを迂回できる
- 9. (2)本質的な対策 絶対に delimiter をコンテンツ本体部に注入できないよう にする。
- 10. 具体的には以下のいずれかを行う (1) 事前に全てのパートに delimiter が含まれないことを確 認する（事前に全パートの内容が確定している場合に 有効な方法。静的ページならこれで十分） (2) 各 パー トを Content-Transfer-Encoding: base64 とし て base64 で パ ー ト 本 体 を エ ン コ ー ド に す る （delimiter 先頭の”--”の注入が不可能になる）。
- 11. (3) boundary をランダムにすることで攻撃者が実用的なコ ストで故意に衝突させることが出来ない様にする (4) Animation GIF や動画などの代替技術を使う
- 12. 実用的な攻撃が成功する条件の検証 1. delimiter の注入が成功する条件 --boundary text とその前後の[CRLF]の間が空白文字だけであること ※RFC と違って Gecko は --boundary text の前に スペースがあっても構わない
- 13. 2. 注入された body-part を攻撃者にとって有効なものにする ための条件 以下のいずれかが出来る必要がある ・ body part の Content-* ヘッダ注入できる ・ multi part の終端が注入できる ・ 攻撃者の注入した文字列の後ろに意味のある文字列が 全く存在しない
- 14. 安全なライブラリの使い方(Web ブラウザへ返す応答の場合) (1) CGI.pm の multipart_init() ・毎回同じ boundary 指定で呼んでいるとバージョンに関係 なく危険。 ・を予測不能な boundary を指定して呼べば安全 ・boundary 指定無しで使う場合は、 Ver.3.50 以降では自動 で ラ ン ダ ム な boundary が 採 用 さ れ る の で 安 全 だ が 、 Ver.3.49 以前は毎回同じ boundary なので危険
- 15. (2) CGI.pm の CGI:Push ・比較的古くから安全（自動でランダムな boundary を生成） ・念のためソースを確認して boundary がランダムであるこ とを確認する (3) CGI:Simple の multipart_init() ・boundary 指定がある場合の条件は CGI.pm と同じ ・github の 2010 年 11 月 13 日の更新を含むバージョン以降 は boundary 指定無しでも安全
- 17. まとめ ・ HTTP レスポンス分割は HTTP ヘッダインジェクション だけじゃない。 ・ MIME の boundary は中身が予想できないならランダム にするのが正しいあり方。実際、メールクライアントはほ とんどがそのように実装されている。 ・安全なサンプルコードが少ないので注意。