見出し画像

情報セキュリティ:クロスサイトリクエストフォージェリ(CSRF)の仕組みと対策


情報セキュリティ第一弾:クロスサイトリクエストフォージェリ

こんな方に見ていただきたい記事になります。
・ログインしっぱなしだと危険なの?
・安全な会員制サイトを作成したいけど、どんな脆弱性があるかよくわからない


1.CSRF(クロスサイトリクエストフォージェリ)の仕組み

前章の通り、CSRFはサイトにログインしている状態の時に起こりうるものです。
一例として下記のようなサイトを想定します。

 【ログイン状態でできること】
 ・会員情報の変更(住所・名前等)

 【会員情報変更時の動き】
 
①個人情報変更画面へ遷移
 ②変更したい住所をテキストボックスに入力する
 ③「変更」ボタンを押下する
 ④変更完了画面に遷移


 【CSRF攻撃のURL押下時の遷移先内容】

/* CSRFの仕組まれたパスのコード */
<form action="sample" method="post">
 <input type="textarea" name="address" value="東京都ほにゃらら">
 <input type="submit" value="変更">
</form>

 内容を簡潔に述べますと、
 テキストボックスに住所「東京都ほにゃらら」に設定して、
 「変更」ボタンを押したときの通信を実際に入力した値に関係なく行う処理が記述されています。
これが、パスワードの変更だったら、アカウント乗っ取りを企んでいる人の任意のパスワードに勝手に変更されて、、、

ここで、CSRFの攻撃が仕組まれたパスをクリックしたときの
ログアウトをしている人とログインしたままの人の動作を見てみましょう。

【ログアウトしている人がCSRFのパスを踏んだ時】
ログインした状態でないと実行不可の機能のため、
「もう一度ログインしてください」と言いった内容が表示されるなどし、
ログイン画面に遷移させられます。

【ログインしたままの人がCSRFのパスを踏んだ時】
ログイン情報が保持されているため、
パスを踏んだ時に「ログイン中ユーザ」が送信したとみなされ
意図していない会員情報に変更されます。

ここまでの話の内容を聞くと、平穏にネットサーフィンもできないと思う方もいるかもしれませんが、ご安心ください。
基本的にそのサイトにCSRFの脆弱性に対する策が完備されていれば起こりえないですし、利用する側としても対策があります。

特に個人情報の変更、ネットでの支払いにつながる内容の場合は、
上記の例のような「変更したい住所」情報の入力と「変更」ボタンを押して情報を変更する以外のロジックが組まれています。
(対策については次の章を見てください。)

2.CSRFへの対策①(ユーザ向け)

・再ログインを面倒と思わずに、使用後のサイトからはログアウトをする
・脆弱性がある可能性のあるサイトに登録しない(通販の場合、楽天市場やamazonなどの有名なところを選ぶ)
・SNSとかのおいしい話に安易に乗らない(URLを開かない)

3.CSRFへの対策②(サイト運営者・開発者向け)

以下の内容は実際に会員制サイトを作成、システム開発する方向けです。

先ほどの会員登録の例に沿って、遷移の流れを示すと下記のようになります。
正規ルート:A → B → C
攻撃ルート:Aの状態が保持(ログインしっぱなし) → D → C

システム上のユーザ名とその住所情報を保持しているデータベースの情報を変更する処理はそれぞれB→C、D→Cの遷移時に動きます。

この処理が不正ルートで行われることを阻止するための対策を紹介したいと思います。

簡単に言うと"アリババと40人の盗賊"です。
岩の扉は合言葉「開けゴマ!」を知らなければ開けないのと同じです。
「変更完了」という扉の先に進むために、正しい合言葉が必要で、
合言葉を知らない人は門前払いすれば良い!という例えが近いです。

「変更」ボタンを押した際に動くアクションには、
次に行う処理のために必要な情報が値として設定されている必要があります。

そこで脆弱性を無くすために、もともと必要であった変更内容(変更したい住所)とは別の送信値を用意します。
それも使いまわしではなく毎回変更される値である必要があります。
(開けゴマ!という合言葉がばれてしまってはその合言葉は効力をなくすからです。)

このような毎度変更される値を「nonce(ナンスまたはノンス)」といいます。
「Number used once」の略で一度きりの使い切り乱数です。
設定箇所は下記のようになります。

制御項目:
画面上では持っていない裏で保持している項目

画面項目:
画面上で保持している項目で、CSRFの攻撃コードのように自在に値を設定できる項目

つまり、Cに遷移する前の画面がBでない場合は
・ユーザがBの画面を表示している状態を保持している
・nonce生成を安全とされている32bitほどの桁数を天文学的な確率で
ぴったり当てる
という2つの奇跡が同時に起こらない限り不正なルートからは変更ができないようになります。​

※重要情報を扱うシステムとして必須※
データベースへの登録情報にかかわる処理が入るアクションには、
必ずnonceを設定するようにしましょう。

4.最後に

世の中にはいろんな会員制のサイトがありますが、
すべてのサイトで脆弱性対策が網羅されているわけではありません。
自分の身は自分で守りましょう~(/・ω・)/

この記事が気に入ったらサポートをしてみませんか?