読者です 読者をやめる 読者になる 読者になる

Blank?=False

「呉下の阿蒙にあらず」をモットーにしたITエンジニアの日々

CSRFとはなんぞや

tips Rails セキュリティ

Webアプリのセキュリティ用語として、CSRFというものが有ります。
コレは、Cross-site Request Forgery(クロスサイトリクエストフォージェリ)の略です。
Railsの書籍でもこういった話はたくさん出てきますが、実際にはどんなものか? 勉強してみました。

CSRFとはどんなものか?

Wikipediaではこう書かれています。

クロスサイトリクエストフォージェリ(Cross site request forgeries、略記:CSRF、またはXSRF)は、WWW における攻撃手法のひとつである。

どのようしてに攻撃するか

f:id:stonebeach-dakar:20160723115142p:plain

1 1px四方のIFrameが埋め込まれた誘導用のWebページにユーザーがアクセス 2 IFrame内部で攻撃用Webページを呼び出す 3 攻撃用WebページにあるJavascriptでユーザーの操作を偽装して攻撃対象のページにアクセスする・・・

どういった被害を受けるか

IPAのセキュア・プログラミング講座で以下のように説明されています。

インターネットショッピングの最終決済や退会等Webアプリケーションの重要な処理を呼び出すようユーザを誘導する攻撃である。


実際に会った事例として、有るページにアクセスした大学生が、全く知らない小学校の掲示板に意図しない書き込みをされ、誤認逮捕されたという事例があります。 パソコン遠隔操作事件 - Wikipedia

どういったWebアプリケーションが狙われやすいか

IPAの講座には以下のように書かれています。

  • フォームに入力した情報の検証を行わないサイト
  • Basic認証を行うサイト
  • Digest認証を用いているWebアプリケーション
  • そのほかWebクライアントから自動で得られる情報にもとづきユーザやセッションを識別しているWebアプリケーション

ログイン方法が雑だったり、ブラウザの情報を元にするサイトは危険ということですね。

対策

攻撃用Webサイトは攻撃者が作るため、防ぎようがありません。
なので、攻撃用Webサイトからの攻撃を防ぐ、という対策が必要です。 f:id:stonebeach-dakar:20160723131353p:plain

対策方法

対策方法は、様々なものがありますが、一番手っ取り早いのはCSRF対策がされているWebアプリケーションフレームワークを使うことです。

もしくは、IPAが公開している対策方法を実装することです。(この方式の対策が様々なフレームワークで実装されています) https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/301.html

CSRF対策がされているWebアプリケーションフレームワーク

など、採用実績が多いフレームワークはたいてい対応しているようです。
※ただし、フレームワークを採用しているからといってCSRF対策をしているかはまた別問題。

これら以外のフレームワークも対応しているものがあるので、自分が使っているフレームワークのリファレンスを読んで確認しておくとよさげ。

Railsではどんな対策をしているの?

RailsIPAが公開している対策の照合方式がデフォルトで組み込まれています。
そのため、開発者が意識する必要はありません。

どのように対策されているのかというと、 ApplicationController.rbの最初の方にprotect_from_foregery with: :exceptionという記述がデフォルトで有ると思います。
また、layoutフォルダのapplication.html.erbには<%= csrf_meta_tags %>というものがデフォルトであります。

コレがCSRF対策のキモとなっています。

全体の流れとしては、以下のように処理していきます。 f:id:stonebeach-dakar:20160724091131p:plain

Form_tagForm_forなどのビューヘルパーで、HTTP POST, PUTなどのフォーム、リンクを作成するだけで、Railsがトークンと言われる証明書のようなもの(公開鍵暗号方式のキーみたいなイメージ)を作り、それをフォームに自動的に埋め込み、アプリケーションに保存します。
そして、フォームのsubmitボタンがクリックされると入力した情報とトークンをアプリケーションに送り、トークンが一致することを確認できて初めてサーバーにデータを保存できます。
もし、ここでトークンが一致しなければRailsは例外InvalidAuthenticityTokenを発生させ、データは保存されません。
このトークンは、Railsがランダムに作成するため、複製・推察が難しく悪意あるサイトがトークンを埋め込んだリクエストを送信してもサーバーで弾かれます。

例えば、悪意あるサイトが入力を偽装するjsを作成してデータ入力しようとしたとしても、弾くことができるようになっています。 f:id:stonebeach-dakar:20160724091811p:plain
これがRailsCSRF対策です。

注意点

RubyOnRails4アプリケーション・プログラミングではRails開発者がCSRF対策で意識することは以下と書かれています。

  • HTTP GETによるリンクでデータ操作(特に削除)を行わない
  • データ操作のリクエストは、form_for / form_tag, link_toなどのビューヘルパー経由で生成する
  • レイアウトを自分で作成する場合は、csrf_meta_tagメソッドの呼び出しを忘れない

また、Rails4からは不正なリクエストが行われた時の挙動を変更できるようになっています。コレは、まだ後で紹介します。

参考文献・サイト

クロスサイトリクエストフォージェリ - Wikipedia

www.ipa.go.jp

Ruby on Rails 4 アプリケーションプログラミング

Ruby on Rails 4 アプリケーションプログラミング