セッションハイジャック関係

| | コメント(0) | トラックバック(1)

気をつけよう、セッションハイジャック

クッキーを secure モードで発行する

・経路のセキュリティと同時にセキュアなセッション管理を
http://www.ipa.go.jp/security/ciadr/20030808cookie-secure.html

独立行政法人産業技術総合研究所から発行されたテクニカルレポート(AIST03-J00017)において、セッション管理のためにクッキー(cookie)を使用し、かつ、SSL/TLS のような経路のセキュリティ保護を行っている Web アプリケーションにおいて、クッキーを secure モードで発行することの重要性が指摘されています。

理由は「secureモードでない通常のcookieは、SSL/TLSによる経路のセキュリティ保護を受けることができないから。

回避策は


  1. すべてのページをSSL/TLSを利用したページにして、cookieにsecure属性を付与する

    「すべてのページ」とは、セッション追跡の必要な画面(「ログイン後の画面」)のすべてのページのこと。

  2. 2つのcookieを使ってセッション追跡する

    ランダムに生成するセッションIDを、「secure 属性なし」のcookie(仮に名前を「session-id」)と「secure 属性付き」のcookie(仮に名前を「secure-session-id」)の2つ発行する。
    2つのcookieはhttps://のアクセスでログインが成功したタイミングで発行し、どちらのセッションIDからでもユーザを特定できるようにしておく。
    SSLで保護すべき画面に http:// でアクセスできると、盗聴で盗み出した「secure 属性なし」のcookieを使って、重要情報にアクセスできてしまいます。
    そのため、SSLで保護すべき画面に対してhttp:// でアクセスできないようにする必要があります。

セッションIDの作成

・@IT:Webアプリケーションに潜むセキュリティホール(3)
http://www.atmarkit.co.jp/fsecurity/rensai/webhole03/webhole01.html

簡単に予測しにくいセッションIDを作るには、乱数とハッシュを使う方法がある。

Perlプログラムの例

#!/usr/bin/perl
require 5.004; 
use Digest::MD5 'md5_hex';
print md5_hex rAnd;
ハッシュの元になる値は乱数だけでなくてもよい。ハッシュ化するとハッシュ元の値を導き出すことは事実上不可能になるので、ユーザー特有の情報を含ませてしまっても安心だ。 (略) ただし、ユーザー特有の情報だけからハッシュを計算するのはお勧めできない。その情報が変わらなければ何度ハッシュを計算しても同じハッシュ値しか生成されないからだ。 必ず乱数を併用しよう。

(参)アプリケーションサーバが使っているセッションIDの文字種と長さ

PHP:128bit(PHPSESSID=f08b925af0ecb52bdd2de97d95cdbe6b)
ASP:32bitのIDを暗号化(ASPSESSIONID=PUYQGHUMEAAJPUYL)
JSP:大小英文字+数字の組み合わせによる52文字

トラックバック(1)

このブログ記事を参照しているブログ一覧: セッションハイジャック関係

このブログ記事に対するトラックバックURL: http://kinshachi.ddo.jp/mt/mt-tb.cgi/60

» セッションハイジャック回避ワザ(airmash.life)~のトラックバック

コンピュータ系blog: セッションハイジャック関係セッションハイジャック回避ワザ ハッシュ関数を使った場合がよさそう。擬似乱数だっけかな。 ... 続きを読む

コメントする


画像の中に見える文字を入力してください。

このブログ記事について

このページは、ikeが2003年9月 4日 12:26に書いたブログ記事です。

ひとつ前のブログ記事は「HotFix管理の勘所」です。

次のブログ記事は「ColdFusion MX 6.1 用のオンラインマニュアル(日本語版)」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

最近のコメント

Powered by Movable Type 4.261