「うちのWebサービス、会員が日記やメッセージを書けるユーザー機能があるから、最近サーバーのセキュリティを強化した」
「ログインはパスキーも設定して、二段階認証にしたし、もう大丈夫。」
情報漏えいのニュースが増えてきて、経営者は不安になりながらも、日々セキュリティを気にかけていると思います。
サーバーやプログラムが新しいか、ログインなどの認証を複雑にしたか、個人情報を持たないように整備したかなど、気にかける内容もサービスによって違うと思います。
その中で、今回一般的なユーザーが投稿できるWebサービスの話。
会員どうしがやり取りできる仕組みは、サービスの魅力そのもの。
口コミ、日記、つぶやき、メッセージ、プロフィールの自己紹介、メッセージの交換や、動画にテキストでメッセージを送る。
どれも、ユーザーが自由に文章を書けるからこそ、サイトが盛り上がります。
そして、ユーザーの盛り上がりは売上に直結するので、投稿できて参加もできるコンテンツを増やしたくなる。この気持ちは凄くわかります。
ただ、結論から言うと、会員が書いた文章を「そのままスマホやウェブサイトの画面に表示している」状態で無防備だと、1人の悪意ある攻撃者がプロフィールや日記を投稿するだけで、それを見た会員全員が、乗っ取られる可能性があります。
これを「蓄積型XSS（クロスサイト・スクリプティング）」と呼びます。煽りではなく、実際に行われる可能性のある攻撃です。
ログインの強化やサーバーを強くして、EDRを導入していても、この蓄積型XSSの危険性は、別の場所に開いています。
この記事では、その蓄積型XSSの仕組みと被害の大きさ、どこを防御するべきなのかを、専門用語をなるべく使わずにお伝えします。
実際のセキュリティ対策は人間のカラダに近い。風邪を引いて頭痛薬は飲まない。骨折をして風邪薬を飲みません。蓄積型XSSは、悪意のある内容がサービスの中に保存され、気が付かないうちに、それを見た会員のブラウザで実行されてしまう攻撃です。本人はいつもどおりサイトを使っている。
セキュリティと聞いて身構えずに、身近な人間のカラダや病気にあてはめながら考えてください。
最後に、私たちが実際にこの蓄積型XSSの可能性を発見して、その日のうちに本番に適用して防御をした記録も載せました。
この記事は特定の攻撃手法を伝える・広める目的として書いていません。他社のサイトで悪用をしないでください。他人のサイトで試すこと自体が、犯罪になり得ます。身近にセキュリティに詳しい人がいない中小企業の経営者の方が、どう守ればよいかを知るために書いています。
- 蓄積型XSSで、会員のブラウザで何が起きる可能性があるのか
- パスワードを盗まれなくても起こせる攻撃とその被害、そして広がりかた
- WAF(ワフ)やEDR、投稿用のエディタ設定だけでは止まらない理由
- どう守るのか。「表示する直前に無害化する」方法と、その無害化で既存のシステムが壊れないのか
- 制作会社や開発会社に、どう質問をすればいいのか
蓄積型XSSとは、どんな悪意なのか
蓄積型XSS。それは、会員が投稿した文章の中に「悪意のある命令」を紛れ込ませ、それを見た人のブラウザで実行させる攻撃です。
隠れてコソコソ仕込む卑怯な攻撃で、実際に被害にあうのはユーザーです。特に怖いのは、スタッフや管理者が悪意のある投稿を見てしまった場合です。管理画面の作り方によっては、そのスタッフや管理者の権限まで悪用される可能性があります。
ホームページは、HTMLという「裏側はただの文字だけど、人間が見たら画面が設計されて表示される」ように、できています。それを整えるのがCSSです。
設計図（HTML）の中には、文字や画像だけでなく、見ている人のブラウザに、こう動いて欲しいという指示する「命令（スクリプト）」も書けます。
画面がスクロールしたり、点滅したサイトを見たことがあると思います。そのように、こう動いてほしいと制作者が考えていて、ウェブサイトが出来上がります。
デザイナーや制作会社が作った場合は、問題にはなりません。コードを書いているだけなので。
ここで問題になるのは、会員が書いた文章です。投稿したり、コメントを入れたり、ユーザーが書く内容。
本来は「ただの文字」として表示されるべきものが、設計図（HTML）の一部として読まれてしまうと、文章に紛れ込ませた命令がそのまま動きます。そんな事まで、と思いたいのは分かりますが、会員が何かを投稿できる以上、それがすべて悪意がないとは限りません。
| 種類 | 何が起きるか | 被害が広がる範囲 |
|---|---|---|
| 蓄積型XSS | 悪意ある投稿がサービスの中に保存され、表示されるたびに実行される | その投稿を見た人全員 |
| 反射型XSS | 細工したリンクを踏ませ、その場で実行させる | リンクを踏んだ人 |
リンクを踏まなければ大丈夫だよ。これはユーザーも自分で注意ができますが、蓄積型が怖いのは、「待ち伏せ」ができること。
攻撃をしようとする側は、一度投稿するだけで済みます。
あとは、普段どおり、そのサービスを使っている会員が、その投稿を開くたびに被害者になります。
パスワードが盗まれなくても、会員は乗っ取られる
蓄積型XSS（クロスサイト・スクリプティング）で動いた命令は、「その会員本人として」サービスを操作する事ができます。
ここが、少し勘違いしてしまうところです。
「ログイン情報を保存するCookieは、盗めない設定にしてあると聞いた。パスワードを強固にしたから大丈夫と聞いた。」
その設定はとても大切で、たしかにCookieそのものの持ち出しは防げます。ログインとパスワードを強固にするのも大切です。そもそも、パスワードが漏れていなくても、乗っ取りは起きます。
XSSの命令が怖いのは、会員がログインしたままの状態で、そのログインした画面の中で動作をすることです。
わざわざパスワードやログイン情報を盗まなくても、本人が開けたドアの内側にいるのと同じ。最初からログインしたサイトの中で待ち構えています。
想定される被害は、たとえば次のようなものが考えられます。
- その会員になりすまして、メッセージを送る
- 登録メールアドレスや設定を書き換える
- 本物のページの上に、偽のログイン画面やカード入力画面を重ねて表示する
- 会員が見られる範囲の情報（やり取りの履歴、予約、残高など）を読み取って、外部へ送る
さらに、蓄積型のむかつくところが、会員どうしがやり取りできるサービスで、被害が自動で広がる形も組めてしまうということです。
感染した会員のアカウントから別の会員へ、命令入りのメッセージを送らせる。
受け取った会員も、また次へ送る。
人手をかけずに広がる、いわゆる「ワーム」です。昔はやった、5人に送らなければ不幸に・・・のチェーンメールの自動版と考えてください。
一方で、XSSだけで「サーバーの中の全会員のデータを一度に抜く」ことはできません。
被害は「見た人の分だけ、どんどん広がっていく」形です。
ただし、スタッフが使う管理画面に、会員の投稿がそのまま出ている場合や、スタッフが管理画面にログインしたままの同じブラウザで会員向けの画面を見ている場合は別で、スタッフの権限で全ての会員の情報に届く可能性があります。
そのため、ユーザーが見る画面だけではなく、管理画面の表示も、必ず確かめてください。
管理画面をトンネル化、そしてゼロトラストをかけて認証をかけて権限で絞る。Cookieもログも保存して、記録してある。でも、投稿者が投稿をした内容を管理画面で見ているシステムは必ず一度チェックしてください。
WAFやエディタの設定だけでは被害をおさえられない理由
入口の見張り役と、内部で怪しい挙動を捕獲する役、投稿画面の制限は「あくまでも補助」です。防御すべき本体は、表示する側、つまりユーザーが見る画面にあります。
投稿エディタで制限しても、迂回される
「投稿画面では、太字とリンクと画像しか使えないようにしてある」これは、普通に使うユーザーに対して行う制限です。
実際に、映画のワンシーンのハッキングや攻撃を見ていると想像してください。攻撃する側は、ログインして投稿用のエディターを使うことはあまり考えられません。ログインをしたあとで、画面の裏で送られている通信を、直接作って攻撃として送ってきます。明確に攻撃として理解してなければ送ってこないので、攻撃と言っています。無意識では仕込めません。
エディタの制限は、投稿者に対して、ブラウザの中だけで効果があります。
でも、サーバーに届く中身は、適切な防御をしていないと、自由に書き換えられてしまいます。
WAFは、正しい投稿まで止めてしまうことがある
WAFは、怪しい通信をサーバーの手前で止める門番です。WAFも設定していないサイトは、今の時代では 裸で北極にいて、寒いと言っているに等しいくらい。
WAFは、XSSらしい文字列を見つける機能も、もちろん持っています。絶対に設定をしなければいけない。
ただ、日記や口コミ、プロフィールを入れる箇所のようにもともと装飾つきの文章（HTML）を受け取る機能では、正しい投稿なのか、それが攻撃なのかの見分けがつきにくくなります。
WAFは本来、まず「数えるだけ」で様子を見て、正しい投稿を止めていないかを確かめてから「止める」に切り替える、という段階を経て設定します。ただ、大抵の中小企業のウェブサービスで、そこまでは行われていないでしょう。なぜなら、様子を見るにはユーザーに実際に使ってもらう必要があり、納品したときには分からないからです。
なお、サーバーに入れるEDRからは、会員のブラウザの中で動くXSSの命令はほとんど見えません。EDRは大切な守りですが、XSSの対策にはなりません。
写真のアップロードのような通信を、XSSと勘違いして止めてしまうこともあります。この「勘違い」は、後ほどの追記で、我々が実際に記録の中で見つけたものです。
だから、WAFは使う場所や通信の内容に合わせて、細かく調整する必要する。装飾つきの文章を受け取る場所でもWAFは活用できます。ただ、WAFだけに頼るのではなく、実際に表示するときにも必ず守る。両方とも必要です。
死守すべき本体は「表示する直前に無害化する」
ユーザーが書いたものは、画面に表示する直前に、必ず「無害な形」に整えてから出します。人のカラダでいえば、口に入れる前に消毒しておく、くらいの認識で大丈夫です。
無害な形にする方法は、表示する内容によって2通りです。
| 表示する内容 | 無害な形へ | たとえば。 |
|---|---|---|
| ただの文字（メッセージ、名前、自己紹介） | 記号をすべて「文字として」表示する形に置き換える | 手紙を、透明なケースに入れて見せる |
| 装飾つきの文章（日記、口コミの本文） | 使ってよい装飾だけを残し、それ以外を取り除く | 手紙から、ホチキスや刃物だけを抜いて見せる |
装飾つきの文章を整えるには、専用の部品（ライブラリ）を使います。
自分たちで「危ない文字列を探して消す」仕組みを作ることもできると思います。でも、人間がつくると必ずAIや悪意ある攻撃者が抜け道をみつけます。人間の手作業ではどうしても抜け道が残るからです。
「何を消して防御するのか」ではなく、「何なら残して表示してもよいか」を決めるのが、蓄積型XSSという待ち伏せする攻撃に対して、対処をする正しい考え方です。
- 保存するときと、表示するときの両方で整える（表示側が本体。保存側は、他の画面や別のシステムに生のまま渡さないため）
- 会員の名前やニックネームなど「短い文字」も対象にする。長文だけ守っても、名前の欄から入られる
- スタッフ用の管理画面の表示も、必ず同じ基準で確かめる。
対策をするときに、逆に壊れてしまうもの
無害化を入れると、正しい投稿の見た目が変わることがあります。かならず対策をして無害化した前と後で、必ず表示を見比べてください。
守りを強くすることと、普段の使い勝手を守ることは、両立させる必要があります。ユーザーが求めるのは利便性です。そしてその裏側で経営者は、ユーザーを守らなければいけません。
私たちが実際に確かめたのは、次のような点です。(一例)
- 過去の投稿に入っている文字の色や、画像のサイズ指定が消えていないか
- 絵文字や改行、空白が崩れていないか
- メッセージの中のURLが、今までどおりリンクとして押せるか
- ログインしていない人には画像を隠す、といった表示の切り替えが、そのまま動作をするのか
- 本番に入れる前に、テスト環境で、攻撃に使われる典型的な書き方を実際に投稿し、無害になることを確かめたか
最後の項目は、省かないでください。「修正したつもり」と「実際に自分でテスト環境で攻撃に使われる書き方で直ったことを確かめた」は別です。これは経営者ではなくても、外部に委託している業者やベンダーに確認してください。「防いだ処置は分かった。で、実際攻撃はためしたの？」と。自社のシステムや、持ち主の許可を得たテスト環境で行うのであれば違法にはならないため、テストは必須です。
制作会社・開発会社に聞いてほしいこと
「XSS対策はしていますか」と聞くと、たいてい「しています」と返ってきます。嘘ではないと思います。ただ、作る側が確かめるのは「仕様どおりに動くか」であることが多く、攻撃者の目線で試しているとは限りません。納品したあとの売上や事業を守る責任を負うのは、経営者自身です。だからこそ、具体的に聞いてください。
聞き方の例を記載しておきます。もし聞いて嫌われようが、蓄積型XSSを仕込まれるより、嫌われたほうが良い。
- 「会員が文章を書ける・投稿できる場所を、全部挙げてもらえますか。それぞれ、表示するときには、どう整えていますか」
- 「日記や口コミのように装飾を許している場所は、どのような部品(ライブラリ)を使い、何だけ表示する・残す設定にしていますか」
- 「スタッフ用の管理画面で、会員の投稿はどう表示されているのでしょうか？」
- 「納品前に、攻撃に使われる書き方で試してもらえましたか？もしくは古いライブラリを使っていませんか？」
ちょっと頼りないなと思う回答は、「エディタで制限しているので大丈夫です」「WAFを入れているので大丈夫です」「EDRを導入したので大丈夫です」という答えだけが返ってくることです。
すべて必要な防御ですが、今回のXSS、表示側の守りの代わりにはなりません。
正直、業務請負の契約書に、セキュリティの懸念をすべて書いておき、制作者がサイバー保険にはいって、何かあったら対応する気持ちでサイトを作ってあげてほしいなと思います。
我々の実話。
私たちが実際に対応したときの記録です。案件が特定されないよう、細部は伏せています。本当は、同じ状態のサービスを抱えている経営者のために、もっと詳しく伝えたいところです。ただ、運営に関わるサービスの安全性を守るため、詳細は伏せています。
どんな状態だったか。
ある会員制Webサービスでした。セキュリティの優先順位を経営者の方から相談をうけて、見直していたときのことです。
「絶対に死守しなければいけない。全部死守するのは当然。古いものがありませんか？」という問いを受けて、部品の古さがないのか、それは前のバージョンではないのかを調べていました。
そして、ユーザーが書いたものが、今この瞬間にどう画面に表示されているのかを調べました。すると、会員の書いた文章や、メッセージの本文が、保存のときも表示のときも、何も対策をされていない状態で表示がされていました。
誰でもカンタンに作れる会員アカウント1つで、文章やメッセージを見た会員全員のブラウザを、操作できる状態でした。
何をしたのか。
実際に、おこなった対策を記載しておきます。Webアプリケーション・システムで規模や対策は違うため、一例として見てください。
1. まず、WAFの設定だけで止められないかを確かめました。入口の見張り（WAF）の記録を見ると、XSSを見つける規則が、今回対応したシステムでは、写真アップロードの通信にも反応していました。この見張り役のWAFを「止める」に切り替えると、ユーザーが写真を上げられなくなる。設定だけの応急処置は使えないと分かりました。(投稿だけのWAFもありますが、即対応しなければいけない案件と判断しました。)
2. 文章の本文は、専用の部品(ライブラリ)で「表示してよい装飾・残してよいものだけを残す」形に整えました。保存のときに確認する、表示するときの両方で整えました。
3. メッセージは、先に記号を文字として表示する形に置き換え、URLだけをリンクに戻しました。
4. 会員の名前を、整えずに出していた画面が数か所あったので、あわせて直しました。
5. テスト環境で、攻撃に使われる典型的な書き方を、投稿画面を使わずに、直接裏側から送り、保存された中身と表示の両方で、無害になることを確かめました。
6. 実装した本人とは別の攻撃者の目線と防御する側の目線で、抜け道がないのか、正しい投稿の表示くずれをしていないのか点検しました。
7. 最後に実際の会社の方に見てもらい、動作に違和感がないのかの確認をおこないました。
行ってみて分かったこと
点検をして、攻撃ができる抜け道は見つかりませんでした。ただ、代わりに正しい投稿の見た目が変わってしまう箇所が3か所ほど見つかりました。
ログインしていない人に対して隠すべき表示が、一部の箇所では効かなくなっていたこと。投稿したときに、画像のサイズ指定が消えてしまっていたこと。文章の中の一部の書き方で、リンクが崩れていたこと。
どれも「守りとしては効果はあるが、ユーザーの使い勝手が落ちる」種類のものです。セキュリティも大切。でも、ユーザーの使い心地も経営者は大切にしています。UIやUXという言葉は知っていて、XSSは知らない経営者も多い。だから使い勝手を悪くするわけにはいきませんでした。
本番にアップをする前に直せたのは、修正をしたあとの工程を省かなかったからでした。実際に見つけたその日のうちに、本番まで反映しています。
社長・経営者に伝えたいこと
ユーザーが文章を書くことが、1つでもあるサービスなら、ログインの守りとは別に、この蓄積型XSSを必ず確かめてください。そして「対策しているだろう」の一言で終わらせず、「どこで、どう対策がされているのか」「それを、最後にいつ試したか」まで聞いてください。AIの時代で攻撃者側のスピードが凄くはやくなっています。でも、守る側のスピードもはやくなっています。最後に試したのが1年前なのか、1か月前なのか。売上と事業を守るために、その答えを把握しておいてほしいと思います。
まとめ
我々は、攻撃者側の視点にたち経営者の方の相談にのって、適切な防御をしています。
今回は、ユーザーが書いた文章をそのまま画面に表示をしていると、1つの投稿で、見た人全員のブラウザが乗っ取られる危険性があるということでした。
そして、これが蓄積型XSSです。
パスワードが盗まれなくても、会員本人として操作される可能性がある。
会員どうしがやり取りできるサービスなら、自動で被害が広がってしまうこともある。
そして、投稿画面の制限やWAFを導入していても、防御するには、「表示する直前に無害化する必要」がある。
会員が投稿やアップロードできる場所を全部しらべて、表示のしかたを一つずつ確かめる。
装飾をしてもいい場合は、専用の部品で「何を表示して、それ以外何を却下するのか」を決める。
修正をしたあとは、制作会社に、実際の攻撃の書き方で実際に試してもらい、正しい投稿が崩れていないかも見比べる。
もし、「うちのサービスの投稿機能、本当に大丈夫か見てほしい」
そう思ったら、ご相談ください。
会員が書ける場所を洗い出し、表示のしかたを一つずつ確かめるところから、お手伝いします。
外部から侵入を試みるだけが、セキュリティの調査ではありません。システムのコードや表示処理を確認することで、蓄積型XSSの危険がある箇所を見つけ、必要な対策につなげることができます。
不安を煽るつもりもありません。ただ、攻撃者の視点から見た時に、どう攻撃をするのかという視点を、我々はもつことが出来ます。そして、その視点で、経営者が事業で背負う責任を少しでも軽くできるよう、Webセキュリティの用心棒として役に立ちたいと考えています。
悪いのは、攻撃者でありハッキングをする人ですけどね。ユーザーのために、売上のために、そして事業のために、今のこのセキュリティの脅威に負けないでいきましょう。
出典・参考資料
記載に間違いがないように、下記の出典・資料を参考として記載をしております。