タグ

セキュリティとCSRFに関するinc-2734のブックマーク (6)

  • CSRFトークン インタビューズ - Qiita

    VAddyとCSRFトークン VAddyは脆弱性診断を実行する際に、CSRFトークンを最新のものに更新しながら動作します。そのため「どのパラメータがCSRFトークンか?」を判断するロジックが存在しています。最近あるフレームワーク(後述)について「CSRFトークンを正しく認識できない」というバグを修正したのですが、良い機会なのでメジャーなフレームワークやCMSを中心にCSRFトークンの実装をざっと追ってみました。一覧にしても面白くないので、仮想インタビュー形式にまとめてあります。GitHub上で軽く追ったものが多いので、最新のバージョンでなかったり、解釈が間違っている箇所があるかもしれません。 それでは、どうぞ。 Ruby on Rails 金床(以下、金)「こんにちは。ようこそ。」 RoR「こんにちは」 金「相変わらずシェア高いようですね。」 RoR「はい、おかげさまで。この間はルマン24

    CSRFトークン インタビューズ - Qiita
  • CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
  • 有名フレームワークのCSRF対策方法を調べたまとめ - webネタ

    ZendFramework 流れ 表示時 : token生成→hiddenセット + セッションにセット 送信時 : 送られてきたtokenをセッションにあるものと同じかでチェック token生成方法 ランダム値 + salt + 固定値 + ランダム値 md5( mt_rand(1,1000000) . $this->getSalt() . $this->getName() . mt_rand(1,1000000) ); まとめ ランダム値をセッションにいれて、送られてきたものとチェック。 Symfony 流れ 表示時 : token生成→hiddenセット 送信時 : 送られてきたtokenを、再度生成したtokenと比較して同じかチェック token生成方法 salt + 固定値 + セッションID sha1($this->secret.$intention.$this->getSe

    有名フレームワークのCSRF対策方法を調べたまとめ - webネタ
  • CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん!

    こんにちはこんにちは!! 今日はCSRF脆弱性のちょっとした話です! このCSRFってなにかっていうと、 サーバーへのリクエストを『誰かに勝手に送らせる』っていうセキュリティがらみの攻撃手法のひとつ。 わかりやすい例だと、 HTMLの画像タグを以下のようにしたページを誰かに教える。 <img src="何々SNSの足跡.php" width="1" height="1"> そうすると、そのページを「見た人」が何々SNSの足跡.phpにアクセスしたことになる。 ※詳しくはこちらのマンガで → [はまちちゃんのセキュリティ講座]ここがキミの脆弱なところ…! : 第2回 しーさーふって何ですか? CSRFってこんな風に、 「ログイン済みの人に何か操作させる」ってイメージが強くて、 対策する側もまた、「既にログイン済みの人を守る」ような考えが強いんだよね。 例えば、勝手に日記に投稿させないように対

    CSRFで強制ログインさせるというアイデア - ぼくはまちちゃん!
  • おさかなラボ - [CSRF]高木氏のエントリへの返答

    CSRF対策に「ワンタイムトークン」方式を推奨しない理由 @ 高木浩光@自宅の日記 ものすごく遅くなってしまったが、高木氏の反論を読ませて頂いた。 ワンタイムトークン方式の欠陥 (拙作の)「ワンタイムトークン方式」では複数の画面遷移を実装できない、という点についてはまさにその通りで反論の余地はない。僕が提唱した方法では、同一セッションで2つ以上の画面遷移を平行して行った場合、先にワンタイムトークンを発行した方の処 理がエラーを起こしてしまう。 「ワンタイムトークンを変数で切り分ける」方式(僕が提唱したものではないが)についても、高木氏の言う通りで現実的ではないと思う。全く同じ画面の平行編集についても、同じ人へ複数のメッセージ(メール)を送る場合など必要と思われる場面はいくつか想定できる。 で、hiddenにSessionIDを入れるのは問題ないの? 高木氏やおおいわ氏の主張は

  • 高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由

    水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更

  • 1