アド・オン・デマンド 開発者ブログ

リファラのチェック以外のCSRF対策をしてみた。

ので、
リファラの無い場合でも、Myフィーダーの管理が出来るようになりました。

が不安は残る。。。

一旦、これで様子を見たいと思います。

念の為、自分の為にも、メモを残しておきます。

セッション関係のまとめ
1．ログイン処理
それ自体がIDとパスワードで保護されているので、特に対策は必要ない。
それらが漏洩した場合は論外。
が、セッションを張るときに、セッション固定攻撃対策として
セッションIDの再初期化　session_regenerate_id(TRUE);
と
CSRF対策用トークンの発行
は行っておく。

2．実行処理
CSRF対策が必要な（情報の更新や削除を実行する）処理の前画面では、
hiddenにCSRF対策用トークンをセットし、実行処理で、
_POST(_GET)と_COOKIEと_SESSION内のSRF対策用トークンをチェックする。
さらにリファラがあれば、リファラのチェックもする。
（やっぱりリファラのチャックが一番良さそうだけど。）

3．PHPのセッション
PHPの_SESSIONを使用する場合、
    session_start();
が必要だが、このままだと無条件で勝手に
（ログイン前に、ログインしているかどうかチェックする時だけでも）
セッション用のクッキーが発行されてしまうので、危険。
セッションが必要な場面でも無条件にPHPの先頭に入れてはダメ。
クッキーでのみセッションを管理するようにする。
ログイン処理は1．の通り。ログインが成功した後でスタートする。
ログイン処理以外は、session_start();の前に
    $_COOKIE[session_name()]
をチェックし、無ければその時点でセッションが無いことが解るので、無用なスタートはしない。
スタートした後に無効なセッション用のクッキーがあったら削除する。
もちろんログアウト処理でも削除する。
これで、常に新しいセッションがログイン処理の時にのみ生成される。

4．セッションハイジャック
最終的には、SSLを使って、セッション用のクッキーにsecure属性を付けるしかないの？

これでいいのか？
いろんな議論を読んでもまだ納得出来ない。
頭がこんがらがってきた。。。

AoDはそんなにシビアに考える程のシステムじゃないよーな気もするけどね。

ユン

参考サイト
PHP でセッション変数、Cookie を使用する際のセキュリティ対策について
開発者のための正しいCSRF対策
クロスサイトリクエストフォージェリ対策
CSRF対策に「ワンタイムトークン」方式を推奨しない理由
セッション固定攻撃