Open1
ウェブ・セキュリティ基礎試験(徳丸基礎試験)⑤
445徳丸基礎試験勉強まとめ⑤
「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」の4章の4.5、4.6を自分なりにまとめる
アドバイスや間違い指摘など歓迎です
4章 「Webアプリケーションの機能別に見るセキュリティバグ」
4.5 「重要な処理」の際に混入する脆弱性
「重要な処理」の際に混入する脆弱性が原因でなにが起こるの？
- CSRF(クロスサイトリクエストフォージェリ)
- クリックジャッキング
CSRFがあるとどんな影響があるの？
- 利用者のアカウントでできること(物品購入や退会やパスワード変更など)が、勝手に行われる
CSRFの仕組みは？
実行画面において、クッキー内のIDとPOSTで渡されたパスワードでパスワード変更する正規サイトに攻撃
- 利用者が正規サイトにログイン(クッキー発行)
- 利用者が罠サイト閲覧
- 罠サイトのJS(onloadでsubmitすることにより、閲覧しただけでPOSTメソッドによる送信が行われるなど)により正規サイトに新しいパスワードがPOSTメソッドで送信される(1のクッキーが付与されている)
- パスワードが勝手に変更される
確認画面でクッキー内のIDとメールアドレスを表示し、実行画面においてPOSTで渡されたメールアドレスでメールアドレス変更する正規サイトに攻撃
- 利用者が正規サイトにログイン(クッキー発行)
- 利用者が罠サイト閲覧
- 罠サイトの一つ目のiframeによって確認画面にメールアドレスをPOSTする(1のクッキーが付与されている)
- 罠サイトの二つ目のiframeによって、タイミングを見計って実行画面を呼び出す(1と3のクッキーが付与されている)
- メールアドレスが勝手に変更される
ファイルアップロードを伴うフォームを持つ正規サイトに攻撃
- 利用者が正規サイトにログイン(クッキー発行)
- 利用者が罠サイト閲覧
- 罠サイトのJSが正規サイトに画像ではなくテキストを送信(1のクッキーが付与されている。テキストはphp形式にし、内部はphp.infoを表示するphpコードを記載。CORSエラーが出ても、攻撃自体は成功する)
- 正規サイトにアップロードされた上記phpファイルを閲覧するとブラウザ上にphp infoが表示される
CSRFとXSSの違いって？
CSRF: 実行場所は正規サイトサーバー
XSS: 実行場所は利用者のブラウザ上
CSRFの原因は？
- form要素のaction属性にはどのドメインURLでも指定可能
- クッキーに保存されたセッションIDは、対象サイトに自動送信される
- 外部サイトから対象サイトへのリクエストでも、クッキーが自動送信される
CSRFの対策は？
- CSRF対策が必要なページを区別する
- 正規利用者の意図したリクエストを確認できるように実装する
- トークンの埋め込み(最も一般的)
- 重要な処理の前にパスワード再入力（利用者の手間が増えるデメリットがある）
- Refererチェック（リファラをOFFにしている利用者もいるため注意）
保険として
- 重要な処理の実行後には登録ずみメールアドレスにメール通知する
クリックジャッキングがあるとどんな影響があるの？
-
利用者のアカウントでできること(物品購入や退会やパスワード変更など)が、勝手に行われる
- 例えば罠ページのiframeのsrcに「フォームインデント機能を利用したTwitter URL」を記載し、iframeはz-indexなどで見えない細工をした上で、罠のclickable要素をクリックした際に投稿されてしまうなど
-
用語「フォームインデント機能」
クエリから投稿内容を埋めておく機能
クリックジャッキングの対策は？
iframeやframeが指定した設定以外のドメインで読み込まれた場合に表示しないように設定
- X-FRAME-OptionsレスポンスヘッダをDENYに指定(iframeやframeを使わないサイト)
- X-FRAME-OptionsレスポンスヘッダをSAMEORIGINに指定(iframeやframeを使うサイト)
保険として
- 重要な処理の実行後には登録ずみメールアドレスにメール通知する
4.6 セッション管理の不備
セッション管理の不備が原因でなにが起こるの？
- セッションハイジャック
セッションハイジャックがあるとどんな影響があるの？
- 利用者の重要情報閲覧
- 利用者の持つ権限での操作(送金など)
- 利用者のIDによるメール、ブログなどへの投稿、設定の変更
セッションハイジャックの原因は？
- セッションIDの推測
- 自作セッションIDによるセッションID推測(今章で解説)
- ミドルウェア脆弱性によるセッションID推測(8章)
- セッションIDの盗み出し
- XSSによる盗み出し(4.4章)
- HTTPヘッダインジェクションによる盗み出し(4.7章)
- リファラの悪用(今章で解説)
- ミドルウェア脆弱性によってセッションID推測(8章)
- セッションIDの強制
- セッションIDの固定化(今章で解説)
セッションID推測ってどうやるの？
- 正規サイトからセッションIDを集める
- セッションIDの規則性を推測
- 推測したセッションIDを正規サイトで試し、なりすましする
- セッションIDの規則性を推測されてしまうのは、ありがちなセッションID生成方法を使うから
- email, ユーザーID、リモートIPアドレス、日時、乱数などの組み合わせ
- 上記の組み合わせをそのまま、またはエンコードやハッシュ化してセッションIDとして使用
セッションID推測の対策は？
-
重要な処理の前にパスワード再入力要求する
- セッションハイジャックではパスワードの推測は不可能
- ただし、パスワード再入力しなくてもパスワード変更できると意味がなくなる
-
自作ではなく、開発ツールが提供するセッション管理機構を使用し、推測が難しいセッションIDを作成する
- やむおえず自作しなければならない場合、暗号論的擬似乱数生成器を元に、十分な桁数のセッションIDを生成する
-
PHPの場合はデフォルトでは推測可能なセッションIDが生成されてしまう。なので、php.ini に下記設定を行う
[Session]
session.entropy_file = /dev/urandom
session.entropy_length = 32
リファラの悪用ってどうやるの？
セッションIDをクッキーに保存せず、URLに埋め込む場合、リファラヘッダを経由してセッションIDが外部に漏洩する
携帯電話向けブラウザが以前にクッキーをサポートしていなかったため、上記のようなサイトが残っている場合がある
リファラの悪用の対策は？
- URLではなくクッキーにセッションIDを埋め込む
PHPの場合、php.iniでセッションIDをURLに埋め込みしない設定とする
[Session]
session.use_cookies = on
session.use_only_cookies = on
session.use_trans_sid = off
セッションIDの固定化ってどうやるの？
- 利用者が罠サイトにアクセス
- 罠サイトにある正規サイトへのリンクをクリック(パラメータとしてセッションIDを埋め込む)
- 上記セッションIDで正規サイトにログイン
- 罠サイト管理者（悪者）が上記セッションIDを使用して利用者の登録情報画面などを閲覧
- 用語「セッションアダプション」
上記手順3.のように、未知のセッションIDを受け入れてしまう特徴。
PHPやASP.NETなどはセッションアダプションの特徴があるので特に注意が必要。
ただし、セッションアダプションがないミドルウェアの場合も、有効なセッションIDを特定して、ユーザーにセッションIDを強制させることができるので注意が必要。
セッションIDの固定化の対策は？
- 認証成功後にセッションIDを変更する
- 認証成功後にトークン発行する
- 認証前にはセッション変数に秘密情報は保持せず、POSTメソッドの値をhiddenにして渡す