攻撃者がセッション ID を入手可能な状態で CSRF 攻撃を仕掛ける可能性について検討した - co3k.org
仕事で「フレームワークで使ってる CSRF 対策用トークンがセッション ID を基にいろいろ組み合わせた文字列のハッシュなんだけれども、なんでセッション ID 直接使わないんだよう」的な話が出たので、なんでだろうなーと考えつつ理由について検討してみたので以下に一部晒してみます（社内向けに書いたものなのでいろいろ雑だったりするのはごめんね）: 推測ですが、セッション ID が GET パラメータとかに含まれたりする可能性を避けたかったんじゃないかなあとか思います（フォームは GET でも使われうることを想定している）。 GET パラメータにセッション ID のような種類の情報は含めるべきではありません。 あと、セッション ID が盗まれた場合でも CSRF 攻撃を受けないようにするという意図もありそうな気がします。攻撃者がセッション ID を知っている状況で CSRF 攻撃を選択する状況につ
Web セキュリティに関するインターンで伝えようとしたこと - co3k.org
これは VOYAGE GROUP エンジニアブログ：Advent Calendar 2014 の 17 日目のエントリです。 VOYAGE GROUP では もの創り実践プログラム Treasure というエンジニア向けインターンシップを開催しています [1] [2] 。 Treasure 全体の様子は既に VOYAGE GROUP エンジニアブログにて 前編 と 後編 に分けて紹介されていますが、このエントリでは、前半パートにおいて僕が担当した Web セキュリティに関する講義についてお話ししていきます [3] 。 講義は休憩や実際に手を動かしてもらいつつで 3 時間半という長丁場でしたが、なぜか随所で笑いが巻き起こる状態で非常に評判がよく、同じ内容を 独立した 1 day インターンシップとして京都でも開催 させていただけました [4] 。これもひとえに必死に内容に食らいついてくれたイ
Symfony2 の力を借りたセキュア開発 (Symfony Advent Calender 2011 JP - 18日目) - co3k.org
Symfony Advent Calender 2011 JP 18日目です。前回は @hidenorigoto さんでした。リダイレクト・インターセプションは 2.0.0 が出る前のどこかのタイミングでデフォルトでオフになって焦った記憶があります。投稿処理などをしたタイミングでプロファイラを見る機会が多いので、有効にしておくと便利ですよね。 さて、 18 日目となるこのエントリでは、セキュリティの観点から Symfony2 の機能について簡単に観ていくことにします（本当はしっかり見ていくつもりだったのですが、時間的制約から急遽簡単になりました！）。 ここでは Symfony Standard Edition v2.0.7 のインストール直後の構成、依存ライブラリを前提として解説します。また、 Web アプリケーションセキュリティに関する基本的な知識を持っていることを前提として説明します。
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
