IPAの「安全なウェブサイトの作り方」を読み進める第5回！
この記事は上記の文書を個人的にまとめた防備録となるので注意。
この文書の目次は以下。
1) SQL インジェクション
2) OS コマンド・インジェクション
3) パス名パラメータの未チェック/ディレクトリ・トラバーサル
4) セッション管理の不備
5) クロスサイト・スクリプティング
6) CSRF(クロスサイト・リクエスト・フォージェリ)
7) HTTP ヘッダ・インジェクション
8) メールヘッダ・インジェクション
9) アクセス制御や認可制御の欠落
前回はクロスサイト・スクリプティングについて学んだ。
今回は「CSRF:クロスサイト・リクエスト・フォージェリ」について。
1.クロスサイト・リクエスト・フォージェリとは
ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由した悪意のあるリクエストを受け入れてしまう場合があります。このようなウェブサイトにログインした利用者は、悪意のある人が用意した罠により、利用者が予期しない処理を実行させられてしまう可能性があります。
例えば、利用者があるサイトにログインしたまま、別の悪意のあるサイトを閲覧したとする。すると、その悪意あるサイトは利用者のセッションIDなどを利用して、サイトに攻撃を仕掛ける。
これを、「クロスサイト・リクエスト・フォージェリ」と呼ぶ。
IT用語辞典では以下のように説明されている。
Webサイトにスクリプトや自動転送(HTTPリダイレクト)を仕込むことによって、閲覧者に意図せず別のWebサイト上で何らかの操作(掲示板への書き込みなど)を行わせる攻撃手法。
意図したリクエストでない＝スクリプトや自動転送ってこと？
発生しうる脅威は以下。
・ログイン後の利用者のみが利用可能なサービスの悪用
・ログイン後の利用者のみが編集可能な情報の改ざん、新規登録
注意が必要なウェブサイトは以下。認証系は一度ちゃんと勉強しないと！
・Cookie を用いたセッション管理
・Basic 認証
・SSL クライアント認証
2.クロスサイト・リクエスト・フォージェリの対策
処理を実行するページをPOST メソッドでアクセスするようにし、その「hidden パラ メータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページでは その値が正しい場合のみ処理を実行する
例として「入力画面 → 確認画面 → 登録処理」のフォームによるページ遷移を考える。
入力画面から確認画面に遷移する際、秘密のセッションID（ログイン用以外にもう一つ、トークンと呼ぶことも）を作成し、確認画面のフォーム内に hiddenとして埋め込む。
そして登録処理の際に、hiddenから POSTされた値とセッションIDが同一かを確認し、同一のときのみ処理を実行する。
これなら、リクエストが正しいものかどうか確認できる。
ただし、リロードするたびに新しいセッションIDを生成しなければならない。
処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する
最初の解決法で使用する第2のセッションIDには、暗号論的擬似乱数生成器を用いて第3社に予測困難なように生成する必要がある。
しかし、暗号論的擬似乱数生成器を簡単に用意できない場合はこちらの策が簡単。
ただし、画面設計の仕様を変更しなければならない。
Referer が正しいリンク元かを確認し、正しい場合のみ処理を実行する
Refererとは、Webページ上のリンクからページ遷移した場合のリンク元のページのこと。
Refererが確認できない場合や殻の場合は、怪しいので処理できなくしておく。
が、ブラウザやパーソナルファイアウォールなどの設定で Refererを送信しないようにしている。
なので、一番最初の設定だけで良いのかな。
保険的対策
・重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する
コメント