🔰ハッカーにブラウザへの命令権は渡さない🙀XSSを対話で理解する🔯ミカと教授のサイバーセキュリテイ🖥️第1回

入力欄からプログラムが侵入する

ミカ「教授、XSSとは何でしょうか。名前だけでは、何をする攻撃なのか想像できません」
教授「簡単にいえば、Webサイトの入力欄などに悪意のあるスクリプトを紛れ込ませ、それを見た人のブラウザで実行させる攻撃だよ」
ミカ「入力欄は、名前や文章を入力する場所ですよね。そこにプログラムを入れられるのですか」
教授「入力欄は、人間から見れば文章を書く場所だ。しかし、コンピューターから見れば、文字を受け取る場所にすぎない。『山田太郎』も『こんにちは』も、ブラウザへの命令も、最初はすべて文字列として入ってくる」
ミカ「入口では区別されていないのですね」
教授「そうだ。受け取った文字列をWebサイトがそのまま画面に表示すると、ブラウザが文章ではなくプログラムとして解釈することがある。それがXSSの入口になる」
ミカ「受付で身分証明書を確認せず、全員を事務室まで通してしまうようなものですね」
教授「しかも、事務室に入ってから『私は設備担当者です』と言われると、ブラウザは素直に鍵まで渡してしまう」

実際のスクリプトを見てみる

ミカ「具体的には、どのようなスクリプトが使われるのでしょうか」
教授「XSSの学習では、危険な処理ではなく、警告画面を表示するだけの簡単なスクリプトがよく使われる。たとえば、次のようなものだ」

<script>
  alert('XSSが実行されました');
</script>

ミカ「これを入力すると、どうなるのですか」
教授「Webサイトが安全な処理をせず、そのままHTMLへ埋め込むと、ブラウザに『XSSが実行されました』という警告画面が表示される」
ミカ「警告を表示するだけなら、それほど怖くありませんね」
教授「この例は、スクリプトが本当に実行されたことを確認するための安全な実験だ。警告画面を出せるということは、別のJavaScriptも実行できる可能性がある」
ミカ「玄関の鍵が開くかどうかを確認するために、ドアを少し押してみた状態ですね」
教授「そうだ。警告画面そのものが被害なのではない。外部から入力された命令を、ブラウザが実行できてしまったことが問題なんだ」

ブラウザはなぜ実行するのか

ミカ「ブラウザは、なぜ怪しいスクリプトだと判断しないのでしょうか」
教授「ブラウザは、誰がそのスクリプトを書いたのかを知らないからだ。正規の開発者が書いたものなのか、攻撃者が入力欄に入れたものなのか、完成したHTMLを見ただけでは区別できない」
ミカ「命令の形になっていれば実行するのですね」
教授「そうだ。ブラウザは命令に忠実だ。『これは少し怪しいから、今日は実行しないでおこう』とは考えてくれない」
ミカ「仕事は速いけれど、空気を読まない職員ですね」
教授「空気は読まないが、HTMLは驚くほど正確に読む」

お問い合わせフォームで起こるXSS

ミカ「実際のWebサイトでは、どこで起こりやすいのでしょうか」
教授「たとえば、会計事務所のお問い合わせフォームを考えてみよう。普通の利用者は、相談内容に『会社を設立したので、税務顧問について相談したいです』と入力する」
ミカ「通常のお問い合わせですね」
教授「ところが、攻撃者が相談文章の代わりに、先ほどのようなスクリプトを入力する。その内容がデータベースへ保存されたとしよう」
ミカ「保存した瞬間に実行されるのですか」
教授「保存しただけでは、通常は実行されない。問題は、事務所の職員が管理画面を開いたときだ」
ミカ「管理画面にお問い合わせ内容が表示されますね」
教授「その表示処理が安全でなければ、保存されていたスクリプトが職員のブラウザで実行される」
ミカ「職員は、お問い合わせを読もうとしただけですよね」
教授「そうだ。メールを開封したつもりが、手紙の中から小さな作業員が出てきて、勝手に事務所の中を歩き始めるようなものだ」
ミカ「お問い合わせフォームが、管理画面への裏口になるのですね」
教授「このように、悪意のある内容を一度保存し、あとから別の利用者のブラウザで実行させるものを、保存型XSSという」

管理画面だから安全とは限らない

ミカ「管理画面は職員しか見ないので、一般公開ページより安全なのではありませんか」
教授「むしろ、管理画面は注意が必要だ。外部から届いたお問い合わせ、顧客名、備考、コメントなどを、強い権限を持つ職員が閲覧するからだ」
ミカ「攻撃者本人のブラウザではなく、管理者のブラウザで実行させるのですね」
教授「そのとおり。管理者のブラウザなら、一般利用者にはできない操作が可能な場合もある」
ミカ「金庫番に怪しい荷物を開封させるようなものですね」
教授「『職員しか見ないから大丈夫』ではない。職員が見るからこそ、安全に表示しなければならないと考えるべきだ」

検索画面にも潜んでいる

ミカ「データベースに保存しなければ、XSSは起こらないのでしょうか」
教授「保存しなくても起こることがある。たとえば、Webサイトで『相続税』と検索すると、『相続税の検索結果』と表示されるページがあるだろう」
ミカ「よく見かけます」
教授「検索語をURLから受け取り、そのまま画面へ表示している場合、細工された検索語を含むリンクが作られることがある。利用者がそのリンクをクリックすると、検索結果の画面でスクリプトが実行される可能性がある」
ミカ「検索語を画面に返しただけなのに、攻撃になるのですか」
教授「そうだ。このように、送られてきた内容をすぐ画面へ返すことで発生するものを、反射型XSSという」
ミカ「保存型は事務所に置かれた時限装置、反射型は投げ返したボールの中に仕掛けが入っているようなものですね」
教授「少々物騒だが、違いはよく表している」

XSSによって何をされるのか

ミカ「XSSが成立すると、警告画面以外には何をされる可能性がありますか」
教授「本物に似た偽のログイン画面を表示されたり、ページの内容を書き換えられたり、別の危険なサイトへ移動させられたりする可能性がある」
ミカ「正規のWebサイトを開いているのに、偽画面が出るのですか」
教授「それがXSSの怖いところだ。利用者は正規サイトのURLを見ているため、表示された画面も本物だと思いやすい」
ミカ「正規の建物の受付に、偽の職員が座っている状態ですね」
教授「さらに、ブラウザから読み取れる情報を盗まれたり、ログイン中の利用者に代わって操作されたりする危険もある」
ミカ「単なる表示のいたずらではないのですね」
教授「そうだ。信頼されているWebサイトの中で、攻撃者の命令が実行されることが問題なんだ」

PHPの基本対策

ミカ「PHPでは、どのように防ぐのでしょうか」
教授「普通の文章としてHTMLに表示する場合は、htmlspecialchars()という関数を使うのが基本だ」
ミカ「以前出てきた関数ですね」
教授「この関数は、HTMLで特別な意味を持つ記号を、安全に表示できる文字表現へ変換する」
ミカ「スクリプトを削除するのですか」
教授「削除するというより、命令ではなく文字として扱える形に変えると考えたほうがよい」
ミカ「先ほどのスクリプトを入力しても、警告画面は出ず、入力された内容が文字として画面に表示されるのですね」
教授「そのとおり。ブラウザに『これは実行する命令ではなく、画面に見せる文章です』と伝えるわけだ」
ミカ「俳優が舞台で『非常口を開けろ』と言っても、劇場の非常口は開かない。あくまでセリフとして扱うのですね」
教授「よい例えだ。htmlspecialchars()は、命令をセリフへ変える通訳のようなものだ」

なぜ引用符も変換するのか

ミカ「htmlspecialchars()では、ENT_QUOTESやUTF-8も指定していましたね」
教授「ENT_QUOTESは、シングルクォートとダブルクォートの両方を安全な文字へ変換するための指定だ。引用符はHTML属性の境界として使われるため、対策が必要になる」
ミカ「UTF-8は文字コードですね」
教授「そうだ。日本語を含む現在のWebサイトでは、通常UTF-8を使う。つまり全体としては、『この文字列をUTF-8として扱い、HTMLで特別な意味を持つ記号を安全な表示用文字へ変えてください』という処理になる」
ミカ「長く見えましたが、それぞれ仕事があったのですね」
教授「税務申告書と同じだ。意味のない欄に見えても、たいてい何かの役割がある」

入力時に削除すればよいのか

ミカ「危険な文字が入力された時点で削除すればよいのではありませんか」
教授「入力チェックも必要だが、それだけに頼るのは危険だ。攻撃方法をすべて予想し、危険な文字列だけを完全に見分けるのは難しい」
ミカ「それでは、どう考えればよいのでしょうか」
教授「入力時には、文字数、形式、必須項目などを確認する。そして画面に表示するときには、表示場所に応じて安全な形へ変換する」
ミカ「入口で確認し、部屋へ入れるときにも確認するのですね」
教授「そうだ。データベースから取り出した内容も、過去に保存されたものだから安全だとは限らない。外部から来た可能性のあるデータは、出力時にも注意する」

SQLインジェクション対策とは別物

ミカ「データベースにはプリペアドステートメントを使えば安全だと聞きました。それでXSSも防げますか」
教授「そこは別の問題だ。プリペアドステートメントは、主にSQLインジェクションを防ぐ。データベースへの命令と、保存するデータを区別するための対策だ」
ミカ「XSSは何を区別するのですか」
教授「ブラウザへの命令と、画面に表示する文章を区別する」
ミカ「同じ入力データでも、データベースへ入れるときと、画面へ出すときで危険が違うのですね」
教授「そのとおり。金庫の鍵を頑丈にしても、受付に偽の職員が座る問題までは解決しない。それぞれ別の対策が必要だ」

htmlspecialchars()だけで完全なのか

ミカ「それなら、すべてにhtmlspecialchars()を使えば完全ですね」
教授「普通の文章をHTML本文へ表示する場合には、非常に重要な基本対策だ。ただし、表示場所によって必要な処理は異なる」
ミカ「どのような違いですか」
教授「HTML本文、HTML属性、URL、JavaScriptの内部では、文字の解釈方法が違う。特に、利用者が入力した内容をJavaScriptの中へ直接埋め込む設計は避けたほうがよい」
ミカ「どこへ出力するかによって、包装方法を変えるのですね」
教授「そうだ。また、ブログ編集画面のように一部のHTMLを許可する場合は、すべてを普通の文字へ変換するだけでは目的を果たせない。その場合は、許可された要素だけを残すサニタイズという処理が必要になる」
ミカ「関数を一つ覚えれば卒業、というほど単純ではないのですね」
教授「しかし、最初に覚える原則は単純だ。外から来たデータを信用せず、表示する場所に合わせて安全に処理することだ」

XSS対策の要点

ミカ「最後に、覚えておくことを整理してください」
教授「基本は次のとおりだ」
・入力フォームやURLから受け取った内容を、そのまま表示しない
・データベースから取り出した内容も、無条件には信用しない
・普通のHTML本文へ表示するときは、適切にエスケープする
・PHPではhtmlspecialchars()が基本的な対策になる
・入力チェックだけでなく、出力時にも対策する
・SQLインジェクション対策とXSS対策を混同しない
・一般公開ページだけでなく、管理画面でも安全に表示する
・表示場所によって必要な対策が異なることを理解する
ミカ「結局、人を疑うということでしょうか」
教授「人を疑う必要はない。疑うのは、外から届いた文字列だ」
ミカ「人は信用しても、データは確認する」
教授「税務の仕事でも同じだろう。お客様を信用することと、帳簿や証憑を確認しないことは別問題だ」
ミカ「なるほど。急に身近な話になりました」

お客様の声と命令を区別する

ミカ「XSSは、もっと難しい攻撃だと思っていました」
教授「高度な攻撃方法はいろいろあるが、基本的な仕組みは難しくない。文章として受け取るべき内容を、ブラウザが命令として実行してしまう。それがXSSだ」
ミカ「開発者の仕事は、文章と命令をきちんと区別することですね」
教授「そのとおり。お問い合わせフォームでは、お客様の声を受け取らなければならない。しかし、ブラウザへの命令権まで渡す必要はない」
ミカ「お客様は大切ですが、入力値には受付で身分証明書を見せてもらう、と」
教授「そして、管理画面へ通す前には手荷物検査もする」
ミカ「ずいぶん警戒される文字列ですね」
教授「文字列は気を悪くしない。遠慮なく検査すればよい」
XSS対策の本質は、特別に複雑な技術ではありません。
外部から来た内容をそのまま信用せず、表示するときに、命令ではなく文字として扱う。
お客様の声は、きちんと受け取る。
しかし、ブラウザへの命令権までは渡さない。
それが、安全なWebサイトを作るための第一歩です。