csrfの人気記事 55件 - はてなブックマーク
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状
はてな各サービスの CSRF 脆弱性対策について - はてなダイアリー日記
先日より、はてな各サービスにおける CSRF 脆弱性の対策方法を見直しております。これまではリファラをチェックする方法を採用しておりましたが、この方法は対策としては不十分な点があり、新たに POST によるデータの送信時、セッションIDを用いた検査を行う方法を採用しております。 現在、各サービスでの対応がほぼ完了しております。サードパーティ製のツールなど、外部から直接データを POST しているアプリケーションなどが、今回の変更により動作しくなっている可能性がございますが、はてな各サービスの安全性向上が目的の変更となりますので、ご了承いただければ幸いです。 なお、セッションID は Cookie に保存されている rk パラメータの値を MD5 BASE64 でシリアライズした値になります。Cookie を取得可能なサードパーティ製ツールであれば、rk パラメータをエンコードした値を rk
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「tDiary」にクロスサイト・リクエスト・フォージェリの脆弱性
