CSRF 対策はいまだに Token が必須なのか?
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
ロシア情勢が Web / Internet / Tech に与えた影響の記録 2022年3月
令和４年３月２４日 経済産業省 総務省 警察庁 内閣官房内閣サイバーセキュリティセンター 現下の情勢を踏まえたサイバーセキュリティ対策の強化について（注意喚起） (本文中の「参考」セクション引用) これまでの注意喚起 ２月 23 日 経済産業省「昨今の情勢を踏まえたサイバーセキュリティ対策の強化について（注意喚起）」 https://www.meti.go.jp/press/2021/02/20220221003/20220221003-1.pdf ３月１日 経済産業省、金融庁、総務省、厚生労働省、国土交通省、警察庁、ＮＩＳＣ 「サイバーセキュリティ対策の強化について（注意喚起）」 https://www.nisc.go.jp/press/pdf/20220301NISC_press.pdf ランサムウェア対策 ストップ！ ランサムウェア ランサムウェア特設ページ STOP! RANSOM
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cache 解体新書｜Cache 解体新書
