TL;DR
- 1つのブラウザ、1つのプログラミング言語、15個の { Web Framework, HTTP Client ライブラリ, Email ライブラリ / Web Service 等} で脆弱性を見つけました。
- 見つけた脆弱性は、全て 1つの観点で発見した (多分 50-80 くらいのプロダクトの調査をした)。
- RFC の記載では、(かなりわかりにくく)この問題に対する要件が記載されており、WHATWG > HTML Spec の方はしっかりと書かれているといった状況にある。
- この問題は、
Content-Disposition
のfilename
,filename*
というフィールドを明確なターゲットとしている。 - この問題は、 HTTP Request / Response / Email の箇所で影響がそれぞれ変わる。
- これらの攻撃ベクトルの明確な攻撃対象として、
Content-Disposition
(のfilename
,filename*
) を見ている人は現在はあまりいない。 - OWASP の刊行物でこのあたりをちゃんとまとめているのはパッと見ない。 ASVS ではこれに関する Issue が立てられている。
Content-Disposition
のfilename
,filename*
はちゃんとエスケープしましょう。filename
:"
-->\"
or%22
\r
-->\\r
or%0D
\n
-->\\n
or%0A
filename*
:- ちゃんとフォーマットを守って URL Encode する
はじめに
どうも、涼宮カルビの牛角です。
この記事では、2018-2022 のリサーチ結果で発見した 脆弱性に関して書いていきます。 リサーチ期間が非常に長くなっていますが、単純にやる気のアップダウン等が入り混じって調査していない期間が長くなっただけです。実際の調査期間は 3ヶ月-半年程度です。
リサーチの結果、以下のプロダクト(?)で脆弱性を発見しました。
- 1個の ブラウザ
- 1個の プログラミング言語
- 15個の {Web Framework / Library / Web Service } (あえてぼかすために混ぜてます)
見つけた問題は大きく以下の3つに分かれます。
- HTTP Request における multipart/form-data > Content-Disposition 上の
filename
のエスケープ不足による、ペイロード生成時のコンテンツ改竄の脆弱性 - HTTP Response における Content-Disposition ヘッダ上の
filename
,filename*
のエスケープ不足による、Reflect File Download の脆弱性 - Email の multipart > Content-Disposition における
filename
のエスケープ不足によるコンテンツ改竄の脆弱性