XSSとCSRFとSSRFを最近のCVEと共に理解する
はじめに
セキュリティ・キャンプ2021のグループワークの活動で、リレー形式でブログを執筆していくことになりました。 前回のブログはこちらです。
今回のテーマはWebセキュリティ！
といっても私はWebに強くありません。書けることなんて限られています。なのでXSS、CSRF、SSRF辺りをCVEと共に見ていけたらなと思います。基礎的な攻撃手法なので知っている方も多いと思いますが、最近のCVEを選択したので少しは新たな学びがあるといいなと。
変なところがあったら言ってください。
XSS
XSS（クロスサイトスクリプティング）は動的に生成されるWebページにおいて、悪意のあるスクリプトが入り込んで実行されてしまう脆弱性です。
例えば、クッキーを取得して攻撃者のサーバーに送信するJavascriptをXSS脆弱性のあるサイトのURLに紛れ込ませれば、それをクリックした第三者のセッション情報などを盗み取れてしまいます。基本的にユーザーの入力をエスケープせずにそのまま使うことで発生するためOWASP TOP 10 2021ではInjectionに分類されています（CWEでも同様）。
CVE-2021-22931
Node.js before 16.6.0, 14.17.4, and 12.22.4 is vulnerable to Remote Code Execution, XSS, Application crashes due to missing input validation of host names returned by Domain Name Servers in Node.js dns library which can lead to output of wrong hostnames (leading to Domain Hijacking) and injection vulnerabilities in applications using the library.
16.6.0、14.17.4、12.22.4以前のNode.jsはリモートコマンド実行、XSSの脆弱性があり、Node.js dnsライブラリのドメインネームサーバーによって返されるホスト名の入力検証が欠落しているためにアプリケーションがクラッシュし、間違ったホスト名の出力（ドメインハイジャックにつながる）や、ライブラリを使用するアプリケーションに対するインジェクションの脆弱性につながる可能性があります。
Node.jsの最近の脆弱性ですね。DNSルックアップの際に悪意のある文字列を含んだドメイン名が返されると、エスケープ処理や検証をせずにアプリケーションへと渡してしまうため、XSS等のインジェクション攻撃を引き起こす可能性があるというものらしいです。XSSとは少しそれるのですがアプリケーション側の処理（"\x00"を0へとデコードしてしまうなど）によっては実際とは違うドメイン名になってしまうため、ドメイン名ハイジャックの可能性もあるとのことです。
詳細はHackerOneの報告を参照してください。ちゃんと理解できているか怪しいので間違いがあれば指摘してくださると助かります(>_<)
上記のようにXSS脆弱性などのインジェクション攻撃に対して最も一般的な対策法は、受け取ったデータをエスケープ処理させることです。今回の場合もエスケープ処理やドメイン名の検証をしていれば防げた脆弱性です。
また、XSSは多くのプロダクトで確認されているのでCVE取りたい方は狙い目の脆弱性ですね。
CSRF
CSRF（クロスサイトリクエストフォージェリ）は掲示板や問い合わせフォームなどにおいて本来拒否すべき他サイトからのリクエストを受理してしまう脆弱性です。
利用者がCSRF脆弱性のあるサイトにログインしている状態で悪意のあるサイトにアクセスすると偽のリクエストがCSRF脆弱性のあるサイトへ発行され、利用者の意図しない動作を引き起こしてしまします。利用者になりすましてDOS攻撃を行ったり脅迫的なメッセージを送信したりすることが考えられます。 OWASP TOP 10 2021ではBroken Access Controlに分類されています。
CVE-2020-35626
An issue was discovered in the PushToWatch extension for MediaWiki through 1.35.1. The primary form did not implement an anti-CSRF token and therefore was completely vulnerable to CSRF attacks against onSkinAddFooterLinks in PushToWatch.php.
1.35.1までのMediaWikiのPushToWatch拡張機能で問題が発見されました。プライマリフォームはアンチCSRFトークンを実装していなかったため、PushToWatch.phpのonSkinAddFooterLinksに対するCSRF攻撃に対して完全に脆弱でした。
MediaWikiは所謂ウィキソフトで、Wikipediaにも使われています。概要に書かれていますがこのCSRFはトークンを実装しなかったことに起因するものですね。 CSRFに対する一般的な対策方法はワンタイムトークンなど他者が推測困難な秘密情報を発行し、リクエストの際にその値を照合することです。また、CAPTCHA認証やパスワードの再入力もCSRF対策には有効です。
SSRF
SSRF（サーバーサイドリクエストフォージェリ）は、本来ではアクセスできない内部サーバーに公開サーバー経由でリクエストを送ることで内部サーバーを攻撃できてしまうという脆弱性です。
公開サーバーから内部サーバーへはアクセスできるが利用者からは内部サーバーへアクセスできないような場合を考えてみてください。もし公開サーバーのWebアプリケーションにユーザーが入力したURLの内容をプレビューするような機能があったとすると、そこに内部サーバーのIPアドレスやドメインを指定することで内部サーバーの情報を読み取れるかもしれません。 OWASP TOP 10 2021では新たに10番目にServer Side Request Forgeryとして追加されました。
CVE-2021-25640
In Apache Dubbo prior to 2.6.9 and 2.7.9, the usage of parseURL method will lead to the bypass of white host check which can cause open redirect or SSRF vulnerability.
2.6.9および2.7.9より前のApacheDubboでは、parseURLメソッドを使用すると、ホワイトホストチェックがバイパスされ、オープンリダイレクトまたはSSRFの脆弱性が発生する可能性があります。
Apache DubboというRPCフレームワークの脆弱性です。書いてある通り、parseURLがホワイトホストチェックをバイパスしてしまうバグによるものですね。 SSRFに対する一般的な解決方法はURLがユーザーに許可されていないサーバーを指定していないかを完全に検証することです。しかし技術的に難しい場合も多いので可能であれば外部からURLを受け取らないようにするか、ホワイトリストによるチェックが安全。ただ、仕様との兼ね合いで難しいことも多いのが現状です。
完全な対策が難しいため、ちょっと前から注目を集めている脆弱性でもあります。
まとめ
CVEと共に理解すると言っておきながらおまけ程度にしか書けていませんね。
セキュリティキャンプのレポートだったり講義の宿題だったりとタスクがたまっていたからとでも言い訳しておきます。次はもっと頑張ります（多分）。
ちなみにSSRFについては徳丸さんのブログがとても分かりやすかったです。参考文献に載せているのでどうぞ……。
OWASP TOP 10も更新されたことだしここらで本格的にWEBセキュリティについて勉強しておきたいですね。
参考文献
OWASP Top Ten Web Application Security Risks | OWASP
クロスサイトスクリプティング（XSS） | トレンドマイクロ
クロスサイトリクエストフォージェリ（CSRF） | トレンドマイクロ
安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構
