CSRF 対策はいまだに Token が必須なのか?
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
webアプリケーションの脆弱性とは？ - OKWAVE
こんにちは！ 「フォームを勝手にサブミットしてしまう」 その認識でだいたいあってます！たぶん！ そのmixiの例だと、 入力画面 → (送信1) → 確認画面 → (送信2) → 完了 ってなるわけですが、 いくら確認画面が間にあったところで、 (送信2)の部分を「勝手にサブミット」しちゃえばいいわけです。 ※ただし今のmixiや、ちゃんとしたwebサービスは送信時にトークンをつけるとかCSRF対策してるのでできません 実際の攻撃の例としては、mixiやtwitterなどの多くの人が繋がっている投稿型サイトで、 「こんにちはこんにちは！！ このリンク先すごいよ！ http://～」 のような書き込みをしておき、 そのリンク先でformやJavaScript等で「自動的に勝手にサブミット」してしまいます。 画面には何も表示されなくてもかまいません。 そしてさらに勝手に書き込む内容を 「こんに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
