「2つのクッキーを使い分ける」ってのがねー (#377356) | 経産省、Cookie盗聴への対策を指示 | スラド
このプレスリリース，基本的には的を射ている提言なんだが，対策Bとして提示している [ipa.go.jp]， 方法 B： 2つのクッキーを使い分ける サイトの設計上、http://... の画面と https://... の画面をまたがってセッション管理を行う必要がある場合は、2つのクッキーを発行し、一方を secure 属性付きとし、もう一方を secure 属性なしとします。https://... の画面ではセッション管理に前者のクッキーを使用し、 https://... の画面では後者のクッキーを使うようにします。 このとき、暗号化で保護が必要な画面（https:// を使うことにした画面）に対して、http:// でアクセスされても情報を表示しないように作る必要があります。そうしないと、攻撃者は、盗聴で盗み出した http:// 用のクッキーを使って、重要情報にアクセスできてしまうか
[ThinkIT] 第1回：Webアプリケーションの脆弱性 (1/4)
ソフトウェア製品の脆弱性は毎年数多くのものが見つかっている。次のグラフは1998年から2004年までに、米国のセキュリティ情報サイト「SecurityFocus」に新たに掲載された脆弱性の記事数の推移を表したものである。 ソフトウェア製品の脆弱性については、最近は各ベンダーがいち早く情報を発信し、パッチを配布するようになってきた。読者の皆さんの職場でもパッチ当て作業に追われている担当者がいるかもしれない。 こうした製品の脆弱性は、ソフトウェアの専門家が発見し、しばらくのちにベンダーの技術者が修正パッチを提供してくれるので、多くのユーザにとってはそのパッチを当てればだいたい事は済んでしまう。 ところが、われわれの身近にありながら、このように問題への対処が行われていないソフトウェアのカテゴリーがある。それが、Webアプリケーションである。 いまや、インターネットにアクセスできるわれわれにとって
おさかなラボ - クロスサイトリクエストフォージェリ対策
過去の議論はこちら 一般的に言われている対策と実際の有効性についてはこちら 一般にCSRFはセッションの利用に伴う脆弱性なのだから、予測不能な文字列を生成してhiddenとセッション内(PHPセッションの場合$_SESSION内)に入れておき、完了画面でこの2つを照会する方法が簡便で堅牢だと考えられる。(要はセッションを使ったワンタイムトークン方式)。 この対策だけでも充分だが、hiddenを横取りされた場合に発生する脆弱性に備え、Cookieでも比較を行う。 実際のコード // 確認画面 session_start(); (認証など略) $uniq_id = md5(uniqid(rand(),1)); // 推測不可能な文字列を生成 $_SESSION['uniq_id'] = $uniq_id; // セッションに保存 setcookie('uniq_id',
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
経路のセキュリティと同時にセキュアなセッション管理を：IPA 独立行政法人 情報処理推進機構
IPA セキュア・プログラミング講座
