『あとついでに』
アメーバなうではformからtokenを送信しているにもかかわらず、 サーバー側で未チェックだったが故のCSRFでしたが、 いま軽くチェックしてみたところ なんと… このAmebaブログの方も、まったく同じ状態(token未チェック)だったので まったく同じこと ちょっと近いことができます…！ って、おばあちゃんが言ってましたよ！ なにこれなにこれ どういう意味なの、おしえてえらいひと！ (追記) 実際には投稿にいくつかの必須パラメータがあってそのうちuser_id(数字)の指定もあるからそれほど簡単ではなかったかも？ ブログ投稿のPOST先: http://blog.ameba.jp/ucs/entry/srventryinsertend0.do 必須パラメータ user_id: 数字 publish_flg: 0 entry_title: 文字 theme_id: 数字 entry_t
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://shotawatanabe.com/2006/04/csrf.html
