まこと先輩と星野君とCSRFの微妙な関係：星野君のWebアプリほのぼの改造計画（4）（3/3 ページ）
Webアプリ改造計画発動-CSRF編
斉藤さん 「う〜ん……。なんとなくは分かった。じゃあ、直接パスワードを変更できないように確認画面か何かを挟めばいいのかな」
赤坂さん 「あ、よくそういう対策をなさる方が多いのですけど、それでは問題は解決しません。確認画面を飛ばして直接変更実行画面に対してリクエストを送信すればいいわけですから……。セッション変数などで画面遷移を追っていても確認画面と変更実行画面の両方にリクエストを送信すれば同じですしね」
斉藤さん 「ああ、そうか……」
赤坂さん 「こういった場合、送信されるパラメータの中に悪意を持った人が推測できないような値を含めればいいんです。この場合だと、旧パスワードをユーザーに入力させるとか」
斉藤さん 「なるほど。普通に考えたら旧パスワードを入力させた方がいいね」
赤坂さん 「ユーザーからパスワードを求めたくない場合は、代わりにCookieのデータをPOSTのデータとして渡して、Cookieと一致するかを確認することでも対策できます」
斉藤さん 「なるほどねぇ〜」
検討の結果、念には念をということで、旧パスワードの入力を求めたうえで、POSTデータとしてセッションIDが埋め込まれるような形にすることとなった。
| <form action=”./changePassword.do” method=”POST”> <input type=”hidden” name=”sessionid” value=”fda94f5a5c6d3bb721d62fe2f30ff97a”> <input type=”password” name=”oldpass” value=””> <input type=”password” name=”newpass1” value=””> <input type=”password” name=”newpass2” value=””> <input type=”reset” value=”リセット”> <input type=”submit” value=”送信”> </form> |
ミーティングが終わって自席に戻ると、星野君は忘れないうちにクロスサイトリクエストフォージェリの脆弱性の再現を行ってみた。
星野君 「なるほど〜。確かにこれでパスワードが変更できちゃうんだ……」
赤坂さんが見つけてくれたからよかったものの、見落として問題になったら大変なところだった。赤坂さんが並行して検査してくれていてよかったと星野君は思った。
星野君 「それにしても、赤坂さんってかなりWebアプリのセキュリティに詳しかったなぁ。まこと先輩もそうだけど、うちの会社って、セキュリティとあんまり関係ないのに詳しい人がいるもんだなぁ……」
次回予告：
検査を通じてWebアプリケーションについて知識を深めていく星野君。しかし、思わぬ落とし穴に自分がはまってしまうこととなる……。
赤坂さんのWebアプリ・チェックポイント！
Check！
Webアプリへの攻撃は、不正入力のチェックだけでは防げない
クロスサイトリクエストフォージェリのように正しいリクエストのように見せ掛ける攻撃もあるため、入力チェックだけで満足してはいけない。
Check！
間違った対策で満足しない
「POSTメソッドだから大丈夫」「確認画面を挟んでいるから大丈夫」「セッション変数で管理しているから大丈夫」ということは決してない。正しい対策を行おう。Cookieのみでの管理ではなく、必ずPOSTデータにもセッションIDを含むようにしたり、再認証をしたりする仕組みにしよう。
Check！
重要な処理を行う機能では必ずクロスサイトリクエストフォージェリ対策を
日記・掲示板への書き込み、決済処理、登録情報の変更・削除などクロスサイトリクエストフォージェリの攻撃の対象となり得る機能はたくさんある。適切に対策がされているかどうかをもう一度見直そう。
Profile
杉山 俊春（すぎやま としはる）
三井物産セキュアディレクション株式会社
テクニカルサービス事業部検査グループ
コンサルタント
セキュリティコンサルタントとして、主にWebアプリケーションのセキュリティ検査などに従事している。大手就職活動支援サイト、ショッピングサイトなどの検査実績を持つ。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。