クロスサイト・リクエストフォージェリ対策

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

クロスサイト・リクエストフォージェリ(以下CSRF)がどういうものかの説明や 対策についてネットに散在しているが、実際に関わったプロジェクトで対策を行う機会があったので書いてみた。

■まずはCSRFの概要について

  • クロスサイト・リクエストフォージェリ(以下CSRF)の概要 アプリケーションが機能を実行する際、サーバーで受け取ったリクエストが 送信者の意図したものであるかの確認処理が十分でない事が原因で発生する問題。
  • CSRFが行われると送信者の認知しない所で情報を操作されてしまう。

■発覚した脆弱性

  • 対象となるウェブアプリケーションではログイン時に生成したセッションIDをcookieにセットし、 ユーザの識別や権限の評価を行っていた。
  • セッションIDの有無に頼った実行権限のチェックのみであったため、 ユーザが意図しない機能を実行するリクエストを送信させられた場合、 ユーザの意思に反して機能を実行してしまう可能性が潜在していた。

■代表的な対策

 CSRFの代表的な対策として以下がある。

1.トークンの実装

クライアントのページ内でhiddenパラメータにトークンを挿入しておき、 処理実行時にサーバー側でセッションIDとトークンを比較し、一致した場合のみ実行する。

2.ワンタイムトークンの実装

クライアントのページ内でhiddenパラメータにワンタイムトークンを挿入しておき、 処理実行時にサーバー側でセッションIDとワンタイムトークンを比較し、一致した場合のみ実行する。

3.パスワード入力

重要なページを実行する際にパスワードの入力を要求する。

■採用した対策

今回は対策として1.採用した。 詳細は以下のとおり。

  • トークンをサーバー側で生成し、hiddenフィールドにトークンを格納したレスポンスをクライアントへ送信。
  • 続くクライアントからのリクエストではトークンを含んだリクエストを送信。
  • サーバー側は送られてきたトークンとセッションIDの正当性を確認。
  • 正当性が確認できた場合のみ処理を続行する。