T.Teradaの日記 - SessionSafe: Implementing XSS Immune Session Handling
SessionSafeは、ハンブルグ大学のMartin Johnsさんが書いたWeb APの方式案です。 もしWeb APにXSS脆弱性があって、これが攻撃されたとしても、 セッションIDが盗まれない 当該ページ以外の情報が窃取・改竄されない ことを目指しています。 面白いなーと思ったので、内容について少し書きます。 なお、元記事を高速斜め読みしたので、この日記の内容には間違いが含まれているかもしれません。興味のある方は原本を見てください。 セッションIDが盗まれない 以下の二つのドメインがあるとします。 www.example.com secure.example.com セッションIDのCookieは、secureサブドメインに発行します。 Webページを表示する際はwww.example.comのURLにアクセスします。そこで返すHTMLに色々と仕掛けを施します。 HTMLの仕掛け
2006-05-07
あなたが10の理由を示すべき10の理由。 「7の理由」ではパターン化しすぎているから。 9では少なすぎ、11では切りが悪いから。 体系的に広い視野で考えているように見てもらえるから。 なんだかんだいって10個くらいの理由は思いつくから。 10個も示せば一つくらいは「なるほど」と言ってもらえるから。 10個も示せば一度には読みにくいためブックマークしてもらえるから。 10個も示せば時間経過とともにランキング変動も調査できるから。 10位から発表していけば「1位は何だろう」と盛り上げられるから。 タイトルで「10の理由」と書いておいても、実際に10個も示す必要なんてないから。 ※流行ものらしいので、書いてみました。 はてな認証APIに関連して、kazuhoさんが以下のエントリを書いておられます。(via まちゅダイアリー) Re: はてな認証 API Hash ≠ MAC これは「秘密鍵をメッ
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A. WEBプログラマコース