本サイトは、快適にご利用いただくためにクッキー（Cookie）を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
夏のセキュリティカンファレンスと言えば…、皆さん何が思い浮かぶでしょうか？ Black Hat USA・Defconですよね（きっと）。MBSDのプロフェッショナル事業部からは、今年も複数メンバがこれらのカンファレンスに参加してきました。
例年通り様々な分野の発表があったのですが、この記事では（執筆者の趣味により）「Web系」の発表に焦点をあてて、その概要を紹介したいと思います。
■Cracking the Lens: Targeting HTTP's Hidden Attack Surface
PortSwigger（Burpの開発会社）のJames Kettle氏による発表です。
クライアントとWebサーバの間にある「見えないシステム」（リバースプロキシ、ロードバランサ、解析システムなど）の発見と、それらへの攻撃について扱ったセッションでした。
いくつかのタイプの脆弱性/攻撃が議論されていましたが、わかりやすいのは下記のようなHostヘッダを操作する手法です。
講演スライドP.11より
中間のリバースプロキシなどに脆弱性がある場合、上記の操作により、本来の対象に送信されるべきリクエストが「id.burpcollaborator.net」に送信されてしまいます。Hostヘッダの値を内部NWのホスト/ポート番号に変えることで、内部システムの攻撃に利用できます（SSRF）。Yahooの例ではプロキシの設定を行う内部のポートに接続可能であったとのことです。
ひとつ興味深いのは、このような中間のプロキシを使用しているのは個別のWebサイトだけではない、ということです。発表の中では、ISPがコンテンツのフィルタリングのために使用しているプロキシに同様の脆弱性があった、との話が紹介されていました。
脆弱性の検出の手法として提示されていたのは「Host: (テスターが制御するホスト名）」のような値を与えて、DNS Lookupが来るのを観測するという方法であり（OOB手法）、発表者が開発したBurpのExtensionである「Collaborator Everywhere」でもこの手法が使われています。
これはこの手の脆弱性を見つける上で非常に有効な手法ではありますが、違うアプローチもあり得ます。
筆者が過去に行ったWeb診断では、この手の脆弱性をタイムベースの手法で検出したことがあります。
GET / HTTP/1.1
Host: somehostI7zd3p
上記は弊社の診断ツールが送信したリクエストで、正常なホスト名の後ろにランダムな文字列を付加しています。正常/操作リクエスト間で若干の応答時間差（数秒）が観測されたことから、最終的に手動での調査により脆弱性を特定しました。
タイムベースの手法としては、「Host: (ルーティング不能なIPアドレス)」のような方法もありうるでしょう。
GET / HTTP/1.1
Host: 192.0.2.1
192.0.2.1はRFC 3330で定められた文書/例示用アドレスであり、普通は現実の機器に割り当てられることがありません。そのため、SSRF的な状況において、遅延を引き出せると期待できます。
外部への通信が完全に隔絶されているシステムにおいては、この種のタイムベースの手法が効果を発揮します。実際、筆者が上の脆弱性を見つけたのも隔絶されたシステムでした。一方、インターネットへのDNS通信が可能であるシステム（より一般的なシステム）ではOOB手法に大きな優位性があります。特に、時間差でDNS Lookupが発生するケースにおいてはOOB的な手法のみが選択肢となるでしょう。
なお、このような脆弱性を持つシステムはそれほど多くないと思われます。本研究はバグバウンティプログラムを実施している50,000程のサーバを調査対象としており、そのうち脆弱性が見つかったサーバは（ペーパーの記載内容から推測すると）数十程度であったようです。
とはいえ、本研究は、殆ど注目されていなかった脆弱性にスポットライトを当てて、さらにツールにより検出を自動化し、マススケールでの調査により脆弱性の実在を示した、という点で意味がある研究であったと思います。
発表の中では、Hostヘッダ以外を用いた攻撃や、キャッシュを通じて情報を窃取する攻撃などについても解説されていました。詳細は元の発表資料を参照ください。
■Don't Trust the DOM: Bypassing XSS Mitigations via Script Gadgets
Googleの研究者3氏（Sebastian Lekies、@kkotowicz、@sirdarckcat）による発表です。
世の中には様々なJavaScriptのライブラリがありますが、これらがXSS対策のバイパスにどのような悪影響を与えているか？というテーマです。
例えば、ある掲示板サイトがあるとします。投稿内容には一部のHTMLタグの使用が許されており、投稿されたHTML断片からJSを取り除くXSS対策（HTMLサニタイズ）をしています。ここで攻撃者が下記のようなHTMLを投稿します。
講演スライドP.20より
一部のサニタイザは、この投稿HTMLを無害だと判定するでしょう。これ単体でJSが実行されることはないからです。しかし、この掲示板サイトが「Ajaxify」というJSライブラリを使っていると話が変わります。なぜならば、（発表によると）Ajaxifyは「document-script」というクラスを持つdiv要素内容をJSとして実行してしまうからです。
つまり、HTMLサニタイズ処理の安全性は、WebサイトがどのようなJSライブラリを使っているかに依存してしまうということになります。なお、影響を受けるのはHTMLサニタイズ処理だけではありません。「document-script」のようなクラスは、ブラウザのXSSフィルタなどの補助的なセキュリティ機構のバイパスにも使用できる可能性があります。
本発表では、このようなライブラリごとの特殊な構文の中でXSS対策のバイパスに使えるものを「Gadget」と呼んでいます。16種類のJSライブラリ、そして4種のXSS対策（CSP、ブラウザのXSSフィルタ、HTMLサニタイザ、WAF）を対象とし、その多くについてGadgetを探し当てた、というのが発表の大きな眼目です。
ところで、筆者が過去に行った診断でも、モール型のECサイトの商品ページにサニタイズ関連のXSSを見つけたことがあります。
かなり昔の話で正確には記憶していませんが、概ね下記のようなものでした。
<img class="hoge" src="/foobar#"onerror=alert(location)//">
商品出品者（攻撃者）が上のような商品説明を登録します。商品説明には一部のHTMLタグが使用できる仕様です。上の値は単体で見ると無害なものですが、商品画面内のJSに「hoge」クラスのIMG要素を動的にいじる処理があり、この処理の不備（DOM Based XSS）によりXSSできる、というものでした。
発表の中でも言及があった通り、このような問題は「責任の所在が明確でない」という点でやっかいです。特に「document-script」クラスのような場合、ライブラリ側は「仕様です」、サニタイザ側は「そんな仕様知りません」という主張になるでしょう。要は、両者にはギャップがあり、それが攻撃者の付け入る隙になりうるわけです。
しかし、ひとつ言えるのは、HTMLサニタイザ側においては、id、class、data-*といったHTML属性を禁止（削除/置換）するのが望ましいということです。実際にそういう処理を行っているサニタイズ用ライブラリもあります。筆者が知っているものとしては、かつてのAnti-XSS Library（Microsoft）がその例です。
さて、発表の内容に話を戻します。発表者らは、Alexa Top 5000サイトを対象とした調査を行い、およそ20%（控えめに見積もって）のドメインにGadgetが存在することを確認したとのことです。これは、現実的な環境において、補助的なXSS対策（CSP、ブラウザのXSSフィルタ、WAF）が、それなりの比率で機能しない可能性を示しています。
最後に、本発表の印象をまとめます。本研究は、Webページに元々埋め込まれているJSによって既存のXSS対策が壊されているという（これまで余り議論されていなかった）事実を、著名なJSライブラリにおける多数の例（Gadget）の提示と、マススケールでの定量調査により示しました。XSS対策の難しさを示した、興味深い成果であったと思います。
■その他Web関連
Omer Gil氏。今年の2月くらいにPayPalの脆弱性として指摘されたものなので、知っている方は多いはずですが念のため。
Alvaro Munoz氏ら。JSON形式のDeserializerにおける攻撃について（.NET/Java）。最近Deserialize系の攻撃についての研究が進んでいます。発表のタイミングが少々厳しかったかなという気はしましたが、参考になる情報は多かったです。
A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!
Orange Tsai氏。SSRFにおけるURLフィルタのバイパス手法や、RCEの実例。RCEは、非常に単純化して言うと、Rails環境下において、SSRFによりmemcachedに細工したSerializeデータを挿入する手法でした。
■最後に
上で紹介したものは数多くのBriefingのほんの一部です。Black Hat USA、Defconともに100程度のBriefingが開かれ、筆者らの部署のビジネス領域（Web/NW/スマホ/IoT診断等）に関連するものだけでも多くの発表がありました。内容についても、筆者が過去に参加した他のカンファレンスと比べて、ジャンルの幅が広く、質の高い研究成果が多く出されていたと感じました。
さらにBriefing以外にも様々な催しがあります。日本からの参加者にしても、Briefingを主目的にする人、実際に手を動かす体験型のコンテスト/ワークショップへの参加を重視する人（主にDefcon）、新たなセキュリティ商材を求めて企業ブースを訪ね歩く人（主にBlack Hat）、自分が開発したツールを展示したい人（Black Hat/Defcon）、交流を深めるためにパーティを渡り歩く人など様々です。
そんな様々な意義・楽しみ方のあるBlack Hat・Defcon、未参加の方は参加を検討されてみてはいかがでしょうか。
＜本ページに関するサービスの詳細＞
https://www.mbsd.jp/solutions/assessment/
関連ブログ記事
おすすめ記事
