はじめに
こんにちは！CTOのはせがわです。
先日公開された、Flatt Securityさんのブログ「開発者が知っておきたい「XSSの発生原理以外」の話」、おもしろいですね。このXSSの記事に限らず、Flatt Securityさんのブログは役に立つ記事が多い*1ので、個人的には記事が公開されるのを毎回楽しみにしています！*2
たしかに、XSSの脅威についてはなかなか理解してもらうことが難しく、また一般的にはSQLインジェクション等と比べても脅威が低く見られることも多いため、XSSの脅威について少し掘り下げて考察したいと思います。
なお、この記事は「XSSの発生原因くらいは知ってるよ」という人を対象にしています。「XSSって何だっけ」という方は クロスサイトスクリプティング対策 ホンキのキホン (1/3)：CodeZine（コードジン） などの記事を参照してください。
技術的な面からの解説
XSSの本質は、「攻撃者の作成したJavaScriptがターゲットとなるWebサイト上で動作する」ということなので、alertを表示する以外であっても本来の開発者がJavaScriptを用いて実現できることは攻撃者も自由に行えます。
例えば
- ニセのログインフォームによるフィッシングやニセの情報の表示
- 同一サイト上の機密情報を読み取って攻撃者の手元に送信
- Cookieに格納されているセッション情報を読み取って攻撃者の手元に送信*3
- LocalStorageに保存されているJWTなどの機密情報の漏えい
などがXSSの典型的な脅威の例としてよく挙げられており、またより高度な技法として
- JavaScriptによるキーロガーの設置
- 自動フィルインで入力された項目の奪取
- ServiceWorkerによる攻撃の永続化
などが先に紹介したFlatt Securityさんのブログ記事でも紹介されています。
それ以外にも、自社が運営している same-site *4 な他のWebアプリが SameSite=lax なCookieによってのみCSRFから守られている*5場合に、それを回避するための踏み台として利用される可能性などもあります。
これらは、「JavaScriptによってどれだけの悪用が可能か」を一般化して考えたものであって、実際のWebサイトでのXSSではそれぞれのサイト固有の性質により脅威が異なります。では、実際のWebサイトにおけるXSSの脅威はどのように考えればいいのでしょうか。
実際のWebサイトでのXSSの脅威はどう考えればいいのか
XSSは受動的攻撃なので、XSSによってそのサイトにどれくらいの被害が発生するかは「XSSが発生するURLに実際にどれくらいの人がリーチするか」に大きく依存しています。
例えば、Webメールにてログイン後最初に表示される受信メール一覧表示の画面に蓄積型のXSSがあるとすると、間違いなく利用者はその画面を開くことになるので、XSSが悪用されたときには確実に被害にあうユーザーが出てくることが予想できます。また、反射型のXSSは一般的には蓄積型に比べ被害にあうユーザーは少ないと想定できるものの、それが知名度や話題性のあるサイトであればSNS等でXSSのURLが拡散されることで多数のユーザーが被害にあうこともあり得ます。
蓄積型のXSSであったとしても、直接URLでアクセスできずログイン後にいくつも操作をしなければたどり着かない、日常的に使われないような機能に存在している場合にはそれほど大きな被害にはつながらないと考えられます。
また、被害の大きさを決定づける別の要素としては、「JavaScriptを用いることでそのサイトに対してどのようなことが行えるか」があります。
例えば、検索フォーム以外は静的コンテンツというWebサイトでのXSSであれば、検索結果にニセ情報を表示するといった程度の被害が現実的なところかと思います。一方、XSSが存在するのがWebメールであれば、JavaScriptによってアドレス帳を盗み出す、JavaScriptによってメールを送信する、などがあり得ますし、クレジットカード番号を入力するECサイトであれば、JavaScriptによって入力されたカード番号を盗み出すといったことが考えられます。
このように、JavaScriptを用いることでそのサイトに対してどのようなことが行えるか、言い換えると、そのサイトのどのような機能をJavaScriptで悪用できるかで、被害の大きさが変わってくると言えます。
CVSSのような二軸で考えるなら、「XSSが発生するURLに実際にどれくらいの人がリーチするか」が攻撃の難易度、「JavaScriptを用いることでそのサイトに対してどのようなことが行えるか」が攻撃の影響に該当するのかもしれません（ここでは前者に「知名度によってはSNSで拡散されやすい」のような漠とした条件もいれているのでまったく定量的ではないですが)。
具体例
話が抽象的になってきましたので、過去実際に発生したXSSの具体例を見てみます。
2007年 Twitterの検索機能におけるXSS
少し過去になりますが、2007年8月にTwitterにて実装されたばかりの検索機能の一部にXSSが発見、公開されたことがありました*6。
検索機能のXSSという典型的な反射型のXSSだったのですが、このXSSを使って「Twitterに『こんにちはこんにちは』の文言とともにこのXSS自身のURLを書き込む」というJavaScriptが実行されたため、海外のユーザーも含め大量の「こんにちはこんにちは」というメッセージでTwitterのタイムラインがあふれました。
反射型のXSSでありながらもTwitterというWebサイトの投稿機能そのものを利用して拡散することで、広い範囲のユーザーに影響が及んだ例でした。金銭的な被害や情報の漏えいなどはありませんでしたが、「自由にメッセージを書き込み他者の書いたメッセージを読んで楽しむ」というTwitterの本質的な機能が阻害されたということで、脅威という点では小さくはないと考えられます。
2021年 EC-CUBEのXSSによるクレジットカード情報の漏えい
2021年に公表されたEC-CUBEのXSS*7は、ショップ管理者が注文情報を確認する箇所にXSSがありました。攻撃者が細工した注文を行うことで、ショップ管理者が注文情報を閲覧するときに管理画面上でスクリプトが発動し、クレジットカード番号の奪取まで行われるといったものでした。蓄積型のXSSであることに加え、XSSの存在している箇所は確実に管理者がアクセスする機能であったこと、ECサイトという性質上クレジットカード情報も扱っているというもので、実際にクレジットカード情報の漏えいといった被害の発生が確認されています。
加えて、EC-CUBEではショップ管理者はブラウザー上からデザインのカスタマイズをテンプレートを直接編集して行うことができます。このとき使用されているテンプレートエンジンTwigではPHPのコードを呼び出すこともできるので、ブラウザー上からPHPを呼び出すコードが配置できる、つまりXSSがあれば攻撃者は簡易的なWebShellをEC-CUBEのサーバー上に設置できるといった条件もそろっていました*8。
このように、条件が重なることでXSSでありながらもSQLインジェクションなどと匹敵するような被害が発生することもありました。
XSSを用いた任意コード実行 / XSS to RCE
さきに紹介したEC-CUBEのXSSのように、XSSを用いてサーバー側で動作するコードを配置しそれを実際にサーバー上で動作させる、XSS to RCE (あるいはRCE via XSS)と呼ばれる攻撃手法が近年よく見つかっています*9。
ブラウザー経由でサーバー上にファイルをアップロード可能な機能を持っているCMSにおいて、そのファイルがサーバー上でPHP等のコードとして実行される経路がある場合に、単なるXSSで終わらずにサーバー上での任意コード実行となり、WebShellの設置などにつなげられるといった攻撃手法です。
従来であればXSSとは「ブラウザー上で任意のJavaScriptコードが実行される」と認識されていたものが、サイトの性質によっては「サーバー上で任意コードが実行される」へと、考えを改める必要がでてきたと言えます。
まとめ
現実のサイトのXSSの脅威について、alert を表示する以上についてどのように考えればいいかを検討してみました。XSSの脅威はサイトの性質によって大きく異なるのですが、それを考えるための要素としては
- XSSが発生するURLに実際にどれくらいの人がリーチするか
- JavaScriptを用いることでそのサイトに対してどのようなことが行えるか
の2点があると言えるのではないかと思います。
特に、前者として「サイト管理者が確実にアクセスする機能にXSSがある」、後者として「サイト管理者はブラウザー上の操作によってサーバー上で実行されるコードをアップロードできる」のような条件が重なると、XSSと言えどSQLインジェクションなどの能動的攻撃と並ぶ大きな被害が発生する可能性があります。
弊社の脆弱性診断でXSSを見つけた際には、上記のような2点を考慮しつつも、診断する側としては必ずしもそのサイトの使われ方を認識していない、サイトの全機能を把握していないといったことから、ある程度決め打ちで脆弱性の脅威を判断せざるを得ません(XSSに限らず、発見されたあらゆる脆弱性がそうなります)。ですので、脆弱性診断の結果を受け取った皆様には、できればご自身のWebサイトの特質に合わせて脅威を再考するとともに、診断の結果として書かれている脅威と乖離がある場合には我々にお伝え頂けますと、今後のよりよいサービスの提供につながるのではないかと思います。Webを安全なものにしていくために、みなさまのご協力を頂けますようお願いいたします。
本稿がみなさまのXSSへの理解につながれば幸いです。 Enjoy XSS!!
*1:役に立つかどうかには個人差があります。効果・効能・お役立ちを保証するものではありません。
*2:個人としての意見であり会社としての公式な見解ではありません。
*3:余談ですが、サイト上でphpinfoが動いているページがあれば httponly のついたCookieもJavaScript経由で取得可能であるという攻撃手法が知られています。
*4:「same-site」と「same-origin」を理解する
*5:SameSite cookies - HTTP | MDN
*6:twitterにセキュリティホールが発覚、日本人ユーザーを中心に「はまちちゃん」だらけに:らばQ
*7:ECサイトのクロスサイトスクリプティング脆弱性を悪用した攻撃 - JPCERT/CC Eyes | JPCERTコーディネーションセンター公式ブログ
*9:発見した0dayについての技術的解説 - EC-Cube, SoyCMS, BaserCMS - Flatt Security Blog