🔰ハッカーは「ログイン済みのあなた」を狙っている🔯ミカと教授のサイバーセキュリテイ🖥️第3回

CSRF――本人がログインしていることを、攻撃者に利用される

ミカ「教授、前回のSQLインジェクションでは、入力欄からデータベースへ命令が入り込む話でしたね」
教授「そうだった。では今日は、もっと妙な攻撃を勉強しよう」
ミカ「もっと妙？」
教授「攻撃者があなたのパスワードを知らなくても、あなたがログインしていること自体を利用する攻撃だ」
ミカ「パスワードを盗まないのですか」
教授「盗まなくてもよい場合がある」
ミカ「では、誰が操作するのですか」
教授「ミカだ」
ミカ「私が攻撃者なんですか？」
教授「違う。被害者でありながら、知らないうちに攻撃の実行役まで務める」
ミカ「待遇が悪すぎませんか」
教授「しかも無給だ」

これは何を狙う攻撃なのか

ミカ「CSRFとは、何の略ですか」
教授「Cross-Site Request Forgery。日本語では『クロスサイト・リクエスト・フォージェリ』などと呼ばれる。Forg­eryは偽造という意味だ」
ミカ「何を偽造するのですか」
教授「簡単に言えば、本人から送られたように見えるリクエストだ」
ミカ「本人から送られたように？」
教授「たとえばミカがネット銀行へログインしているとしよう」
ミカ「嫌な予感がします」
教授「その状態で、攻撃者が用意した別のWebページを開く」
ミカ「銀行とは関係のないページですね」
教授「そうだ。しかし、そのページから銀行サイトへ何らかの操作要求が送られるよう細工されていたとする」
ミカ「私は銀行サイトを操作したつもりがないのに？」
教授「銀行側から見ると、ミカのブラウザから要求が届く。そして条件によっては、ブラウザが持っているログイン済みの認証情報も一緒に使われてしまう」
ミカ「つまり、狙われているのはパスワードではなく……」
教授「ログイン済みという信用状態だ」
ミカ「ハッカーは鍵を盗まず、鍵を持っている私にドアを開けさせるのですね」
教授「今日の核心にもう到着したな」

なぜ成立するのか

ミカ「でも、どうして別のサイトから送られた要求なのに、銀行は受け付けるのですか」
教授「Webの仕組みでは、ブラウザがログイン状態を維持するためにCookieなどの情報を利用する」
ミカ「一度ログインしたら、ページを移動するたびにパスワードを入力しなくてよいのは、そのためですね」
教授「そうだ。便利な仕組みだ」
ミカ「また『便利』が危険の入口ですか」
教授「セキュリティの授業では、便利という言葉が出たら少し身構えるとよい」
ミカ「買い物番組とは逆ですね」
教授「ログイン後、ブラウザは同じサービスへアクセスするとき、必要な認証情報を自動的に利用することがある」
ミカ「そこで攻撃者は、自分でログインするのではなく、私のブラウザから要求を送らせる」
教授「そのとおり」
ミカ「銀行から見れば、本当に私のブラウザから来ています」
教授「だから、サーバー側が『ログインしている人から来た要求なら全部本人の意思だろう』と考えてしまうと危険なのだ」
ミカ「ログインしていることと、本人がその操作を望んだことは別ですね」
教授「非常に重要な区別だ。認証済みであることと、その操作を本人が意図したことは同じではない」

身近な例に置き換える

ミカ「もう少し身近な例にしてください」
教授「では、会社の社長室で考えよう」
ミカ「また社長が登場しました」
教授「社長は自分専用の印鑑を持っている。秘書は『社長の印鑑が押されている書類なら正式な指示だ』と考えている」
ミカ「普通ですね」
教授「ところが悪い人が、社長の机の書類の間に『私の会社へ100万円振り込め』という書類をこっそり挟んだ」
ミカ「社長は内容を見ずに印鑑を押してしまう」
教授「秘書は印鑑を確認して、『社長の正式な指示ですね』と処理する」
ミカ「社長自身は100万円を振り込もうとは思っていない」
教授「しかし、印鑑は本物だ」
ミカ「なるほど。CSRFでは、ログイン済みのブラウザが社長の印鑑のような役割をするのですね」
教授「そう考えると分かりやすい」
ミカ「攻撃者は印鑑を盗むのではなく、社長に知らない書類へ印鑑を押させる」
教授「そうだ」
ミカ「社長には、書類を読む習慣をつけてもらいたいですね」
教授「サイバーセキュリティとは別の研修も必要になりそうだ」

「怪しいリンクをクリックしただけ」が危険になる

ミカ「利用者は何をすると攻撃を受けるのですか」
教授「代表的には、攻撃者が用意したページやリンクを開くことがきっかけになる」
ミカ「見るだけでもですか」
教授「システムの作りによっては、利用者が意識して重要なボタンを押さなくても、Webページ側の仕掛けから別サービスへの要求が送られる可能性がある」
ミカ「私は猫の写真を見ているつもりなのに、裏で別の操作が行われる？」
教授「猫には罪はない」
ミカ「インターネットでは猫まで疑わなければならないのかと思いました」
教授「問題は猫ではなく、ページの仕組みだ」
ミカ「そして、私がその時ちょうど別サービスにログイン中だと危険が増す」
教授「そういうことだ」

成立すると何が起きるか

ミカ「CSRFが成功すると、具体的には何が起きますか」
教授「攻撃対象のサービスにどのような機能があるかによる。たとえば、登録情報の変更、設定変更、何らかの申込みや操作などが本人の意図とは違う形で行われる可能性がある」
ミカ「メールアドレスの変更なども怖いですね」
教授「重要な情報が変更されれば、その後のアカウント管理にも影響する」
ミカ「ネットショップなら？」
教授「配送先や設定が変更されるなど、サービスの設計次第でさまざまな影響が考えられる」
ミカ「企業の管理画面なら、さらに危険ですね」
教授「管理者としてログインしている人が狙われれば、一般利用者より大きな権限を悪用される可能性がある」
ミカ「つまり、偉い人ほど危険？」
教授「権限の大きいアカウントほど、攻撃されたときの被害も大きくなりやすい」
ミカ「会社では肩書が上がると部屋が広くなりますが、攻撃対象としても広くなるのですね」
教授「少なくとも権限は広くなる」

パスワードが盗まれていなくても安心できない

ミカ「被害に遭った人は、『パスワードは誰にも教えていないのに』と思いますね」
教授「そこがCSRFの分かりにくいところだ」
ミカ「パスワードを盗まれたわけではない」
教授「そうだ。攻撃者が本人になりすましてログインしたわけでもない」
ミカ「本物の本人がログインしている状態を利用された」
教授「だから、ログイン履歴だけを見ても、分かりにくい場合がある」
ミカ「アクセス元も本人のブラウザですものね」
教授「そのため、サービス提供側が『この操作は本当に、この画面から、本人の意思で送られたのか』を確認する仕組みが重要になる」

安全な範囲で仕組みを確認する

ミカ「実際の攻撃方法を試してみたいです」
教授「他人のサービスで試してはいけない」
ミカ「もちろんです」
教授「仕組みを理解するだけなら、コードを書かなくてもよい。教室で考えてみよう」
ミカ「はい」
教授「まず、ブラウザに二つのタブがあるとする」
ミカ「一つは『A銀行』、もう一つは『怪しいニュースサイト』」
教授「銀行にはすでにログインしている」
ミカ「ログイン状態ですね」
教授「銀行側には『住所変更』という機能があるとする」
ミカ「はい」
教授「もし銀行側が、住所変更の要求について『ログイン済みかどうか』しか確認していなかったらどうなる？」
ミカ「怪しいサイトから送られた要求でも、私のブラウザが銀行への認証情報を使ってしまえば、銀行は本人からの要求だと思う可能性がある」
教授「正解だ」
ミカ「では銀行側が、『この住所変更画面を正規に開いた人しか知らない、一回限りの確認情報』も要求したら？」
教授「攻撃者のサイトは、その正しい値を簡単には用意できない」
ミカ「これがCSRF対策の考え方ですね」
教授「そうだ。攻撃の具体的な手順を覚えるより、なぜ正規画面から送られたことを確認する必要があるのかを理解するほうが重要だ」

プログラマーはどう防ぐか

ミカ「では、プログラマー側の対策を教えてください」
教授「代表的なのがCSRFトークンだ」
ミカ「またトークンですか。セキュリティの世界はトークンが好きですね」
教授「切符のようなものだと思えばよい」
ミカ「どう使うのですか」
教授「重要な操作を行うフォームなどに、正規の画面を経由した利用者しか持ちにくい、予測困難な値を含める」
ミカ「そしてサーバー側で、その値が正しいか確認する」
教授「そうだ。ログインしているだけではなく、その操作要求が正規の流れから来たかを確認する」
ミカ「攻撃者が勝手に要求を作っても、正しいトークンを持っていなければ拒否できる」
教授「それが基本的な考え方だ」

SameSite属性も重要

ミカ「Cookie側にも対策がありますか」
教授「ある。代表的なのがCookieのSameSite属性だ」
ミカ「同じサイト？」
教授「そうだ。他のサイトを経由したリクエストでCookieをどの程度送るかを制御するための仕組みだ」
ミカ「すると、攻撃者のサイトから銀行へ要求を送ったとき、ログイン情報を自動的に送りにくくできる」
教授「設定や操作の種類によって挙動は異なるが、CSRFのリスクを下げる重要な防御の一つだ」
ミカ「CSRFトークンとSameSiteのどちらか一つでよいですか」
教授「セキュリティでは、一枚の壁だけに期待しないほうがよい。必要に応じて複数の対策を組み合わせる」
ミカ「城壁、堀、門番ですね」
教授「そして門番が昼寝していないことも重要だ」

GETで重要な変更をさせない

ミカ「ほかには？」
教授「重要な状態変更を、単純なリンクを開いただけで実行できる設計にしないことも大切だ」
ミカ「URLを開くだけで『会員情報を変更しました』となるような作りは避ける」
教授「そうだ。閲覧と変更をきちんと分ける」
ミカ「見るだけの操作と、会社の状態を変える操作を同じ扱いにしない」
教授「さらに重要な操作では、パスワードの再入力や多要素認証など、追加確認を求めることも有効だ」
ミカ「100円の設定変更と1億円の振込を、同じ確認方法にしないほうがよいですね」
教授「1億円をワンクリックで動かせる会社なら、まずその設計会議を見学したい」

OriginやRefererの確認

ミカ「正規のサイトから来た要求かどうかは、ほかにも確認できますか」
教授「状況によっては、OriginやRefererといったHTTPヘッダーを使い、要求が想定したサイトから来ているか確認する方法もある」
ミカ「ただし、それだけに全部任せるのではない」
教授「そのとおり。サービスの構造や環境を考え、CSRFトークンなど適切な防御と組み合わせる」
ミカ「今回も『魔法の一行』はないのですね」
教授「セキュリティの記事で『これだけやれば絶対安全』と書いてあったら、その文章自体を少し警戒したほうがよい」

フレームワークの機能を使う

ミカ「Webフレームワークには、CSRF対策が用意されていることがありますね」
教授「ある。成熟したフレームワークには、CSRFトークンの生成や検証を支援する機能が用意されていることが多い」
ミカ「では、自分で全部作らなくてもよい」
教授「むしろ、十分理解せず独自方式を作るより、よく検証された標準的な仕組みを正しく使うほうがよい場合が多い」
ミカ「プログラマーは何でも自作したくなるものです」
教授「車輪を再発明してもよいが、セキュリティの車輪が走行中に外れると困る」

プログラマーが覚えておきたい基本

ミカ「今回も、開発者向けにまとめてください」
教授「では簡潔にいこう」
・状態を変更する重要な処理にはCSRF対策を実装する
・CSRFトークンなどで正規の操作経路からの要求かを検証する
・CookieのSameSite属性を適切に設定する
・重要な変更処理を単純なGETリクエストだけで実行しない
・重要度の高い操作には再認証や多要素認証を検討する
・OriginやRefererの検証を必要に応じて補助的に利用する
・利用しているフレームワークの標準CSRF対策を理解し、無効化しない
ミカ「最後が怪しいですね。便利だからと防御機能をオフにする人がいるのですか」
教授「『エラーが出たのでセキュリティ機能を無効にしたら動きました』という事件は、プログラマーの世界では時々起こる」
ミカ「火災報知器が鳴るので電池を抜いたようなものですね」
教授「しかも『静かになりました』と報告する」

経営者・利用者はどう防ぐか

ミカ「利用者側には何ができますか。CSRFはプログラム側の問題が中心ですよね」
教授「中心はサービス提供側の設計だ。しかし利用者にもできることはある」
ミカ「たとえば？」
教授「重要なサービスを利用した後は、必要に応じてログアウトする。特に共有パソコンでは重要だ」
ミカ「ログインしたままにしない」
教授「怪しいメールやSNSのリンクを不用意に開かないことも基本だ」
ミカ「ただ、怪しいかどうか分からないから困るのですが」
教授「だから、重要なサービスを利用している最中に、無関係なリンクを次々と開く習慣も見直したほうがよい」
ミカ「ネット銀行を開いたまま、『あなたは今日100万円当たりました』をクリックしない」
教授「100万円当たったという通知より、まず100万円減らないことを優先したい」

経営者が確認すべきこと

ミカ「経営者は何を確認すればよいでしょう」
教授「『当社にはファイアウォールがあります』だけで安心しないことだ」
ミカ「CSRFは会社のネットワークの外壁を破る攻撃とは違いますものね」
教授「そうだ。Webアプリケーションそのものの設計を見る必要がある」
ミカ「開発会社に何を聞けばよいですか」
教授「重要なWebシステムについて、CSRF対策が実装されているか、利用しているフレームワークの標準防御が有効になっているか、重要な処理に追加認証が必要か、といった点を確認するとよい」
ミカ「経営者自身がCSRFトークンを実装する必要はない」
教授「もちろんない。しかし、会社のWebシステムには、ログイン後の不正操作を防ぐ設計が必要だということは知っておくべきだ」

管理者アカウントほど慎重に

ミカ「会社のWeb管理画面を使う人には、特に注意が必要ですか」
教授「そうだ。管理者アカウントは権限が強い」
ミカ「商品を一件登録できる人より、全顧客情報や設定を変更できる人のほうが被害が大きい」
教授「だから、管理者には多要素認証を導入し、不要な権限を与えず、重要な操作には追加確認を入れるなど、より慎重な設計が必要だ」
ミカ「また最小権限の原則ですね」
教授「セキュリティでは、昨日覚えた原則が今日も働く。優秀な原則は働き者なのだ」

SQLインジェクションとの違い

ミカ「第2回のSQLインジェクションとは、かなり違いますね」
教授「整理してみよう」
ミカ「SQLインジェクションは、外部入力をデータベースへの命令として解釈させる」
教授「そうだ」
ミカ「CSRFは、ログイン済みの利用者のブラウザを利用して、本人が意図していない要求を送らせる」
教授「よくできた」
ミカ「SQLインジェクションは『命令とデータを分離する』」
教授「CSRFでは、『ログインしている』と『本人がその操作を望んでいる』を分離して考える」
ミカ「なるほど。今回のキーワードは『本人確認』だけでは足りない、ですね」
教授「そうだ。本人であることを確認した後にも、『この操作は本当に本人が望んだのか』という確認が必要になる」

セキュリティは「信用しすぎない」設計

ミカ「セキュリティを学んでいると、だんだん誰も信用できなくなりそうです」
教授「人を疑うのではない。仕組みの中で、確認を省略しないということだ」
ミカ「ログイン済みだから大丈夫」
教授「それだけでは不十分なことがある」
ミカ「自分のブラウザから来たから大丈夫」
教授「それも本人の意思とは限らない」
ミカ「リンクをクリックしたのは本人だから大丈夫」
教授「本人は、その先で別の要求が送られるとは思っていないかもしれない」
ミカ「信用ではなく、確認ですね」
教授「そのとおり。セキュリティで疑われているのは人格ではなく、通信だ」

ミカと教授の一言で締める

ミカ「教授、今日のCSRFを一言で説明してください」
教授「攻撃者が鍵を盗むのではなく、鍵を持っている本人の手を借りてドアを開けさせる攻撃だ」
ミカ「では、防御の一言は？」
教授「ログインしていることと、本人がその操作を望んでいることを同じだと思わないこと」
ミカ「なるほど。『本人のブラウザから来たから本人の意思です』ではだめなのですね」
教授「そうだ」
ミカ「ハッカーはパスワードだけを狙っているわけではない」
教授「むしろ、すでにログインしているあなたの信用を借りたいこともある」
ミカ「信用を勝手に貸し出されるのは困りますね」
教授「だからWebアプリケーションには、信用金庫より厳しい本人確認が必要なのだ」
ミカ「教授、それは税理士向けの駄洒落ですか」
教授「次回までに改善しておこう」

次回予告

第4回　ブルートフォース攻撃――「パスワードは、何回試せば開くのか」

ミカ「次は力ずくですか」
教授「名前どおりだ。賢く鍵を開けるのではなく、何度も試す」
ミカ「ずいぶん原始的ですね」
教授「コンピューターの世界では、原始的な方法でも秒速になると話が変わる」