My Photo

« October 2013 | Main | December 2013 »

November 30, 2013

左耳の聴力低下

1週間くらい前からなんか耳に違和感があった。詰まっている感というか。
今週の後半になってからは左耳で拾った音が頭の中で響いたり、割れて聞こえたり、小さい音が聞き取れなかったり。
さすがに心配になって耳鼻科行ったら左の聴力が落ちていると言われた。内耳の問題だそうだ。

6月にも耳が変に感じになった。音の聞こえ方は普通だったが、耳が詰っている感はあった。
今回とは別な耳鼻科に行ったら点耳薬を処方され、「1ヶ月は耳掃除禁止」と言われた。
で、2日くらい点耳薬を使っていたら治った。
耳掃除は耳の中がかゆかったのでしてしまったが。

それと、関係あるのかどうかわからないが11月は2回も風邪をひいた。
自分は風邪を引くと大体は
喉の痛み=>咳・鼻水=>発熱
という経過をたどることが多いのだが、今回は咳・鼻水がなく頭痛がした。風邪で頭痛になったことが余り記憶がない。
風邪のウイルスが耳に行ったりとか、あるんだろうか?

医者には「とりあえず薬を飲んでまた月曜日に来るように」と言われた。
「放っておいてもそのうち治るかな。」と思って医者に行くかどうか迷ってたんだけど、行っておいて良かった^^;

しかし冬の医者は混むなあ。受付してから診察まで2時間も待たされた。
あと、処方されたシロップ薬、激マズ;;

November 24, 2013

オープンリダイレクト脆弱性

発生箇所 外部から指定したURLにリダイレクト可能な箇所
影響を受けるページ Webアプリケーションの特定ページが影響を受けるわけではなく、フィッシング手法により重要情報が盗まれることで利用者が被害を受ける。
影響の種類
  • フィッシングサイトに誘導され重要情報が入力させられる。
  • デバイスドライバやパッチと称してマルウェアを配布される。
利用者の関与の度合い 大(リンクのクリックおよび情報の入力)

概要

Webアプリケーションにおいて、パラメータにより指定したURLにリダイレクトする機能をリダイレクタと呼ぶ。
特に、任意のドメインにリダイレクトできるものをオープンリダイレクタと呼ぶ。
利用者が信頼しているドメイン上にオープンリダイレクタ脆弱性があると、利用者は自分が信頼しているサイトを閲覧しているつもりでも知らない間に罠のサイトに誘導される可能性がある。

攻撃手法

例として、ログイン認証後にGETパラメータurlで指定されたURLにリダイレクトする "https://example.jp/login.php" を考える。攻撃者はメールやブログなどで利用者が以下のURLを閲覧するように仕向ける。

https://example.jp/login.php?url=<罠サイトのURL>

利用者の多くはドメインが本物でありHTTPSの場合も証明書のエラーが表示されないので、安心してIDとパスワードを入力する。
利用者がログインすると罠サイトにリダイレクトされる。罠サイトで
「ログインエラー。IDとパスワードを際入力してください。」
などと表示されると、やはり多くの利用者は入力ミスしたものと思いIDとパスワードを入力してしまう。このようにして重要情報が収集される。

脆弱性の原因

以下の2点をともに満たす場合にオープンリダイレクト脆弱性が存在する。

  • リダイレクト先のURLを外部から指定できる。
  • リダイレクト先のドメインのチェックがない。

オープンリダイレクト脆弱性が差し支えない場合

以下の2点をともに満たす場合、オープンリダイレクタではあるが脆弱性とはならない

  • もともと外部のドメインに遷移する仕様であること。
  • 利用者にとっても外部のドメインに遷移することが自明であること。

この条件を満たす例としてはバナー広告がある。

対策

オープンリダイレクタ脆弱性の対策は以下のいずれかを実施することである。

  • リダイレクト先のURLを固定にする。
  • リダイレクト先のURLを直接指定せず番号指定にする。
  • リダイレクト先のドメインをチェックする。

リダイレクト先のURLのドメインチェックの実装にはミスが起こりやすい。以下に例を挙げる。

失敗例1
if (mb_ereg('example\.jp', $url)) {
	// チェックOK
}

これは
"http://trap.example.com/example.jp.php"
のようにURLの途中に "example.jp" が含まれていればすり抜ける。

失敗例2
if (mb_ereg('^/', $url)) {
	// チェックOK
}

これはURLがスラッシュで始まっていること、すなわちパスの指定のみのURLであることを確認している。
しかし、
"//trap.example.com/trap.php
がすり抜ける。"//" で始まるURLは「ネットワークパス参照」と呼ばれる形式で、ホスト名(FQDN)以下を指定するものであり、外部ドメインへの遷移を防ぐことはできない。

失敗例3
if (mb_ereg('^http://example\.jp/, $url)) {
	// チェックOK
}

これはURLが "http://example.jp" で始まっていることを確認している。これだけではHTTPヘッダインジェクション攻撃に対して脆弱な場合がある。さらにHTTPヘッダインジェクション攻撃で別ドメインにリダイレクトされる場合があるので、この方法ではオープンリダイレクタ脆弱性を防げない可能性がある。

望ましい書き方
if (mb_ereg('\Ahttps?://example\.jp/[-_.!~*\'();\/?:@&=+\$,$#a-zA-Z0-9]*\z', $url)) {
	// チェックOK
}

"http://example.jp/" または "https://example.jp/" で始まること、その後はURIで使用できる文字の身からなることを確認している。文字列の先頭・末尾を示す記号として "\A" と "\z" を使用している。"https?" はhttpとhttpsの両方に対応するためである。

クッションページ

オークションサイトやSNSなど利用者がURLを書き込むとリンクが生成されるサイトでは、その機能がフィッシングサイトに誘導するのに使用される可能性がある。
これを防止する方法として、外部ドメインに対しては直接リンクせず、クッションページと呼ばれるページをはさむ手法がある。クッションページで外部のドメインに遷移することを利用者に告知することによりフィッシングの被害を防止しようという手法である。
外部ドメインへのリダイレクトを許可しているリダイレクタの場合にも、クッションページをはさむことによるフィッシング被害の防止を検討するとよい。
また、携帯電話向けWebアプリケーションの場合は、セッションIDの漏洩防止を目的としてクッションページを使う。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.7.1 オープンリダイレクト脆弱性

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

正規表現メモ(2) mfind

Windowsにはgrepはないがfindstrという似たようなコマンドがある。しかしUTF-8に対応していない。
それでmfindというフリーソフトを使っている。これはUTF-8に対応している。ただ、仕様なのかバグなのか、マッチしたところのファイル名と行番号が表示されないときがある。どういう条件でそうなるのかがわからない。
mfindは.NETを使っているそうで、.NETの正規表現を使用できる。

下記の例では文字コードにUTF-8を指定し、「"abc"の前が行頭、空白文字、ダブルクウォート、シングルクウォート、ピリオド、カンマのいずれかで、"abc"の後が行末、空白文字、ダブルクウォート、シングルクウォート、ピリオド、カンマのいずれかである。大文字、小文字は区別しない。」という条件で検索している。

C:\data\tmp>mfind /N /E8 "/(^|[\s\"'\.,])abc([\s\"'\.,]|$)/i" *.txt

参考サイト:
mfind - コマンドライン用テキスト検索・置換ツール
.NET Framework の正規表現

November 19, 2013

Object.keys()をjQueryで代替する

以下のJavaScriptのコードが Firefox だと問題なく実行できたのだがIE8(OS:Windows XP SP3)ではエラーになった。

var obj = { 0 : "a", 1 : "b", 2 : "c"};
alert(Object.keys(obj));

Object.keys() はIE9からサポートとのこと。
ググってIE8でも動く方法がないか調べたら、以下の方法を見つけた。jQueryすばらしい。

var obj = { 0 : "a", 1 : "b", 2 : "c"};
var objKeys = $.map(obj, function(value, key) {
	return key;
});
alert(objKeys);

参考サイト:
Using jQuery 1.6 to find an array of an object's keys >> Encosia
Object.keys 関数 (JavaScript)

November 17, 2013

SQLのIN句の色々な例

SQLで "列col1,col2,col3のいずれか1つにでも合致する" という条件で検索する場合、

SELECT * FROM tbl
WHERE ? = col1 OR ? col2 OR ? = col3

というSQLを書いていた。同じ値を指定するプレースホルダが3つもあって、大した条件でもない割に長い。
もっと短く次のように書けるということを最近知った。

SELECT * FROM tbl
WHERE ? IN (col1, col2, col3)

また、いくつかの値をセットにしてIN句を作ることもできる。下記の例では "col1とcol2が(1,3)または(2,4)" という条件である。

SELECT * FROM tbl
WHERE (col1, col2) IN ((1, 3), (2, 4))

上記のSQLではINの後の括弧内に値を記述しているが、次のようにサブクエリを書くこともできる。

SELECT * FROM tbl
WHERE (col1, col2) IN (
        SELECT subCol1, subCol2
        FROM subTable
        WHERE id > 10)

カラムid1, status1, id2, status2, id3, status3 を持つテーブルで (id1, status1)、(id2, status2)、(id3, status3) という3つの組み合わせのうちどれか1つでも ('ab012', '3') と一致するという条件で検索する場合は次のようになる。

SELECT * FROM tbl
WHERE ('ab012', '3') IN (
        (id1, status1), (id2, status2), (id3, status3))

前の例と同じテーブルで、今度は前記の3つの組み合わせがいずれも('ab012', '3')と一致しないという条件では次のようになる。NULLの場合を考慮して COALESCE を使う。

SELECT * FROM tbl
WHERE ('ab012', '3') NOT IN (
        (COALESCE(id1, ''), COALESCE(status1, ''))
      , (COALESCE(id2, ''), COALESCE(status2, ''))
      , (COALESCE(id3, ''), COALESCE(status3, '')))

2014/02/12追記:
この記事で書いた列と列の比較を複数列に一般化したものを「行式」という。SQL-92で標準化された機能である。IN以外の比較演算子にも拡張できる(実装されているかどうか別である)。
行式はOracleとDB2で実装されているそうだ。PostgreSQLでも使える。MySQLは不明。

参考文献:WEB+DB PRESS Vol.66 SQL救急救命室 第5回

参考サイト:
PostgreSQL IN句での複数条件指定 | Fusic Developers' Weblog

セッション管理の不備 その4

関連記事:
セッション管理の不備 その1
セッション管理の不備 その2
セッション管理の不備 その3


セッションIDの固定化

発生箇所 セッションIDを生成している箇所
影響を受けるページ セッション管理を利用しているすべてのページ。特に秘密情報の表示や重要な処理をするページは影響が大きい。
影響の種類 成りすまし
利用者の関与の度合い 大(罠サイトの閲覧、本番サイトでの認証

攻撃手法

セッションハイジャックを引き起こす攻撃手法の中にセッションIDを外部から強制する方法がある。これをセッションIDの固定化攻撃(Session Fixation Atack)と呼ぶ。
手順は以下。

  1. セッションIDを入手する。
  2. 被害者に対して1で入手したセッションIDを強制する。
  3. 被害者は標的アプリケーションにログインする。
  4. 攻撃者は被害者に強制したセッションIDを使って標的アプリケーションにアクセスする。

セッションIDの固定化が起きやすい条件として、セッションIDをクッキーにもURLにも保持できることがある。

セッションアダプション

PHP、ASP.NETでは未知のセッションIDを受け入れるという特性がある。これはセッションアダプション(Session Adoption)と呼ばれる。Tomcatではセッションアダプションがないので勝手に作成したセッションIDは無視される。
セッションアダプションがないミドルウェアで動作するアプリケーションに対してセッション固定化攻撃を行う場合、攻撃者はまずターゲットアプリケーションを閲覧して有効なセッションIDを取得し、このセッションIDを被害者に強制するように罠サイトを設定する。
つまり、ミドルウェアにセッションアダプションがあるとセッション固定化攻撃がセッションアダプションがない場合に比べてより少ない手順で可能となる。

クッキーのみにセッションIDを保存するサイトのセッションIDの固定化

セッションIDをURLに保持できるアプリケーションの方がセッションIDの固定が容易である。
しかしクッキーのみにセッションIDを保持するアプリケーションでも、ブラウザやWEBアプリケーションに脆弱性があればセッションIDを外部から設定することが可能になる。以下クッキーを第三者が設定できる脆弱性の例である。

  • クッキーモンスター問題(ブラウザの脆弱性)
  • クロスサイト・スクリプティング脆弱性
  • HTTPヘッダ・インジェクション脆弱性

対策

  • セッションIDをURL埋め込みにしない。
  • クッキーモンスター問題のあるブラウザを使わない。
  • クッキーモンスター問題の発生しやすい地域型ドメインを使わない。
  • クロスサイト・スクリプティング脆弱性をなくす。
  • HTTPヘッダ・インジェクション脆弱性をなくす。
  • その他クッキーを書き換えられる脆弱性をなくす。

上記をすべて満たすのは困難である。例えばIneternet Explorerの地域型ドメインに対するクッキーモンスター問題は修正される予定がない。
このため、セッションIDが外部から固定化されることは許容し、セッションIDの固定化攻撃が行われてもセッションハイジャックは防ぐように対策することが効果的である。
そのため、Webアプリケーション側での以下の対策が効果的である。

  • 認証後にセッションIDを変更する。

PHPではこの処理に session_regenerate_id()を利用する。

bool session_regenerate_id([bool $delete_old_session = false])

引数は変更前のセッションIDに対応するセッションを削除するかどうか指定する。

セッションIDの変更ができない場合の対策

Webアプリケーションの開発言語やミドルウェアによってはセッションIDを明示的に変更できないものがある。そのような場合はトークンを利用する方法がある。
ログイン時にトークンとして乱数文字列を生成し、クッキーとセッション変数の両方に記憶させる。書くページの認証確認時にトークンとセッション変数のトークンの値を比較し、同一である場合のみ認証されていると認識する。

ログイン前のセッションIDの固定化攻撃の対策

ログイン前にセッション変数を使っているとセッションIDの固定化攻撃に完全に対策することは困難である。ログイン前はセッション管理機構は使わずhiddenパラメータで値を引き回すことが現時的な対策になる。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.6.4 セッションIDの固定化

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

たぶん今年最後の釣り

ずっと釣りに行こう、行こうと思いつつ行けてなかったが、やっと重い腰を上げて行って来た。
6時に起きたのに家を出たのは8時半。モタモタしすぎ。
例によって「三浦半島1DAYきっぷ」を利用。逗子、葉山方面へ。
天気予報は気圧の尾根に入っているために晴れ。でも11月中旬だからそれなりに寒いだろうなと思ってできる限り厚着した。ズボンの下にタイツ、上はタートルネックの長袖Tシャツ、普通のシャツ、フリース、薄いダウンジャケットという装備。でも現地にいってみると快晴で風もさほどなく全然寒くなかった。ちょっと歩き回った汗かくらくらい。
本当に気持ちいい天気だった。釣りしなくてもいいくらい。

釣りの方はさっぱり。
最初は秋谷漁港に行った。10時過ぎに到着。堤防の先のほうは人がいっぱい。
駐車場の防波堤の外側のテトラの上で少しエギやルアー、ソフトルアーを投げたがまったく反応なし。
ちっちゃい子供のイカがいたのソフトルアーとか五目ジグを投げてみたがまったく反応しなかった。
横でウキふかせ釣り?をしている人はメジナ?を釣り上げていた。
魚は釣れなかったが富士山はきれいに見えた。
漁港ではなく砂浜の方で釣りをしている人もいた。キス釣れるのかな?

1時間くらいで撤収して葉山公園に行ってみた。この段階でもう釣りをする気なし。ただの散歩。
葉山公園から砂浜に降りて左側に堤防みたいなところがあった。
釣りできなくはなさそうだが、他の場所に比べるとトイレが近いくらいでそれ以外はメリットなさそうだった。

それから以前行ったことがある真名瀬漁港とその近辺。
釣り船が帰って来ていたので港の中ではあんまり釣りできそうにない感じ。
近くの道路ではそこそこ人がいたが釣り上げる様子は見られなかった。

葉山マリーナにも行こうかと思ったが疲れたのでまっすぐ新逗子駅に戻り、そのまま帰宅。


今日思ったこと。
・エギングとかルアー釣りは、俺には無理だな。サビキ釣りかキスの投げ釣りか、なんかウキ釣りか。
・11月の三浦半島でも今日みたいな天気(晴れて気温が16度くらい)なら全然大丈夫だ。人も夏場より少なくていいかも。

Mtfuji20131116

Weather2013111618

November 12, 2013

セッション管理の不備 その3

関連記事:
セッション管理の不備 その1
セッション管理の不備 その2


URL埋め込みのセッションID

発生箇所 セッションIDを生成している箇所
影響を受けるページ セッション管理を利用しているすべてのページ。特に秘密情報の表示や重要な処理をするページは影響が大きい。
影響の種類 成りすまし
利用者の関与の度合い 必要→リンクのクリック、メール添付のURLの閲覧

PHPやJava、ASP.NETはセッションIDをURLに埋め込む機能をサポートしている。
過去のNTTドコモの携帯電話ブラウザはクッキーをサポートしていなかったので、携帯電話向けWebアプリケーションではURL埋め込みセッションIDが広く用いられている。

攻撃手法

PHPは設定でセッションIDをURL埋め込みにすることができる。php.iniの設定項目は以下。

項目説明デフォルト
session.use_cookiesセッションIDの保存にクッキーを使うOn
session.use_only_cookiesセッションIDをクッキーのみに保存On
session.use_trans_sidセッションIDをURLに自動埋め込みOff

上表の項目の組み合わせにより、セッションIDをどこに持つかを下表のように決まる。

セッションIDの保存場所use_cookiesuse_only_cookies
セッションIDをクッキーのみに保存OnOn
クッキーが使える場合はクッキーに、使えない場合はURL埋め込みOnOff
無意味な組み合わせOffOn
セッションIDを常にURLに埋め込むOffOff

session.use_trans_sidはOnの場合はセッションIDがURLに自動的に埋め込まれ、Offの場合はアプリケーション側で明示的にセッションID埋め込みの処理をしている場合のみセッションIDが埋め込まれる。

RefererによりセッションIDが漏洩する条件は以下の2点を満たすサイトである。

  • URL埋め込みのセッションIDを使える。
  • 外部サイトへのリンクがある。あるいはリンクを利用者が作成できる。

RefererからのセッションID漏洩は意図的な攻撃と事故により漏れる場合がある。
意図的な攻撃を仕掛けることができるのは利用者がリンクを作成できる場合に限られる。具体的にはWebメール、掲示板、ブログ、SNSなどがある。
Webメールからの攻撃では、攻撃者はターゲットアプリケーションの利用者に対してURL付きのメールを送信して攻撃者のサイトに誘導する。利用者が攻撃者のサイトを閲覧すると、WebメールのURLに埋め込まれたセッションIDが攻撃者のサイトにRefererとして漏洩する。

事故として漏洩するのは次のような場合である。
利用者がURLを書き込めないサイトの場合でも外部サイトへのリンクがあればそれらの外部サイトに対してセッションIDが漏洩することになる。
また、利用者がセッションID付きのURLを自ら掲示板などに投稿したり、セッションID付きのURLが検索サイトに登録されることもある。

脆弱性が生まれる原因

セッションIDがURLに埋め込まれる直接の原因は不適切な設定あるいはプログラミングである。
不適切な設定には意図的な場合と不注意による場合がある。前者のでは理由として以下の2つが考えられる。

  • 2000年前後にプライバシーの観点から「クッキー有害論」が起こり、クッキーを避けようという機運が一部にあった。
  • NTTドコモの携帯電話のブラウザが過去にクッキーに対応していなかったため、携帯電話向けWebアプリケーションでURL埋め込みセッションIDを使用している。

「クッキー有害論」とは第三者クッキーが利用者のアクセス履歴を追跡できるということから起こったものである。現在ではブラウザ側の第三者クッキーを拒否する機能が一般的になったため、通常のクッキーまでも拒否する根拠はくなった。
携帯電話に関しては現在でもクッキー非対応ブラウザが使われているためURL埋め込みのセッションIDを完全になくすのは難しい状況である。

対策

クッキーにセッションIDを保存するように設定する。PHPでは以下のようになる。

[Session]
session.use_cookies = 1
session.use_only_cookeis = 1

参考文献:体系的に学ぶWebアプリケーションの作り方 4.6.3 URL埋め込みのセッションID

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

November 07, 2013

セッション管理の不備 その2

関連記事:
セッション管理の不備 その1


推測可能なセッションIDによる脆弱性

発生箇所 セッションIDを生成している箇所
影響を受けるページ セッション管理を利用しているすべてのページ。特に秘密情報の表示や重要な処理をするページは影響が大きい。
影響の種類 成りすまし

攻撃手法
  1. 対象アプリケーションからセッションIDを集める。
  2. セッションIDの規則性の仮説を立てる。
  3. 推測したセッションIDを対象アプリケーションで試す。

ありがちなセッションID生成規則では、下記の値を単独または組み合わせて元データとする。さらにその元データをそのまま、あるいはエンコードしたりハッシュ値を計算してセッションIDとする。
このうちユーザIDや日時は外部から推測可能な元データなので脆弱性の原因となる。

  • ユーザID
  • メールアドレス
  • リモートIPアドレス
  • 日時(UNIXタイムの数値または年月日時分秒の文字列)
  • 乱数

推測可能なセッションIDが生成される技術的要因は前記に述べたが、さらに上流から考えるとアプリケーション側でセッション管理機構を自作していることが脆弱性の原因を作ったと言える。通常のWEBアプリケーション開発でセッションIDの生成を自作する意味はない。
理由は以下である。

  • 主要なWEBアプリケーション開発ツールはセッション管理機構を備えている。
  • 安全なセッションID生成プログラムを開発することは技術的難易度が高い。

もし主要なWebアプリケーション開発ツールのセッションID生成部分に脆弱性があれば、セキュリティ研究者が指摘して改善されているはずである。

対策

現時的な対策は、Webアプリケーション開発ツールが備えるセッション管理機構を利用することである。
なんらかの事情でセッション管理機構を自作する場合は、暗号論的擬似乱数生成器を元に十分な桁数のセッションIDを生成する。

PHPではデフォルト設定では以下の組み合わせにMD5ハッシュ関数を通す方法でセッションIDを生成している。

  • リモートIPアドレス
  • 現在時刻
  • 乱数(暗号論的擬似乱数生成系ではない)

これは前に述べたありがちなセッションIDの生成方法に該当する。ロジックの複雑性が高いために解読方法が判明しているわけではないが、理論的には安全性が保証されているわけではない。
php.iniの設定で安全な乱数を元にセッションIDを生成するようにできる。以下のその設定を示す。

[Session]
;; entropy_file は Windows では設定不要
session.entropy_file = /dev/urandom
session.entropy_length = 32

/dev/urandom はUnix系OSで実装されている乱数生成器で、デバイスファイルとして使用できる。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.6.2 推測可能なセッションID

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

November 05, 2013

セッション管理の不備 その1

セッションハイジャックの原因

第三者がセッションIDを知るための手段は以下の3種類に分類される。

  • セッションIDの推測
    攻撃対象攻撃手法脆弱性
    アプリケーションセッションIDの推測自作セッション管理機構の脆弱性
    ミドルウェアセッションIDの推測ミドルウェアの脆弱性
  • セッションIDの盗み出し
    攻撃対象攻撃手法脆弱性
    アプリケーションXSSXSS脆弱性
    HTTPヘッダ・インジェクションHTTPヘッダ・インジェクション
    脆弱性
    Refererの悪用URL埋め込みのセッションID
    ミドルウェアアプリケーションと同様ミドルウェアの脆弱性
    ネットワークネットワーク盗聴クッキーのセキュア属性不備ほか
  • セッションIDの強制
    攻撃対象攻撃手法脆弱性
    アプリケーションセッションIDの固定化攻撃セッションIDの固定化脆弱性

セッションハイジャックの影響

セッションがハイジャックされた場合、利用者に対するなり酢マシが行われ以下の影響がある。

  • 利用者の重要情報(個人情報、メールなど)の閲覧
  • 利用者の持つ権限での操作
  • 利用者のIDによるメール送信、ブログなどへの投稿、設定の変更など

参考文献:体系的に学ぶWebアプリケーションの作り方 4.6.1 セッションハイジャックの原因と影響

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

November 04, 2013

クロスサイトリクエストフォージェリ(CSRF)その3

関連記事:
クロスサイトリクエストフォージェリ(CSRF)その1
クロスサイトリクエストフォージェリ(CSRF)その2

対策

CSRF攻撃を防ぐためには、「重要な処理」に対するリクエストが正規利用者の意図したものであることを確認する必要がある。そのために以下の2点を実施する。

  • CSRF対策の必要なページを区別する。
  • 正規利用者の意図したリクエストを区別できるように実装する。

CSRF対策の必要なページを区別する

CSRF対策はすべてのページに実施するのもではない。むしろ対策の必要のないページの方がはるかに多い。
ECサイトの物品購入、パスワード変更、個人情報編集などの確定画面は他のサイトから勝手実行されると問題があるページであるので、このようなページにはCSRF対策を施す。
開発プロセスでは以下のようにする。

  • 要件定義で機能一覧を作成し、CSRF対策が必要な機能をマークする。
  • 基本設計で画面遷移図を作成し、CSRF対策が必要なページをマークする。
  • 実装でCSRF対策を作りこむ。

正規利用者を意図したリクエストであることを確認する

具体的な方法として以下の3種類が用いられる。

  • 秘密情報(トークン)の埋め込み
  • パスワード再入力
  • Refererチェック

秘密情報(トークン)の埋め込み

CSRF攻撃への対策が必要なページに対して第三者が知りえない秘密情報を要求するようにすれば、CSRF攻撃のリクエストをアプリケーション側で判別できる。このような目的で使用される秘密情報の事をトークン(token)と呼ぶ。セッションIDをトークンとして利用することができる。
下記にトークン利用の実装例を示す。

実行画面の直前の画面
<from action="change_password.php" method="post">
新パスワード<input type="password" name="pwd"><br>
<input type="hidden" name="token" value=<?php
echo htmlspecialchars(session_id(), ENT_COMPAT, 'UTF-8'); ?>">
<input type="submit" value="パスワード変更">
</form>
トークンの確認
session_start();
if (session_id() !== $_POST['token']) {
	die('<エラーメッセージ>');
}
// 以下、重要な処理

入力-確認-実行形式のように3段階以上の遷移がある場合でも、トークンを埋め込むページは実行の直前のページだけである。
また、トークンを受け付けるリクエスト(重要な処理を受け付けるリクエスト)はPOSTメソッドにする必要がある。GETメソッドで送信するとRefererにより機密情報が外部に漏れる可能性があるからである。

トークンには使い捨てのワンタイム・トークンがある。ワンタイム・トークンは必要になる度に生成する。
ワンタイム・トークンを利用する典型的なケースはリプレイ攻撃(Replay attack)対策が必要な場合である。リプレイ攻撃は暗号化されたリクエストを盗聴してその内容を丸ごと再送すること成りすましなどの攻撃をする手法である。
ワンタイム・パスワードの利用には以下のような主張がある。

  • CSRF攻撃は盗聴やリプレイ攻撃とは無関係であり、ワンタイム・トークンを用いる必然性はない。
  • ワンタイム・トークンがセッションIDをトークンとする方法に比べて安全になる根拠はない。
  • ワンタイム・トークンを用いることで正当な操作までエラーになる場合がある。

パスワードの再入力

パスワード再入力はCSRF対策以外に、次の目的で利用される。

  • 物品の購入などに先立って、利用者の意思を念押しして確認する。
  • 共有PCで別人が操作している状況などがなく、本当に正規の利用者であることを確認する。

ページが上記の要件を満たしている場合はパスワード再入力によってCSRF対策を行うとよい。逆にそれ以外のページ(ログアウト処理など)でパスワードの再入力を求めると、煩雑で使いにくくなる。

Refererのチェック

正規リクエストでは実行画面の1つ手前のページ(入力画面や確認画面など)に対するURLがRefererとしてセットされているはずなので、それをチェックする。

この方式の欠点は、Refererが送信されない場合はそのページを実行できないことである。セキュリティソフトやブラウザによってRefererを抑止している利用者もいる。携帯電話のブラウザではRefererが送信されないものや送信を制御できるものもある。

また、Refererのチェックには漏れが生じやすいので注意が必要である。下記は脆弱性があるチェックの実装の例である。"example.jp"の後のスラッシュをチェックしていないため、例えば"http://example.jp.trap.example.com/trap.html"がチェックを通過してしまう。

if (preg_match('#^http://example\.jp#', @$_SERVER['HTTP_REFERER']) !== 1) {
	// エラー処理
}

CSRF攻撃への保険的対策

重要な処理の実行後に、対象利用者の登録済みメールアドレスに対して処理内容の通知メールを送信することを推奨する。
万一CSRF攻撃を受けた場合に利用者が早期に気付くことができ、被害を最小限にとどめることができる可能性がある。
通知メールによってCSRF攻撃以外の攻撃で成りすましによって重要な処理が悪用されたことを早期に気付くことができるので、メリットが大きい。
ただし、通知メールには重要情報は含ませず、重要な処理が実行されたことのみを通知するにとどめるべきである。詳細内容はWEBアプリケーションにログインして閲覧してもらうようにする。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.5.1 クロスサイト・リクエストフォージェリ(CSRF)

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

« October 2013 | Main | December 2013 »

March 2017
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
無料ブログはココログ

日本blog村

  • にほんブログ村 IT技術ブログへ
  • にほんブログ村 アニメブログへ
  • にほんブログ村 サッカーブログ アルビレックス新潟へ

好きな音楽家

メモ

XI-Prof