「重要な処理」の際に混入する脆弱性

書籍を読んで

www.amazon.co.jp

こちらの書籍を読んでWebアプリケーションを作る際に重要な要点を自分用としてアウトプットします。

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

対策としては

• CSRF対策の必要なページを区別する

• 利用者の意図したリクエストであることを確認する

概要

重要な処理

--> 利用者のクレジットカードの決済、口座からの送金、メール送信など

• 「重要な処理」の受付に際して、利用者の意図したリクエストであることを確認する処理が必要
• この確認処理が抜けていると罠サイトなどを閲覧しただけで、利用者のブラウザから勝手に「重要な処理」を実行させられる場合がある
• このような問題を引き起こす脆弱性をCSRF脆弱性と呼ぶ
  • またこの脆弱性を悪用する攻撃をCSRF攻撃と呼ぶ

• 利用者のアカウントによる
  • 物品の購入
  • 退会処理
  • SNSや問い合わせフォームなどへの書き込み
  • パスワードやメールアドレスの変更

• CSRF脆弱性の影響は、アプリケーションの「重要な処理」の悪用に限る
  • 被害者である利用者の個人情報などを盗むことはできない

CSRF攻撃とXSS攻撃の比較

分かりづらかったので、Qiitaで良い記事があったので貼らせて頂きます

3分でわかるXSSとCSRFの違い - Qiita

攻撃の広範さという点ではXSSの脅威の方が大きいのですが、CSRFは以下の点で注意すべき脆弱性と言える

• CSRFは設計段階から対策を盛り込む必要がある
• 開発者の認知度がXSSのに比べて低く、対策が進んでいない

確認画面があればCSRF攻撃ができなくなるというのはよくある誤解

防げないパターンや攻撃手法

• 確認画面から実行画面へのデータの受け渡し方法として
  • hiddenパラメータを使う方法
  • セッション変数を使う方法
• ファイルアップロードフォームでのCSRF攻撃
• 認証機能のないWebアプリケーションに対するCSRF攻撃
  • アクセスログを辿っていった先のIPアドレスが犯人ではなく、罠サイトを閲覧しただけの場合などがある
• 内部ネットワークに対するCSRF攻撃
  • 主に内部犯(使用ソフトを調べる事が出来る、内部ネットワークへの情報を持っている、内部犯そのもの)が行う可能性
  • ルータやFWの管理者端末から罠を閲覧してしまうなど

脆弱性が生まれる原因

• form要素のaction属性にはどのドメインのURLでも指定できる
  • 罠などのサイトからでも、攻撃対象サイトにリクエストを送信できる
• クッキーに補完されたセッションIDは、対象サイトに自動的に送信される
  • 罠経由のリクエストに対しても、セッションIDのクッキー値が送信されるので、認証された状態で攻撃リクエストが送信される

通常のアプリケーションではRefererの値をチェックしないので、アプリケーション開発者が意識して、正規利用者の意図したリクエストであることを確認しない限り、両者は区別されない。 --> CSRF脆弱性が混入することになる

クッキー以外にも、自動的に送信されるパラメータを使ってセッション管理しているサイトには、CSRF脆弱性の可能性がある。具体的には、HTTP認証や、TLSクライアント認証を利用しているサイト

対策

CSRF対策の必要なページを区別する

• 全てのページについて実施するものではない
  • 対策の必要のないページの方がずっと多い
• パスワード、個人情報画面以外のページは様々なリンク先からアクセスされることが予想されるのでCSRF対策を絞る事で対策をする

開発プロセスの中での対策例

• 要件定義工程で機能一覧を作成し、CSRF対策の必要な機能にマークする
• 基本設計工程で画面遷移図を作成し、CSRF対策の必要なページにマークする
• 開発工程でCSRF対策を作り込む

正規利用者の意図したリクエストを確認できるよう実装する

意図したリクエスト

--> 対象アプリケーションの画面上で正規利用者が自ら「実行」ボタンを押した結果のリクエストと考える

= 意図しないリクエストとは、罠サイトからのリクエスト

意図したリクエストかどうかを判定する方法

• 秘密情報(トークン)の埋め込み
• パスワード再入力
• Refererのチェック

秘密情報(トークン)の埋め込み

• トークン
  • CSRF攻撃への対策が必要なページに対して、第三者が知り得ない秘密情報を要求するようにする
  • 不正なリクエストを送信させられても、アプリケーション側で判別する事が出来る
  • このような目的で使用される秘密情報のこと
• フレームワークでトークンの生成とチェックの機能を持つものが増えてきたため、その機能を有効化することで対策出来る

フレームワークを使わない場合の対策

トークンは第三者に推測されにくい乱数を用いて生成する

このような性質を持つ乱数を「暗号論的疑似乱数生成器」と呼ぶ

• empty()によりトークンが空でないことを確認することが重要
  • このチェックがないとセッション変数にトークンがセットされていない状況でhiddenパラメータのトークンがなくても処理が継続されてしまう
• PHP5.6以降の環境では、トークン比較の専用関数hash_equalsの使用が推奨
• 入力-確認-実行形式の画面のように、3段階以上の遷移がある場合でも、トークンを埋め込むページは実行ページの直前のページ
• トークン(重要な処理)を受け付けるリクエストはPOSTメソッド
  • GETメソッドではRefererにより情報漏洩の可能性がある

パスワード再入力

CRSF対策以外の目的での利用ケース

• 物品の購入などに先立って、正規利用者であることを再確認する
• 共有PCで別人が操作している状況などがなく、本当に正規の利用者であることを確認する

上記以外のページでパスワードの再入力を求めると利便性を欠いてしまう

パスワードを確認するページは最終の実行ページ

Refererのチェック

正規のリクエストとCSRF攻撃によるリクエストでは、Refererフィールドの内容が異なってくるため、「重要な処理」を実行するページでRefererを確認することにより、CSRF脆弱性への対策となる

Refererの欠点

Refererが送信されないように設定している利用者は、そのページを実行できなくなるという点

パーソナルファイアウォールやブラウザのアドオンソフトなどでRefererを抑止している利用者も少なくない

Refererのチェック方法

• 前方一致検索で絶対URLをチェックすること
• ドメイン名の後のスラッシュ「/」まで含めてチェックする

上記2点は必須条件

Refererのチェックは「重要な処理」の実行ページだけの追加で済むため、対策のためのプログラミングの量はもっとも少なく済む

欠点なども含め総合的に判断すると、社内システムなど利用者の環境を出来る場合で、かつ既存アプリケーションの脆弱性対策の場合に限って利用すると良い

CSRF攻撃への保険的対策

「重要な処理」の実行後に、対象利用者の登録済みメールアドレスに対して、処理内容の通知メールを送信することが推奨される

CSRF攻撃を防ぐ事は出来ないが、早期発見により被害を最小限にとどめることが期待される

また、CSRF攻撃だけでなくXSS攻撃などで成りすまされた場合でも、早期発見に繋がりメリットの大きい手法だと言える

※メール自体は平文で送信されるため、「重要な処理」が実行されたのみを通知するにとどめるべき