My Photo

« November 2013 | Main | January 2014 »

December 24, 2013

秀丸エディタのマクロにおける配列

秀丸エディタのマクロには配列がなくて不便だなと思っていたが、ちゃんとあった。
他の言語にあるような波括弧を使って複数の要素で一気に初期化することはできないので使い勝手はよくないが、ないより全然いい。
以下、簡単な例。1行ずつ"aaa","bbb","ccc"を挿入する。

$array[0] = "aaa";
$array[1] = "bbb";
$array[2] = "ccc";

#i = 0;
while ($array[#i] != "") {
	insert $array[#i];
	insert "\n";
	#i = #i + 1;
}

December 22, 2013

クッキーのSecure属性不備

発生箇所 セッションIDを踏めてクッキーを発行している箇所すべて
影響を受けるページ HTTPS通信を利用し、かつ認証のあるページすべて
影響の種類 成りすまし
利用者の関与の度合い HTTPSのみのサイトの場合は必要(リンクのクリックなど)
HTTPとHTTPS混在のサイトでは不要

概要

クッキーにはSecureという属性があり、これを指定したクッキーはHTTPSの場合のみブラウザからサーバに送信される。アプリケーションがHTTPS通信を利用していても、Secure属性のついていないクッキーは平文で送信される場合があり盗聴される可能性がある。
HTTPとHTTPSの混在するサイトでは、セッションIDに対してクッキーのSecure属性を設定するとアプリケーションが動かなくなる場合がある。その場合、セッションIDとは別にトークンをSecure属性付きクッキーとして発行して、ページ毎に確認する方法がある。

攻撃手法

次の手順で平文のクッキーがネットワーク上に流れる。

まず、HTTPSでかつSecure属性のつかないクッキーを発行するページを閲覧し、ブラウザーにクッキーをセットする。例としてURLは https://www.example.jp/set_non_secure_cookie.php とする。
次に罠ページを閲覧する。罠ページには下記のような見えないimgタグ(幅と高さが0)が含まれている。

<img src="http://www.example.jp:443/trap/ width="0" height="0" />

URLで指定されたポート番号443はHTTPSのデフォルトポートだが、スキームが「http:」と指定されているのでこのリクエストは暗号化されずに送信される。ブラウザにクッキーを送信させるのが目的なので、URLの画像はなくても攻撃は成立する。
攻撃者がこの暗号化されていないクッキーを盗聴できる場合、セッションハイジャックに悪用できる。

脆弱性の原因

直接の原因は単にSecure属性を付けていないというだけのことだが、Secure属性を付けない主な原因は以下の2種類があると思われる。

  • 開発者がSecure属性について知らない。
  • Secure属性を付けるとアプリケーションが動かなくなる。

クッキーにSecure属性が付けられないアプリケーション

Webアプリケーションの中にはHTTPとHHTPSの両方を使うものがある。多くのショッピングサイトは、カタログページで商品を選ぶ際にはHTTPを、商品を選び終わって決済する段階ではHTTPSを利用する。
HTTPとHTTPSが混在するWebアプリケーションの場合、セッションIDを保持するクッキーにSecure属性を設定することは困難である。仮にセッションIDのクッキーにSecure属性を付けると、HTTPのページではセッションIDのクッキーが受け取れないのでセッション管理機構が使えなくなる。HTTP側のページでもショッピングバスケットの実現などにセッション管理機構は利用したいので、HTTPSを利用するサイトの多くがセッションIDのクッキーに対してSecure属性を付けていないのが現状である。

対策

セッションIDのクッキーにSecure属性を付ける

クッキーのSecure属性不備の対策はクッキーにSecure属性を付けることである。
PHPではphp.iniに以下の設定をする。

session.cookie_secure = On

Aapache Tomcatの場合、HTTPS接続されたリクエストに対して、セッションIDのクッキーには自動的にSecure属性が設定される。

トークンを用いた対策

セッションIDを保持するクッキーにSecure属性が付けられない場合、トークンを利用してセッションハイジャックを防止する方法がある。
トークンを保持するクッキーにSecure属性を付けることによって、HTTPページとHTTPSページでセッションを共有しつつ、仮にセッションIDを盗聴された場合でもHTTPSページはセッションハイジャックを防止できる。
トークンを設定するコードのサンプル。

// /dev/urandomによる擬似乱数発生器
function getToken() {
	$s = file_get_contents('/dev/urandom', false, NULL, 0, 24);
	return base64_encode($s);
}

// ここまでで認証が成功していると想定

session_start();
session_regenerate_id(true);	// セッションIDの再生成
$token = getToken();	// トークンの生成
// トークンクッキーはSecure属性を付けて発行する
setcookie('token', $token, 0, '', '', true, true);
$_SESSION['token'] = $token;

トークンを確認するコードのサンプル。

session_start();
// ユーザIDの確認(省略)

// トークンの確認
$token = $_COOKIE['token'];
if (!$token || $token != $_SESSION['token']) {
	die('認証エラー。トークンが不正です。');
}

HTTPSでトークン設定のページにアクセスしトークン確認のページに遷移すると、トークンの確認に成功する。
HTTP(非SSL)で同じ遷移をすると、トークンのクッキーはSecure属性付きなのでトークン確認のコードはトークンを受け取れず、トークン確認は失敗する。

トークンにより安全性が確保できる理由

  • トークンは認証成功時に一度だけサーバから出力される。
  • トークンはHTTPSのページで生成される(サーバ→ブラウザ)
  • トークンは確実に暗号化されてブラウザから送信される(ブラウザ→サーバ)
  • HTTPSのページを閲覧するにはトークンが必須。

すなわち、トークンがサーバとブラウザの双方向で確実に暗号化されること、HTTPSのページを閲覧するには第三者の知り得ないトークンが必要であることから安全性が確保されていることになる。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.8.2 クッキーのセキュア属性不備

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

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

Amazonで詳しく見る
by G-Tools

December 15, 2013

クッキーの不適切な利用

Webアプリケーションでページをまたがる情報を保存する方法としては、PHPやServletコンテナなどが提供するセッション管理機構が用いられる。
一般的にセッション管理機構ではセッションIDのみをクッキーに保存し、データ自体はWebサーバのメモリやファイル、DBなどに保存する。

クッキーに保存すべきではない情報

クッキーにデータを保存することにより脆弱性となる場合を説明する。セッション変数は外部から書き換えができないのに対して、クッキーはアプリケーション利用者によって書き換えることができる。このため、書き換えると困る情報をクッキーに保存すると脆弱性の原因になる。
例えば、ユーザIDや権限情報をクッキーに保存していたため、権限外の操作や情報閲覧ができてしまう場合がある。

脆弱性とはならない場合でも、一般的にクッキーにデータを保存しないことが推奨される。

クッキー セッション変数
使いやすさ APIにより設定、取得 変数とほぼ同じように使える
配列やオブジェクトの格納 アプリケーション側で文字列に変換する必要あり 通常の変数同様に代入可能な場合が多い
サイズの制限 厳しい制限あり 実用上は無制限
利用者による格納情報の直接参照 容易 不可能
脆弱性などでクッキーが漏洩した際の情報漏洩しやすさ クッキーが漏洩するとデータも漏洩 漏洩のしにくさを制御可能
利用者によるデータ改ざん 容易 不可能
第三者によるデータ改ざん XSSやHTTPヘッダ・インジェクションなどの脆弱性があれば可能 クッキーを改変できる脆弱性があってもセッション変数は改変不可能
情報の寿命の制御 容易 セッション限り
異なるサーバとの情報共有 ドメインが同じであれば可能 基本的には不可能

表に示すように、クッキーで実現できてセッション変数で実現できない項目は情報の寿命の制御と異なるサーバとの情報共有だけである。
セッション変数で「漏洩のしにくさを制御可能」というのは、次のような理由からである。Webアプリケーションでは機密性の高い情報を表示する場合にパスワードの再入力(再認証)を求めるように実装することができる。また、セッションに保存されている情報はセッションタイムアウトすると表示されなくなる。クッキー自体に情報を保存している場合は、このような制御は困難である。
セッションやサーバをまたがって情報を保存する必要性がある場合には、クッキーを使用する。例としては、ログイン画面における「ログイン状態を保持する」という機能がある。この場合でもクッキーに保存すべき情報はトークンと呼ばれる乱数であって、IDやパスワードなどをデータとしてクッキーに保存するわけではない。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.8.1 クッキーの不適切な利用

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

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

Amazonで詳しく見る
by G-Tools

December 08, 2013

ペーパードライバー講習を申し込んだ

今年の夏ぐらいから「車の運転したい」という欲求が急激に高まった。
釣り行くときの足として車を使いたいとか、いろいろ理由がある。

車を持つのは金銭的に無理なので、先日、カーシェアリングサービスに入会した。
そして昨日、自動車学校でペーパードライバー講習の申し込みをしてきた。

ペーパードライバー講習にも教習所と出張の2種類がある。出張でも教習車を使うのと自分の車を使うのがある。
色々と検討して、電車で数駅先にある教習所を選んだ。
講習代を先払いして講習毎に予約を取るタイプ。「講習4回で38,000円」みたいなパック料金ではないので、自分の納得いくまで何回でも講習を受けられる(講習料金は先払い)。逆に1回で「もう大丈夫」と思えば1回で終わることもできる。
入所料を取られるが、講習1回あたりの料金はまあ良心的な感じがする。だだし、入所料の有効期間は3ヶ月で、3ヶ月を超えてさらに講習を受ける場合はまた入所料を取られる。
あと、高速料金は通常の講習の3倍以上のお値段。高速教習は時間も3倍なのか?

窓口の人の説明では今は繁忙期なので予約が取れるのは10日以上先とのこと。
#大学はもう冬休み?
これは「最初の予約は10日以上先しか取れない」なのか、「今後も予約する日から10日以上先の予約しか取れない」という意味なのか、イマイチわからなかった。
最初の1回は必ず所内のコースでの教習だそうだ。路上で練習したいのでとりあえず2回分の予約(21日、28日)を取った。路上を走るのはだいぶ先だ。
#1回目で指導員が「路上はムリ」と言ったら2回目も所内になる^^;
高速教習も指導員がOKしないと受けれない。

今のところ路上講習を1,2回受けて、あと高速教習を1回受けるつもり。

psqlでパスワード入力の省略

psqlについての以前の記事:
PostgreSQLのコマンドラインクライアントpsql: ぷ~ろぐ

参考ページ:
PostgreSQLでパスワードを省略する(.pgpass)(PostgreSQL)--WEBシステム開発 技術的備忘録(通称 技忘録)
PostgreSQLでパスワードを省略(Windows編)(PostgreSQL)--WEBシステム開発 技術的備忘録(通称 技忘録)
パスワードファイル

バッチファイル内でpsqlを使うときに対話的なパスワード入力を省略する方法。
"%APPDATA%\postgresql\pgpass.conf"(自分のWindows7のPCの場合は "C:\Users\<ユーザ名>\AppData\Roaming\postgresql\pgpas.conf")に以下の書式で接続情報を書いておく。psqlの接続時に指定した接続先と pgpass.conf に含まれる接続先が一致すれば、パスワード入力なしで接続する。

hostname:port:database:username:password

例えば、pgpass.confの内容が以下であったとする。

dbserver1:5432:dbtest:uesr1:password1

pgpass.conf のユーザ名とパスワードが正しければ、コマンドラインから以下のようにパスワード入力無しでログインできる。

C:\Users\user1>psql -h dbserver1 -U user1 dbtest
psql (9.0.9)
"help" でヘルプを表示します.

dbtest=>

December 01, 2013

HTTPヘッダ・リダイレクション

発生箇所 リダイレクトやクッキー生成など、外部から指定したパラメータに基づいてHTTPレスポンスヘッダを出力している箇所
影響を受けるページ 直接的には脆弱性のあるページが影響を受けるが、任意のJavaScript実行により成りすましをされ、最終的にはアプリケーションのすべてのページが影響を受ける。
影響の種類
  • 成りすまし
  • 偽ページの表示
  • キャッシュ汚染
利用者の関与の度合い 必要(罠ページの閲覧、メール添付のURLの閲覧など)

概要

HTTPヘッダ・インジェクション脆弱性はリダイレクトやクッキー発行など外部からのパラメータを元にHTTPレスポンスヘッダを出力する際に発生する脆弱性である。
レスポンスヘッダを出力する際のパラメータ中に改行を挿入することによって、被害者のブラウザ上で以下を引き起こす。

  • 任意のレスポンスヘッダ追加
  • レスポンスボディの偽造

HTTPヘッダ・インジェクション脆弱性を悪用した攻撃により、以下の影響があり得る。

  • 任意のクッキーの生成
  • 任意のURLへのリダイレクト
  • 表示内容の改変
  • 任意のJavaScript実行によるXSSと同様の被害

攻撃手法

例として、GETパラメータurlで指定されたURLを受け取り、Locationヘッダを出力してリダイレクトするスクリプトを考える。 このスクリプトを

http://example.jp/redirect.cgi?url=http://exmple.jp/%0D%0ALocation:+http://trap.exemp.com/trap.php

でアクセスすると、"http://trap.exemp.com/trap.php" にリダイレクトされる。
これはパラメータurlの値の中に改行(%0D%0A)があるためである。スクリプトが以下に示すように2行のLocationヘッダを出力する。AapcehはCGIから受け取ったヘッダ中に複数のLocationヘッダがあると、最後のLocationヘッダのみをレスポンスとして返す。結果として "http://trap.exemp.com/trap.php" にリダイレクトされる。

Location: http://example.jp/
Location: http://trap.example.com/trap.php

HTTPレスポンス分割攻撃

HTTPレスポンス分割攻撃(HTTP Response Splitting Attack)は、HTTPヘッダ・インジェクション攻撃により複数のHTTPレスンポンスを作り出してキャッシュサーバ(プロキシサーバ)に偽のコンテンツをキャッシュさせるという攻撃手法である。
HTTP1.1では複数のリクエストをまとめて送信することができる。この場合、レスポンスもまとめて返される。
そこで、攻撃側はHTTPヘッダ・インジェクション攻撃を行うHTTPリクエスト(第1リクエスト)の後に偽のコンテンツをキャッシュさせたいURLに対応したHTTPリクエスト(第2リクエスト)を付加する。
このとき第1リクエストのHTTPヘッダ・インジェクション攻撃により偽のコンテンツをHTTPレスポンスに挿入させると、キャッシュサーバがこの偽のコンテンツを第2リクエストに対するHTTPレスポンスと認識してキャッシュする。この攻撃はキャッシュ汚染とも呼ばれる。
HTTPヘッダ・インジェクション攻撃単独では攻撃を受けた利用者のみが一時的に影響を受ける。対してキャッシュ汚染の場合は複数の利用者が持続的に影響を受ける可能性があり、影響度が大きい。

脆弱性の原因

HTTPレスポンスヘッダはテキスト形式で1行に1つのヘッダを定義できる。つまりヘッダとヘッダは改行で区切られる。
この性質を悪用して、リダイレクト先URLやクッキー値として利用されるパラメータ中に改行を挿入した場合、改行がそのままレスポンスとして出力されることがこの脆弱性の原因である。

対策

対策1:外部からのパラメータをHTTPレスポンスとして出力しない

設計段階で外部からのパラメータをHTTPレスポンスヘッダとして出力しないことを検討するべきである。以下の方針に従えばよい。

  • リダイレクト先を固定にするか番号で指定する
  • セッション変数を使って値を受け渡す

対策2:以下の両方を実施する

どうしても外部からのパラメータをHTTPレスポンスヘッダとして出力しなければならない場合は、以下の対策を実施する。

  • リダイレクトやクッキー生成を専用APIに任せる
  • ヘッダ生成に使うパラメータの改行文字をチェックする

PHPではクッキー生成には setcookie()/setrawcookie()、その他のヘッダの出力にはheader() がある。ただし、現状ではこれらを使用しても完全な脆弱性対策にはならない。よって、アプリケーション側でパラメータの改行文字をチェックを行う。
改行文字に対する処理方法にはいかがある。

  • URL中の改行はエラーとする。
  • クッキー値の改行はパーセントエンコードする。

ただし、ライブラリ側でクッキー値をパーセントエンコードしている場合はアプリケーション側でする必要はないので開発前に調査が必要である。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.7.2 HTTPヘッダ・インジェクション

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

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

Amazonで詳しく見る
by G-Tools

2014冬アニメ視聴予定

2014年冬季(新春)開始の新作アニメ一覧 - GIGAZINE

とりあえず見てみようと思うのは

隣の関くん
生徒会役員共*
鬼灯の冷徹
世界征服~謀略のズヴィズダー

自分としてはすごい楽しみ!!ってのがない。

関くんと鬼灯は原作マンガが人気だが、自分は未読。
鬼灯は「聖おにいさん」が好きな人には合うという話を聞いたが、自分は「聖おにいさん」を巷の評判ほどは面白いと思わなかった。

ズヴィズダーは監督・キャラクターで選んだ。岡村監督作品はビバップとDTBの1期は好きだが Wolf's Rain は合わなかったし、DTB2期は「1期の方が良かった」という印象。黒星紅白はサモンナイトシリーズのキャラクターデザインをしている人。
俺が今まで見た岡村監督作品はビバップ以外は「世界設定における謎が最後まではっきりとは明かされない」というイメージがある。世界設定は重要じゃない、作品中で語られる話が重要なんだってことだろうか。でも俺はなんかモヤモヤしてしまった。DTBなら「結局『契約者』とは何なの?」という疑問について、何か答えを示してほしかった。
今回の作品は現時点で明かされている内容からすると Wolf's Rain やDTBほどシリアスな感じではなさそうだが、はてさて。

生徒会役員共の2期は1期がかなり楽しめたから、まあ大丈夫だろう。WEBラジオも面白かった。というかWEBラジオの方が面白かった^^;

今見てる作品でヴァルヴレイヴと物語シリーズは12月で終わるし、のんのんびよりとコッペリオンとキルラキルも1クール作品だろうと思ってる。続くのはログ・ホライズンだけかなと。
よって、1月以降見るアニメは継続作1本+新作4本、今期と変わらず5本/週の予定。

« November 2013 | Main | January 2014 »

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