ChaichanPapa-World !

燈明日記(2010/05

◆ インデックス

◆ 2010年5月

2010-05-31 URLパラメータとGETパラメータの関係とは(バージョンアップ版)

URLパラメータは、ブラウザのアドレス欄に表示されるURLの「?」以降の文字列のことです(たぶん)。

GETパラメータは、form要素のmethod属性に"get"と指定してサブミットした時にアドレス欄に表示されるURLの「?」以降の文字列のことです(たぶん)。


通常、form要素のmethod属性に"post"を指定して、action属性にURLパラメータを指定すると、サーバー側では、postのデータは標準入力で、URLパラメータは環境変数で取得することができます。

また、form要素のmethod属性に"get"を指定すると、サーバー側では、環境変数で取得することができます。


では、form要素のmethod属性に"get"を指定して、action属性にURLパラメータを指定すると、サーバー側では、どのようになると思いますか?


そう、URLパラメータもGETパラメータも単独では環境変数にセットされるのですが、この2つが重なったときは、GETパラメータとなり、URLパラメータは無視されるのです。

これ、IE6,IE7,Opera10,Firefox3で同じ結果になりました。

以下は、そのサンプルソースです。


◆ サンプルソース テストフォーム(test_get.cgi)
#!c:/perl/bin/perl.exe
use strict;

print <<"HERE1";
Content-type: text/html; charset=Shift_JIS

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<title>Test Form</title>
</head>
<body>
<h1>Test Form</h1>
<form method="get" action="test_get2.cgi?ID1=1&ID2=2" name="FM">
<p><input type="hidden" name="ID3" value="3"></p>
<p><input type="hidden" name="ID4" value="4"></p>
<p><input type="submit" value="実行"></p>
</form>
</body>
</html>
HERE1

◆ サンプルソース QUERY_STRING表示(test_get2.cgi)
#!c:/perl/bin/perl.exe
use strict;

# 画面出力
print <<"HERE1";
Content-type: text/html; charset=Shift_JIS

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<title>QUERY_STRING</title>
</head>
<body>
<h1>QUERY_STRING</h1>
<p>---------->$ENV{'QUERY_STRING'}<--------</p>
</body>
</html>
HERE1

また、GETパラメータだとhiddenにしてもアドレス欄に表示されてしまいますね(hiddenじゃない!)。

セキュリティ的には、form要素のmethod属性は"post"の方が安全ですね!

2010-05-29 トビラ / a pool par

トビラは、a pool parのオープニングの曲で、もう定番ですかね!

トビラで、お客さんの気持ちを掴んで、あとは、Dくんとkanaeちゃんのバラードでお客さんのハートを掴んで、最後はシャイニングロードでぶちかます!!

a pool parは、すごくカッコイイバンドになってきていると思います。

あとは、なにでブレイクするかですね。

もちろん、練習も沢山して、技術を磨いとかないと、ブレイクが逃げてくよ!


しかし、ヒロちゃん(長男)は、相変わらず叫んでいるだけだな…。

ヒカルさんのドラムとDくんのギターは、迫力があるね!

kanaeちゃんのキーボードもいいし、サポートのシュウヘイさんのベースもいいよ。

問題は、ヒロちゃんの歌とギターがもう少し上手くなるとかなり完成度が上がるね!


D


このトビラ、意外とリードギターの始めのフレーズが耳に残っていい感じです(Dくん、いいよ!)。



◆ a pool par のご紹介

2009年10月頃、長男こと小池啓仁を中心に結成されました。

っていうか、長男が強引にメンバーを引きずり込んだという噂が…。

(メンバーのみなさん、長男がいつもご迷惑をお掛けしています)


・メンバー

・サイト&ブログ

2010-05-28 気になるニュース

◆<米アップル>株式時価総額マイクロソフト抜くITで首位

今度は、Googleがアップルを抜く日が来るのでしょうね!

まぁ、マイクロソフトは退場願います。


◆ライブドア、優れたブロガーに最大300万円を支給する「ブログ奨学金」開始

魅力ですね。はてなでも「ブログ奨学金」開始をしてください!


◆北朝鮮、韓国との全関係断絶を宣言

この国、はやくなんとかならないですかね…。


◆署名拒否の福島消費者相を罷免

福島さんには、頑張れ!って、それだけ言っておきます。

鳩山さんには、リーダ失格!って、それだけ言っておきます。


◆タブレット端末が主戦場に

こんなPCいらない!って、それだけ言っておきます。


◆宮崎県、種牛49頭殺処分へ=2頭で口蹄疫の症状

殺処分が牛でなくて、人間だったらと思うとぞっとします…。

殺処分でなくて、口蹄疫の特効薬はできないものなのですかね?

2010-05-28 シャイニングロード / a pool par

昨日(5/27)、東京吉祥寺のシルバーエレファント(ライブハウス)で a pool par のライブがありました。

長男(小池啓仁)から、a pool parの代表曲『シャイニングロード』をユーチューブにアップしたいとのことで頼まれました。


で、昨日会社から家に帰ってきて食事をしたあと吉祥寺にバスで行きました。

吉祥寺は、地元で一番の繁華街で子供の頃から庭のようなもので、シルバーエレファントには、迷子にならずに行けました。


ライブの出来は、a pool par以外のライブもありましたが、a pool parがダントツでよかったような気がしました。

まぁ、見てもらえれば一目瞭然ですが、長男は、歌っているのではなく、ただ叫んでいるだけですね!

すごく、楽しそうにやっているのが救いです。まぁ、見てやってください!


D


よく見ると、意外とカッコよく撮れている!

みんな、カッコイイ!!


◆ a pool par のご紹介

2009年10月頃、長男こと小池啓仁を中心に結成されました。

っていうか、長男が強引にメンバーを引きずり込んだという噂が…。

(メンバーのみなさん、長男がいつもご迷惑をお掛けしています)


・メンバー
・サイト&ブログ

2010-05-26 URLパラメータとGETパラメータの関係とは

本記事は以下が最新です。




URLパラメータは、ブラウザのアドレス欄に表示されるURLの「?」以降の文字列のことです(たぶん)。

GETパラメータは、form要素のmethod属性に"get"と指定してサブミットした時にアドレス欄に表示されるURLの「?」以降の文字列のことです(たぶん)。


通常、form要素のmethod属性に"post"を指定して、action属性にURLパラメータを指定すると、サーバー側では、postのデータは標準入力で、URLパラメータは環境変数で取得することができます。

また、form要素のmethod属性に"get"を指定すると、サーバー側では、環境変数で取得することができます。


では、form要素のmethod属性に"get"を指定して、action属性にURLパラメータを指定すると、サーバー側では、どのようになると思いますか?


そう、URLパラメータもGETパラメータも単独では環境変数にセットされるのですが、この2つが重なったときは、GETパラメータとなり、URLパラメータは無視されるのです。(IE7で確認しています。他のブラウザでは違う結果になる場合があるかもです…はてブでご指摘をうけました)

また、GETパラメータだとhiddenにしてもアドレス欄に表示されてしまいますね(hiddenじゃない!)。


セキュリティ的には、form要素のmethod属性は"post"の方が安全ですね!

2010-05-25 クッキーなしでもセッション管理ができる?

昨日の記事で、『httpはステートレスなので、httpを使っている以上、セッション管理はクッキーが必須』と書きましたが、厳密には間違いでした。


Javaのセッションオブジェクトではメモリ、PerlのCGI::Sessionモジュールでは、ファイルやDBにセッション情報を保持し、セッションIDをhiddenパラメータやURLパラメータで引き渡し、セッション情報にセッションIDを問い合わせることでセッション管理をすることができますね。

ですので、クッキーは必要ありません。


しかし、hiddenパラメータやURLパラメータは、htmlのソースがブラウザで丸見えなので簡単に改ざんされるケースが否定できないです。

やはり、セッションIDは、安易に改ざんできないクッキーで渡すのが一番なんですかね。

また、httpsの場合は、クッキーにsecure属性を指定すれば、ほぼ完璧に安全ですね。


ということで、以下はセッションID引き渡しの安全順です。

  1. クッキーにsecure属性つけてセッションIDを引き渡す。
  2. クッキーでセッションIDを引き渡す。
  3. hiddenパラメータでセッションIDを引き渡す。(セッションIDが改ざんされ易い)
  4. URLパラメータでセッションIDを引き渡す。(ブラウザのアドレス欄にセッションIDが表示される)

2010-05-24 httpを使っている以上、セッション管理はクッキーが必須?

httpはステートレスなので、httpを使っている以上、セッション管理はクッキーが必須です(たぶん)。

携帯サイトでは、セッション管理をクッキーでなくケータイID認証で行う限り、脆弱性が無くならないとのことです。

これは、auとSoftBankが98%以上クッキー対応なのに、ドコモは28%という現状が原因なんですね。

ここのところ、高木先生のブログを読み漁っています。


そうそう、クッキーといえば、最近以下の記事を書きました。

2010-05-23 復号化か復号か?

平文を暗号化して、それを元に戻すことは、復号化か復号かの『化』を付けるか付けないかが、気になりました。

平文を暗号文にするには、暗号に変化させるので、暗号化で自然です。


しかし、暗号文を復号するには、復号に変化させるとは、いいません。

復号だけで、『化』の意味が含まれているのですね。


なので、今回、『WEB暗号化基礎知識最速マスター』では、復号化ではなく復号としました。

しかし、『WEB脆弱性』は、はてブが1500近く行ったのに、『WEB暗号化』は、ほぼ空振りですね。


自分としては、『WEB暗号化基礎知識最速マスター』も良い感じでまとまったと思うんだけれど…。

皆さま、『WEB暗号化基礎知識最速マスター』もよろしくお願い致します。


2010-05-22 WEBプログラマー必見!WEB暗号化基礎知識最速マスター

以下は、WEBプログラマー用のWEB暗号化の基礎知識の一覧です。

WEBプログラマーの人はこれを読めばWEB暗号化の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。

また、WEB暗号化の簡易リファレンスとしても少し利用できるかもしれません。

しかし、WEBアプリケーションを開発するには、暗号そのものを知らなくても、実は大丈夫なのです。

そう、OSI参照モデルのレイヤー(層)がWEBアプリケーションは7層で、暗号は5層になっているからです。

でも、httpsでの暗号や認証の方法が謎なので、やはり気になりますね。


今回、WEBで使われているhttpsのsの部分について調べてみました。

それには、まず『暗号とは』から始まって、『暗号方式』、『認証方式』そして、httpsのsの部分について解説していきますね。

また最後に、暗号技術の分類をご紹介します。

このまとめがWEBアプリケーション開発の参考になれば幸いです。


尚、本コンテンツを作成するにあたって、以下のリンク先を大変参考にさせて頂きました。

下記のリンク先は、凄く勉強になりました。謹んで御礼申し上げます。


◆参考リンク



◆暗号とは

暗号とは、大辞泉では、『通信の内容が相手以外にわからないように、当事者の間だけで決めた記号』となっています。

通信の内容の元の文章を「平文」といい、これを相手以外にわからないように「暗号文」に変換することを暗号化といいます。

一方、「暗号文」を元の文章に戻すことを復号といい、暗号化や復号を行う手順を「アルゴリズム」といいます。

また、当事者の間だけで決めた暗号化に用いるパラメータのことを「鍵」といいます。


整理すると、暗号には、以下の4つの要素があります。

  1. 平文
  2. 暗号文
  3. アルゴリズム

■シーザー暗号での例

この要素について、シーザー暗号に当てはめてみると…まずは、シーザー暗号とは

古来から伝わる暗号化の方式としてシーザー暗号というのものがあります。

仕組みはとても簡単で、下の表のように文字列をアルファベット順に

数個ずらすだけです。この例では A〜Z を F〜Z・A〜E と、5つずらしています。

ABCDEFGHIJKLMNOPQRSTUVWXYZ
FGHIJKLMNOPQRSTUVWXYZABCDE

例えば「I LOVE YOU」というメッセージをこのシーザー暗号で

暗号化すると「N QTAJ DTZ」という暗号文になります。

暗号文を受信した側は、F〜Z・A〜E を 5つずらして A〜Z

に戻せば「I LOVE YOU」という平文が手に入ります。

http://x68000.q-e-d.net/~68user/net/crypt-1.html

尚、「5文字」の鍵は、暗号化と復号で一つ(共通)ですが、暗号化は5文字後ろにずらし、復号は5文字前にずらします。

これは、ドアの鍵が一つで、右に回すとロックされ、左に回すとアンロックされるのと同じ感じです。


ついでにPerlでシーザー暗号してみました。


■実装仕様

仕様としては、アルファベット26文字のみ暗号化します。

暗号化(CaesarCipherEnc)としては、引数に平文とローテート数を指定します。

復号(CaesarCipherDec)としては、引数に暗号文とローテート数を指定します。


■サンプルソース(ango.pl)
use strict;
use warnings;

    # 暗号化
    my $ans = CaesarCipherEnc('I LOVE YOU', 5);
    print $ans, "\n";

    # 復号
    $ans = CaesarCipherDec($ans, 5);
    print $ans, "\n";

sub CaesarCipherEnc {
# 第1引数は平文
# 第2引数はローテート数で0〜26
my ($intext, $rotate) = @_;
my  $wkABC1 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ';
    return '引数エラー!' if (($rotate < 0) or ($rotate > length($wkABC1)/2));

my  $wkABC2 = substr($wkABC1, $rotate, length($wkABC1)/2);
    $_ = $intext;
    eval "tr/$wkABC1/$wkABC2/";
    return $_;
}

sub CaesarCipherDec {
# 第1引数は暗号文
# 第2引数はローテート数で0〜26
my ($intext, $rotate) = @_;
my  $wkABC1 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ';
    return '引数エラー!' if (($rotate < 0) or ($rotate > length($wkABC1)/2));

my  $wkABC2 = substr($wkABC1, length($wkABC1)/2 - $rotate, length($wkABC1)/2);
    $_ = $intext;
    eval "tr/$wkABC1/$wkABC2/";
    return $_;
}

■サンプルソースの実行結果
C:\Documents and Settings\hoge>perl ango.pl
N QTAJ DTZ
I LOVE YOU

■サンプルソースのポイント

アルファベットの変換にtr///を使用してます。

tr///は、s///と違って、文字列単位の置換ではなく、1文字単位の変換です。

また、tr///は、普通、変数を指定することはできませんが、evalを使うことにより可能にしています。

これは、"tr/$wkABC1/$wkABC2/"の文字列展開をした後にevalで実行ができるためです。

また、『eval "tr/$wkABC1/$wkABC2/";』で変換されるべき変数は『$_』なので、先に$intextを$_に代入しています。



◆暗号方式

つぎに暗号方式には、共通鍵暗号方式と公開鍵暗号方式の2つと、この両方を使うハイブリッド方式などがあります。


■共通鍵暗号方式

たとえば、Aさんは、Bさんへメールをしたいのですが、盗聴が気になるので暗号化して送るとします。

そこで、Aさんは、鍵を使ってメールを暗号化して、Bさんへ送りました。

Bさんは、受け取った暗号化されたメールをAさんと同じ鍵を使って復号しました。

このように、AさんとBさんが同じ鍵を使って暗号文のやりとりを共通鍵暗号方式と言います。

しかし、決定的な欠点がありますね。そう、AさんとBさんは、予め同じ鍵をもっていないとなりません。

つまり、暗号化して送っても同じ鍵をもっていないと復号が出来ないのです。

そこで、この欠点を補う公開鍵暗号方式が出てきました。


・共通鍵暗号方式をまとめると

  1. 送信者は、平文を共通鍵で暗号化して送信します。
  2. 受信者は、暗号化された平文を共通鍵で復号します。

■公開鍵暗号方式

共通鍵暗号方式は、暗号化と復号を同じ鍵(共通鍵)を使いました。

しかし、公開鍵暗号方式は、暗号化と復号で別の鍵を使用するのです。

そして、暗号化する鍵は、公開してしまうのです!

まず、AさんはBさんの公開鍵でメールを暗号化して送ります。

Bさんは、自分が持っている秘密鍵でこのメールを復号するのです。

これで、共通鍵暗号方式の欠点を補えました。

しかし、公開鍵暗号方式は、暗号化・復号に非常に時間がかかる(共通鍵方式の数百〜千倍遅)という欠点があるのです。

そこで、この欠点を補う「共通鍵を公開鍵方式を用いて暗号化する」というハイブリッド方式が出てきました。


・公開鍵暗号方式をまとめると

  1. 送信者は、受信者の公開鍵を取得します。
  2. 送信者は、平文を公開鍵で暗号化して送信します。
  3. 受信者は、暗号化された平文を秘密鍵で復号します。

■ハイブリッド方式

ハイブリッド方式は、共通鍵暗号方式と公開鍵暗号方式のハイブリッドです。

まず、Aさんは、暗号化が速い共通鍵でメールを暗号化します。

つぎに、Aさんは、Bさんの公開鍵で共通鍵を暗号化します。

そして、暗号化された共通鍵とメールを一緒にBさんへ送ります。

一方、Bさんは、暗号化された共通鍵を秘密鍵で復号します。

つぎに、Bさんは、復号された共通鍵でメールを復号します(めでたしめでたし)。

実は、これ、httpsもこの方式なのです!


・ハイブリッド方式をまとめると

  1. 送信者は、平文を共通鍵で暗号します。
  2. 送信者は、受信者の公開鍵を取得します。
  3. 送信者は、共通鍵を公開鍵で暗号化します。
  4. 送信者は、暗号化した共通鍵と平文を送信します。
  5. 受信者は、暗号化された共通鍵を秘密鍵で復号します。
  6. 受信者は、暗号化された平文を共通鍵で復号します。


◆認証方式

httpsの認証方式は、公開鍵証明書に基づく認証です。

通常、サーバだけが証明書を提示し、クライアントがその正当性を確認します。

そして、なりすましを防ぐために、証明書には認証局 (CA; Certification Authority) による電子署名が必要となります。


■電子署名について

電子署名は、同じ内容の平文と秘密鍵での暗号文を送って、送られた方は、公開鍵で暗号文を復号して、平文と同じになれば、署名が正しとします。

しかし、このままでは、公開鍵暗号方式なので暗号化・復号に非常に時間かかります。

そこで、ハッシュ(128〜512 bit 程度なので暗号化・復号に時間がかからない)という機能を使い、平文をハッシュ値にして、それを暗号化し平文と一緒に送ります。

送られた方は、まず、暗号化されたハッシュ値を公開鍵で復号し、つぎに平文のハッシュ値を求め、両方が一致したら署名が正しいことがわかります。


・留意点

電子署名について公開鍵暗号方式が使えるのは、暗号アルゴリズムがRSAの時だけです。

実際の電子署名でのアルゴリズムは、署名専用のDSAが使われることが多いとのことです。

また、秘密鍵で平文を暗号化しても、誰でも公開鍵で復号できるので、広い意味で暗号ではないですね。


・電子署名をまとめると

  1. 送信者は、平文をハッシュ値に変換します。
  2. 送信者は、ハッシュ値を秘密鍵で暗号化します。
  3. 送信者は、平文と暗号化されたハッシュ値を送信します。
  4. 受信者は、暗号化されたハッシュ値を公開鍵で復号します。
  5. 受信者は、平文をハッシュ値に変換します。
  6. 受信者は、両方のハッシュ値が一致したら電子署名が正しいと判断します。

ちなみに、なぜ、同じ内容の平文と暗号文を送って、受け取り側で暗号文を復号した結果、平文と同じになると電子署名が正しいとするかは、送り側が本人以外誰も知らない秘密鍵で暗号化するからです。

つまり、本人以外誰も知らない秘密鍵で暗号化ができ、それを復号して平文と内容が一致すれば、確かに本人の署名と言えるわけです。



◆httpsのsの部分

httpsのsの部分は、Secure Sockets Layer(セキュアソケットレイヤー、SSL)のsで、セキュリティーを要求される通信のためのプロトコルです。

始めに、ブラウザから『https://』のWEBページにアクセスすると、WWWサーバとブラウザの間で双方で使用できる暗号を確認し決定します。

つぎに、ブラウザは、WWWサーバからの証明書を受け取り、証明書内の『認証局』で署名された電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します。(要はWWWサーバが本物かの認証確認)

正当性を確認したら、ブラウザは次ぎに、通信で使用する共通鍵を生成し、先のWWWサーバの証明書に含まれていたサーバの公開鍵(予めブラウザが持っている公開鍵とは別物)で暗号化して、WWWサーバに送信します。

WWWサーバは、それを秘密鍵で復号して共通鍵を求めます。

以後は、この共通鍵で暗号化された電文をHTTPベースで通信します。

つまり、httpsのポイントは、サーバーの認証と通信の暗号化です。


・httpsをまとめると

  1. ブラウザから『https://』のWEBページにアクセスします。
  2. WWWサーバとブラウザの間で双方で使用できる暗号を確認し決定します。
  3. ブラウザは、WWWサーバからの証明書を受け取ります。
  4. ブラウザは、証明書の電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します。
  5. ブラウザは、通信で使用する共通鍵を生成します。
  6. ブラウザは、証明書に含まれていた公開鍵を取得します。
  7. ブラウザは、生成した共通鍵を公開鍵で暗号化しWWWサーバに送信します。
  8. WWWサーバは、暗号化された共通鍵を秘密鍵で復号します。
  9. 以後は、この共通鍵で暗号化された電文をHTTPベースで通信します。

・予めブラウザが持っている公開鍵とは

IE(WINDOWS)では、実は、結構沢山の認証局の公開鍵をレジストリに持っています。メニューバーのツールから確認ができます。ツール内のインターネットオプションから辿ってみてください。

そこに「公開鍵」として、予め持っているわけです。



◆暗号技術の分類

最後に暗号技術の分類を紹介をしときます。


鍵の方式には、共通鍵暗号方式と公開鍵暗号方式があります。

また、両方を使う「共通鍵を公開鍵方式を用いて暗号化する」ハイブリッド方式もあります。


共通鍵暗号方式と公開鍵暗号方式には、各々アルゴリズムを複数もっています。

共通鍵暗号方式アルゴリズムの種類には、ブロック暗号化方式とストリーム暗号方式の2つがあります。

また、ブロック暗号化方式には、ブロック暗号化モードを複数もっています。

ブロック暗号化モードは、ブロック化されることによるブロック単位での「暗号文一致攻撃」を防ぎやすくするモードです。


整理すると、以下のようになっています。



たぶん相互リンク

2010-05-21 暗号リンクメモ

全部は理解できないけど、とりあえず、読みましたよ。

ちゃんと理解するにはメチャクチャ数学力が必要ですね…暗号って…。

2010-05-20 英単語や漢字の意味をクリックなしで調べるには!

Googleで英単語を調べる時は、『英和』とスペースを入れて英単語入力すると、トップに英辞郎やgoo辞書が来て、そこからそれをクリックして意味が求まります。

しかし、沢山の英単語を調べる時には、このクリックが凄く煩わしいのです。


英単語を入れて検索するだけで、クリックなしで、意味が出てくるといいですね。

実は、『辞書』とスペースを入れて英単語入力すると検索画面に沢山意味が出ててくるのです!


あと、『辞書』とスペースを入れて漢字入力すると、こちらも、これだけで意味が出てきますね!

とにかく、検索一発で出てくるので、凄く重宝します。

2010-05-20 公開鍵暗号方式の解説とRSAの解説はイコールじゃないよ!

公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと』という記事をたまたま目にしました。


まず、RSAは公開鍵暗号方式の数あるアルゴリズムの一つです。

で、ネットに氾濫している公開鍵暗号方式の解説が、RSAの解説になっているよ、とのご指摘です。


以下が、勉強になりました。

2010-05-19 WEBでの暗号の基礎知識

◆暗号とは

暗号とは、大辞泉では、『通信の内容が相手以外にわからないように、当事者の間だけで決めた記号』となっています。

通信の内容の元の文章を「平文」といい、これを相手以外にわからないように「暗号文」に変換することを暗号化といいます。

一方、「暗号文」を元の文章に戻すことを復号化といい、暗号化や復号化を行う手順を「アルゴリズム」といいます。

また、当事者の間だけで決めた暗号化に用いるパラメータのことを「鍵」といいます。


整理すると、暗号には、以下の4つの要素があります。

  1. 平文
  2. 暗号文
  3. アルゴリズム

◆シーザー暗号での例

この要素について、過去記事の「シーザー暗号」について当てはめてみると以下の感じです。

(「I LOVE YOU」という言葉を、アルファベット順に5文字後ろの文字に置き換えると「N QTAJ DTZ」になる)

尚、「5文字」の鍵は、暗号化と復号化で一つ(共通)ですが、暗号化は5文字後ろにずらし、復号化は5文字前にずらします。

これは、ドアの鍵が一つで、右に回すとロックされ、左に回すとアンロックされるのと同じ感じです。


◆暗号技術の分類

鍵には、共通鍵暗号方式と公開鍵暗号方式があります。

また、両方を使う「共通鍵を公開鍵方式を用いて暗号化する」方式(ハイブリッド方式)もあります。

これらに関しては『 httpsってわかりますか? - 燈明日記』を参照してください。


共通鍵暗号方式と公開鍵暗号方式には、各々アルゴリズムを複数もっています。

共通鍵暗号方式アルゴリズムの種類には、ブロック暗号化方式とストリーム暗号方式の2つがあります。

また、ブロック暗号化方式には、ブロック暗号化モードを複数もっています。

ブロック暗号化モードは、ブロック化されることによるブロック単位での「暗号文一致攻撃」を防ぎやすくするモードです。


整理すると、以下のようになっています。


◆参考リンク

2010-05-18 httpsってわかりますか?

共通鍵暗号方式と公開鍵暗号方式を説明したあとにhttpsについて説明します。

また、電子署名についても説明します。


◆ 共通鍵暗号方式

たとえば、Aさんは、Bさんへメールをしたいのですが、盗聴が気になるので暗号化して送るとします。

そこで、Aさんは、鍵を使ってメールを暗号化して、Bさんへ送りました。

Bさんは、受け取った暗号化されたメールをAさんと同じ鍵を使って復号化しました。

このように、AさんとBさんが同じ鍵を使って暗号文のやりとりを共通鍵暗号方式と言います。

しかし、決定的な欠点がありますね。そう、AさんとBさんは、予め同じ鍵をもっていないとなりません。

つまり、暗号化して送っても同じ鍵をもっていないと復号化が出来ないのです。

そこで、この欠点を補う公開鍵暗号方式が出てきました。


・共通鍵暗号方式をまとめると

  1. 送信者は、平文を共通鍵で暗号化して送信します。
  2. 受信者は、暗号化された平文を共通鍵で復号化します。

・鍵について

いきなり、『Aさんは、鍵を使ってメールを暗号化して…』と鍵が出てきますが、鍵については以下を参照願います。


◆ 公開鍵暗号方式

共通鍵暗号方式は、暗号化と復号化を同じ鍵(共通鍵)を使いました。

しかし、公開鍵暗号方式は、暗号化と復号化で別の鍵を使用するのです。

そして、暗号化する鍵は、公開してしまうのです!

まず、AさんはBさんの公開鍵でメールを暗号化して送ります。

Bさんは、自分が持っている秘密鍵でこのメールを復号化するのです。

これで、共通鍵暗号方式の欠点を補えました。

しかし、公開鍵暗号方式は、暗号化・復号化に非常に時間がかかる(共通鍵方式の数百〜千倍遅)という欠点があるのです。

そこで、この欠点を補う「共通鍵を公開鍵方式を用いて暗号化する」という方式が出てきました。


・公開鍵暗号方式をまとめると

  1. 送信者は、受信者の公開鍵を取得します。
  2. 送信者は、平文を公開鍵で暗号化して送信します。
  3. 受信者は、暗号化された平文を秘密鍵で復号化します。

◆ 「共通鍵を公開鍵方式を用いて暗号化する」方式

まず、Aさんは、暗号化が速い共通鍵でメールを暗号化します。

つぎに、Aさんは、Bさんの公開鍵で共通鍵を暗号化します。

そして、暗号化された共通鍵とメールを一緒にBさんへ送ります。

一方、Bさんは、暗号化された共通鍵を秘密鍵で復号化します。

つぎに、Bさんは、復号化された共通鍵でメールを復号化します(めでたしめでたし)。

実は、これ、httpsもこの方式なのです!


・「共通鍵を公開鍵方式を用いて暗号化する」方式をまとめると

  1. 送信者は、平文を共通鍵で暗号します。
  2. 送信者は、受信者の公開鍵を取得します。
  3. 送信者は、共通鍵を公開鍵で暗号化します。
  4. 送信者は、暗号化した共通鍵と平文を送信します。
  5. 受信者は、暗号化された共通鍵を秘密鍵で復号化します。
  6. 受信者は、暗号化された平文を共通鍵で復号化します。

◆ httpsとは

始めに、ブラウザから『https://』のWEBページにアクセスすると、WWWサーバとブラウザの間で双方で使用できる暗号を確認し、決定します。

つぎに、ブラウザは、WWWサーバからの証明書を受け取り、証明書内の『認証局』で署名された電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します。(要はWWWサーバが本物かの認証確認)

正当性を確認したら、ブラウザは次ぎに、通信で使用する共通鍵を生成し、先のWWWサーバの証明書に含まれていたサーバの公開鍵(予めブラウザが持っている公開鍵とは別物)で暗号化して、WWWサーバに送信します。

WWWサーバは、それを秘密鍵で復号化して共通鍵を求めます。

以後は、この共通鍵で暗号化された電文をHTTPベースで通信します。

つまり、httpsのポイントは、サーバーの認証と通信の暗号化です。


・httpsをまとめると

  1. ブラウザから『https://』のWEBページにアクセスします。
  2. WWWサーバとブラウザの間で双方で使用できる暗号を確認し決定します。
  3. ブラウザは、WWWサーバからの証明書を受け取ります。
  4. ブラウザは、証明書の電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します。
  5. ブラウザは、通信で使用する共通鍵を生成します。
  6. ブラウザは、証明書に含まれていた公開鍵を取得します。
  7. ブラウザは、生成した共通鍵を公開鍵で暗号化しWWWサーバに送信します。
  8. WWWサーバは、暗号化された共通鍵を秘密鍵で復号化します。
  9. 以後は、この共通鍵で暗号化された電文をHTTPベースで通信します。

・予めブラウザが持っている公開鍵とは

IE(WINDOWS)では、実は、結構沢山の認証局の公開鍵をレジストリに持っています。メニューバーのツールから確認ができます。ツール内のインターネットオプションから辿ってみてください。

そこに「公開鍵」として、予め持っているわけです。


◆ 電子署名について

上記の『電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します』の意味が参考リンクの『暗号化のお話 (3)』で氷解しました。

また、暗号の場合は、秘密鍵で復号化するのに、なんで電子署名の場合は公開鍵で復号化するのかとか…。


電子署名は、同じ内容の平文と秘密鍵での暗号文を送って、送られた方は、公開鍵で暗号文を復号化して、平文と同じになれば、署名が正しとします。

しかし、このままでは、公開鍵暗号方式なので暗号化・復号化に非常に時間かかります。

そこで、ハッシュ(128〜512 bit 程度なので暗号化・復号化に時間がかからない)という機能を使い、平文をハッシュ値にして、それを暗号化し平文と一緒に送ります。

送られた方は、まず、暗号化されたハッシュ値を公開鍵で復号化し、つぎに平文のハッシュ値を求め、両方が一致したら署名が正しいことがわかります。


・留意点

電子署名について公開鍵暗号方式が使えるのは、暗号アルゴリズムがRSAの時だけです。

実際の電子署名でのアルゴリズムは、署名専用のDSAが使われることが多いとのことです。

また、秘密鍵で平文を暗号化しても、誰でも公開鍵で復号化できるので、広い意味で暗号ではないですね。


・電子署名をまとめると

  1. 送信者は、平文をハッシュ値に変換します。
  2. 送信者は、ハッシュ値を秘密鍵で暗号化します。
  3. 送信者は、平文と暗号化されたハッシュ値を送信します。
  4. 受信者は、暗号化されたハッシュ値を公開鍵で復号化します。
  5. 受信者は、平文をハッシュ値に変換します。
  6. 受信者は、両方のハッシュ値が一致したら電子署名が正しいと判断します。

ちなみに、なぜ、同じ内容の平文と暗号文を送って、受け取り側で暗号文を復号化した結果、平文と同じになると電子署名が正しいとするかは、送り側が本人以外誰も知らない秘密鍵で暗号化するからです。

つまり、本人以外誰も知らない秘密鍵で暗号化ができ、それを復号化して平文と内容が一致すれば、確かに本人の署名と言えるわけです。


◆ 参考リンク

2010-05-17 httpsとは?(共通鍵暗号方式と公開鍵暗号方式についてのメモ)

本記事は、以下のリンク先が最新です。



共通鍵暗号方式と公開鍵暗号方式を説明したあとにhttpsについて説明します。

また、電子署名についても説明します。


◆ 共通鍵暗号方式

たとえば、Aさんは、Bさんへメールをしたいのですが、盗聴が気になるので暗号化して送るとします。

そこで、Aさんは、鍵を使ってメールを暗号化して、Bさんへ送りました。

Bさんは、受け取った暗号化されたメールをAさんと同じ鍵を使って復号化しました。

このように、AさんとBさんが同じ鍵を使って暗号文のやりとりを共通鍵暗号方式と言います。

しかし、決定的な欠点がありますね。そう、AさんとBさんは、予め同じ鍵をもっていないとなりません。

つまり、暗号化して送っても同じ鍵をもっていないと復号化が出来ないのです。

そこで、この欠点を補う公開鍵暗号方式が出てきました。


◆ 公開鍵暗号方式

共通鍵暗号方式は、暗号化と復号化を同じ鍵(共通鍵)を使いました。

しかし、公開鍵暗号方式は、暗号化と復号化で別の鍵を使用するのです。

そして、暗号化する鍵は、公開してしまうのです!

まず、AさんはBさんの公開鍵でメールを暗号化して送ります。

Bさんは、自分が持っている秘密鍵でこのメールを復号化するのです。

これで、共通鍵暗号方式の欠点を補えました。

しかし、公開鍵暗号方式は、暗号化・復号化に非常に時間がかかる(共通鍵方式の数百〜千倍遅)という欠点があるのです。

そこで、この欠点を補う「共通鍵を公開鍵方式を用いて暗号化する」という方式が出てきました。


◆ 共通鍵を公開鍵方式を用いて暗号化する方式

まず、Aさんは、暗号化が速い共通鍵でメールを暗号化します。

つぎに、Aさんは、Bさんの公開鍵で共通鍵を暗号化します。

そして、暗号化された共通鍵とメールを一緒にBさんへ送ります。

一方、Bさんは、暗号化された共通鍵を秘密鍵で復号化します。

つぎに、Bさんは、復号化された共通鍵でメールを復号化します(めでたしめでたし)。

実は、これ、httpsもこの方式なのです!


◆ httpsとは

始めに、ブラウザから『https://』のWEBページにアクセスすると、WWWサーバとブラウザの間で双方で使用できる暗号を確認し、決定します。

つぎに、ブラウザは、WWWサーバからの証明書を受け取り、証明書内の『認証局』で署名された電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します。(要はWWWサーバが本物かの確認)

正当性を確認したら、ブラウザは次ぎに、通信で使用する共通鍵を生成し、先のWWWサーバの証明書に含まれていたサーバの公開鍵(予めブラウザが持っている公開鍵とは別物)で暗号化して、WWWサーバに送信します。

WWWサーバは、それを秘密鍵で復号化して共通鍵を求めます。

以後は、この共通鍵で暗号化された電文をHTTPベースで通信します。


◆ 電子署名について

上記の『電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します』の意味が参考リンクの『暗号化のお話 (3)』で氷解しました。

また、暗号の場合は、秘密鍵で復号化するのに、なんで電子署名の場合は公開鍵で復号化するのかとか…。


電子署名は、同じ内容の平文と暗号文を送って、送られた方は、公開鍵で暗号文を復号化して、平文と同じになれば、署名が正しとします。

しかし、このままでは、公開鍵暗号方式なので暗号化・復号化に非常に時間かかります。

そこで、ハッシュ(128〜512 bit 程度なので暗号化・復号化に時間がかからない)という機能を使い、平文をハッシュ値にして、それを暗号化し平文と一緒に送ります。

送られた方は、まず、暗号化されたハッシュ値を公開鍵で復号化し、つぎに平文のハッシュ値を求め、両方が一致したら署名が正しいことがわかります。



◆ 参考リンク

2010-05-16 民主党政権崩壊?

もう限界ですかね。

さて、この危機をどう切り抜けるか…鳩山さんと小沢さん。

個人的には、鳩山さんも小沢さんも好きなのですが……。

2010-05-16 韓国哨戒艦と米国原子力潜水艦との同士討ち!

今日、『北朝鮮艇、韓国側海域に越境 2回目は警告射撃うけ撤収』というニュースがありました。

で、思い出したのですが、今年3月末、航行中の韓国哨戒艦の沈没事故ありました。

当初犯人は、北朝鮮との憶測が流れましたが、その後、この事件は不気味に音なしくなりました。


で、俄然以下の説の信憑性が出てきましたね。


そう、韓国哨戒艦と米国原子力潜水艦との同士討ち!

もしそうなら、北朝鮮へアドバンテージを与えてしまいましたね。


◆追記(5/17)

すみません。昨日書いた記事ですが、やはり犯人は北朝鮮とのニュースが今日(5/17)ありました。

しかし、1ヶ月半も原因判明が遅れたのは、なぜでしょうか……。

2010-05-16 https方式とは?(共通鍵暗号方式と公開鍵暗号方式についてのメモ)

本記事は、以下のリンク先が最新です。



共通鍵暗号方式と公開鍵暗号方式を説明したあとにhttps方式を説明します。


◆ 共通鍵暗号方式

たとえば、Aさんは、Bさんへメールをしたいのですが、盗聴が気になるので暗号化して送るとします。

そこで、Aさんは、鍵を使ってメールを暗号化して、Bさんへ送りました。

Bさんは、受け取った暗号化されたメールをAさんと同じ鍵を使って復号化しました。

このように、AさんとBさんが同じ鍵を使って暗号文のやりとりを共通鍵暗号方式と言います。

しかし、決定的な欠点がありますね。そう、AさんとBさんは、予め同じ鍵をもっていないとなりません。

つまり、暗号化して送っても同じ鍵をもっていないと復号化が出来ないのです。

そこで、この欠点を補う公開鍵暗号方式が出てきました。


◆ 公開鍵暗号方式

共通鍵暗号方式は、暗号化と復号化を同じ鍵(共通鍵)を使いました。

しかし、公開鍵暗号方式は、暗号化と復号化で別の鍵を使用するのです。

そして、暗号化する鍵は、公開してしまうのです!

まず、AさんはBさんの公開鍵でメールを暗号化して送ります。

Bさんは、自分が持っている秘密鍵でこのメールを復号化するのです。

これで、共通鍵暗号方式の欠点を補えました。

しかし、公開鍵暗号方式は、暗号化・復号化に非常に時間がかかる(共通鍵方式の数百〜千倍遅)という欠点があるのです。

そこで、この欠点を補う「共通鍵を公開鍵方式を用いて暗号化する」という方式が出てきました。


◆ 共通鍵を公開鍵方式を用いて暗号化する方式

まず、Aさんは、暗号化が速い共通鍵でメールを暗号化します。

つぎに、Aさんは、Bさんの公開鍵で共通鍵を暗号化します。

そして、暗号化された共通鍵とメールを一緒にBさんへ送ります。

一方、Bさんは、暗号化された共通鍵を秘密鍵で復号化します。

つぎに、Bさんは、復号化された共通鍵でメールを復号化します(めでたしめでたし)。

実は、これ、httpsもこの方式なのです!


◆ https方式

始めに、ブラウザから『https://』のWEBページにアクセスすると、WWWサーバとブラウザの間で双方で使用できる暗号を確認し、決定します。

つぎに、ブラウザは、WWWサーバからの証明書を受け取り、証明書内の『認証局』で署名された電子署名を予めブラウザが持っている公開鍵により解読して正当性を確認します。(要はWWWサーバが本物かの確認)

正当性を確認したら、ブラウザは次ぎに、通信で使用する共通鍵を生成し、先のWWWサーバの証明書に含まれていたサーバの公開鍵(予めブラウザが持っている公開鍵とは別物)で暗号化して、WWWサーバに送信します。

WWWサーバは、それを秘密鍵で復号化して共通鍵を求めます。

以後は、この共通鍵で暗号化された電文をHTTPベースで通信します。


◆ 参考リンク

2010-05-16 シーザー暗号を組んでみる!

先日ご紹介した『暗号化のお話 (1)』にシーザー暗号のことが書かれていました。

普通、暗号化は凄く数学的で難しいものですが、このレベルならまだ私でも理解ができたので、Perlで実装してみました。


◆シーザー暗号とは

古来から伝わる暗号化の方式としてシーザー暗号というのものがあります。

仕組みはとても簡単で、下の表のように文字列をアルファベット順に

数個ずらすだけです。この例では A〜Z を F〜Z・A〜E と、5つずらしています。

ABCDEFGHIJKLMNOPQRSTUVWXYZ
FGHIJKLMNOPQRSTUVWXYZABCDE

例えば「I LOVE YOU」というメッセージをこのシーザー暗号で

暗号化すると「N QTAJ DTZ」という暗号文になります。

暗号文を受信した側は、F〜Z・A〜E を 5つずらして A〜Z

に戻せば「I LOVE YOU」という平文が手に入ります。

http://x68000.q-e-d.net/~68user/net/crypt-1.html
◆実装仕様

仕様としては、アルファベット26文字のみ暗号化します。

暗号化(CaesarCipherEnc)としては、引数に平文とローテート数を指定します。

復号化(CaesarCipherDec)としては、引数に暗号文とローテート数を指定します。


◆サンプルソース(ango.pl)
use strict;
use warnings;

    # 暗号化
    my $ans = CaesarCipherEnc('I LOVE YOU', 5);
    print $ans, "\n";

    # 復号化
    $ans = CaesarCipherDec($ans, 5);
    print $ans, "\n";

sub CaesarCipherEnc {
# 第1引数は平文
# 第2引数はローテート数で0〜26
my ($intext, $rotate) = @_;
my  $wkABC1 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ';
    return '引数エラー!' if (($rotate < 0) or ($rotate > length($wkABC1)/2));

my  $wkABC2 = substr($wkABC1, $rotate, length($wkABC1)/2);
    $_ = $intext;
    eval "tr/$wkABC1/$wkABC2/";
    return $_;
}

sub CaesarCipherDec {
# 第1引数は暗号文
# 第2引数はローテート数で0〜26
my ($intext, $rotate) = @_;
my  $wkABC1 = 'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ';
    return '引数エラー!' if (($rotate < 0) or ($rotate > length($wkABC1)/2));

my  $wkABC2 = substr($wkABC1, length($wkABC1)/2 - $rotate, length($wkABC1)/2);
    $_ = $intext;
    eval "tr/$wkABC1/$wkABC2/";
    return $_;
}

◆サンプルソースの実行結果
C:\Documents and Settings\hoge>perl ango.pl
N QTAJ DTZ
I LOVE YOU

◆サンプルソースのポイント

アルファベットの変換にtr///を使用してます。

tr///は、s///と違って、文字列単位の置換ではなく、1文字単位の変換です。

また、tr///は、普通、変数を指定することはできませんが、evalを使うことにより可能にしています。

これは、"tr/$wkABC1/$wkABC2/"の文字列展開をした後にevalで実行ができるためです。

また、『eval "tr/$wkABC1/$wkABC2/";』で変換されるべき変数は『$_』なので、先に$intextを$_に代入しています。

2010-05-15 花粉症にも効く、ペットボトル鼻づまり解消法!

先日の風邪かと思った季節はずれの花粉症の時、頑強な鼻つまりになりました。

その時、何かのテレビで見た『ペットボトル鼻づまり解消法』を思い出し、試してみました。


頑強な鼻つまりは、左側だったので、右脇にペットボトルを抱えると、あら不思議、鼻が通ったのです!!

ちなみに、右側の鼻つまり時は、左脇にペットボトルを抱えます。


なぜそうなるかは、以下のようです。

そのシステムはというと、ある実験では、体の側面を圧迫するとその反対側の交感神経が刺激されて発汗が促される、というのが分かっているのだとか。

これはその応用で、例えば、右の脇に挟むと左の交感神経が刺激され、鼻甲介の血管が収縮、一時的に鼻づまりが緩和されるのだそうです。

http://karadamemo.jugem.jp/?eid=30

2010-05-14 SQLのinsertで『STRING または BINARY データは切り詰められました。』を出さないようにするには!

SQLのinsertで、データ長を超えたデータを書き込もうとすると以下のメッセージで怒られます。

たとえば、列名がkeyidで、データ型がcharで、長さが8だったとします。

そこに9桁のデータを書き込むと以下のエラーメッセージが出力されます。

INSERT INTO [koike].[dbo].[koike01]([keyid]) VALUES('123456789')

STRING または BINARY データは切り詰められました。

そんな時は、前もってconvert関数で切り詰めるとエラー回避ができます。

INSERT INTO [koike].[dbo].[koike01]([keyid]) VALUES(convert(char(8),'123456789'))

実際は、'123456789'のところは、親言語(たとえばPerlやVBなど)の変数で設定されるのを想定しています。

つまり、親言語で9桁設定されても、エラーにならず8桁がDBに格納される。

これが、良いか悪いかは、とりあえず、今回は別問題としています。


尚、Mirosoft SQL Server 2000とMirosoft SQL Server 2005で確認しています。

2010-05-13 核融合は、実はクリーンなエネルギー?

先日、北朝鮮が「核融合に成功」したとのニュースがありました。

北朝鮮は、すでにウラン型(広島型)とプルトニウム型(長崎型)の原爆を手中に収めていると言われています。

今回、「核融合に成功」したということは、水爆をも手に入れたのですかね…。


ということで、核融合についてググって調べてみました。

すると、意外にも核融合は、クリーンなエネルギーになれる可能性があるのです!

核融合の燃料、重水素(普通の水素の2倍の重さの水素)は海の中に無尽蔵です。初代の核融合炉は三重水素も使いますがこれはリチウムから核融合炉の中で自己生産します。携帯電話の電池でもお馴染みのあのリチウムです。リチウムは、当面はリチウム鉱として十分な量がありますし、海の中には無尽蔵です。だから核融合炉の燃料はすべて海にあるのです。

第一世代の核融合炉は、燃料に放射性物質であるトリチウムを使用するので、核分裂炉からの核廃棄物よりは遥かにましとはいうものの、完全なクリーンエネルギーとまでは言えません。また実験炉であるITERにおいては、低放射化材料の建設許認可に関連するデータがまだ不充分であることから、通常のステンレスが選択されました。したがって、ITERの放射性廃棄物は、通常の原子炉とあまり変わらぬほど出てしまうといわれます。これは事実なのですが、決して核融合炉の不可避な性質なのではないのです。次のデモ炉においては必ず低放射化材をつかうことになります。また、核融合は、その将来においては、燃料を変えていくことで完全に放射能と縁が切れ、真のクリーンエネルギーとなる可能性もあります。

http://www.asahi-net.or.jp/~rt6k-okn/fusion.htm

ということです。

つまり、燃料は、海の中に無尽蔵にあり、かつCO2の排泄は少なく、将来的にはクリーンエネルギーの可能性あるのです!

しかし、クリーンエネルギーになるまでに沢山の放射性廃棄物が出てしまったら本末転倒になってしまいますね。難しい。

2010-05-12 暗号化のお話

今日、たまたま見つけて、読み耽ってしまった『暗号化のお話』です。

私のレベルだとまだまだ難しいけど、凄く面白く読めましたよ!

共通鍵暗号方式と公開鍵暗号方式の仕組みが凄く良く分かります。

(4)が早く読みたいですね。

2010-05-11 今ごろ花粉症だった!

今年は、花粉症にならなくて、治ったのかな…と思っていたのですが。

この土日から熱っぽくて、鼻つまり、ずーっと風邪薬を飲んでも良くならず、試しに去年の花粉症の薬を一錠飲んだら、一発で治った!!


結果的に花粉症だったのですね。


ネットで同じ人が居ないかと検索したら、結構いますね!今ごろ花粉症の人。

ということで、花粉症は治ってなかったみたいorn


追記(5/15):

>今年は、花粉症にならなくて

すみません。ウソ書いていました!

日記を読み返していたら、以下の記事を見つけました。

すっかり、忘れている自分orn

2010-05-11 Excelで「ウインド枠の固定」を設定するには

Excel使いの人なら、なにを当たり前なことと…お思いでしょうが…。

たまに使うと、「ウインドウ枠の固定」が出来なくて苦労するのです。


普通、A列は項目になるので、A列を「ウインドウ枠の固定」にしたいケースが多いと思います。

しかし、A列を選択して、メニューのウインドウ(W)から「ウインドウ枠の固定」を選択してもNGなのです。


これは、固定したい列(今回はA列)を選択するのではなく、固定したい列の一つ右の列を選択するのです!


とにかく、固定したい列や行を選択するのではなく、固定したい列や行の一つ右や下を選択するのです。

そして、メニューのウインドウ(W)から「ウインドウ枠の固定」を選択します。

2010-05-10 一夜にして、はてブ1000獲得!!

前回、5年以上かかった、はてブ1000獲得を、今回、一夜にして、新たに1000を獲得してしまいました。すごい!

勝因は、たぶん、『WEBプログラマー必見!WEB脆弱性基礎知識最速マスター』のタイトルとそれなりのボリュームですかね。


あとは、メインテーマの『WEB脆弱性』対応が、WEBプログラミングで益々重要になってきているのでしょう。


ということで、今後も頑張って行きますね。

皆さま、よろしくお願い致します。


それにしても、タイトルって、重要ですね!

2010-05-09 WEBプログラマー必見!WEB脆弱性基礎知識最速マスター

以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。

WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。

また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。


WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。

そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。


今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。

このまとめがWEBアプリケーション開発の参考になれば幸いです。

尚、本コンテンツを作成するにあたって、以下のリンク先を大変参考にさせて頂きました。

下記のリンク先は、凄く勉強になりました。謹んで御礼申し上げます。



追記:

すでに、はてブで指摘されているように、本コンテンツは、参考リンク先で勉強したノートです。

したがって、本コンテンツより、参考リンク先で勉強することを強くお薦めします。


追記(5/23):

以下の暗号化の基礎知識もあわせてご利用ください。



■ インジェクション
◆ インジェクションとは?

インジェクション(injection)の意味は、内部に何かを注入することです。

そして、WEB脆弱性のインジェクションには、以下の3つがあります。

  1. SQLインジェクション
  2. OSコマンドインジェクション
  3. HTTPヘッダインジェクション

つまり、SQL、OSコマンド、HTTPヘッダの各々に、Webページから悪意のコマンドをインジェクションされることなのです。


◆ SQLインジェクション

たとえば、以下のソースで、$uidと$passhをWebページから入力(POST)される以下のSQLがあったとします。

$query = "SELECT * FROM usr WHERE uid = '$uid' AND pass = '$passh'";

$uidに「taro'--」と入力されたら、以下のように展開されます。

$query = "SELECT * FROM usr WHERE uid = 'taro'--' AND pass = ''";

すると、SQLで「--」はコメントになりますので、パスワードがなくても以下のSQLが発行されてしまうのです。

$query = "SELECT * FROM usr WHERE uid = 'taro'";

これ、Delete文もインジェクションされるケースもあり、私は実際にテストで体験しております。DBがクリアされました!


・対策1

バインド機構を利用します。

バインド機構とは、実際の値がまだ割り当てられていない記号文字(プレースホルダ)を使用して、あらかじめSQL文の雛形を用意し、後に実際の値(バインド値)を割り当ててSQL文を完成させるようにします。


・対策2

対策1のバインド機構が利用できない場合は、入力されるパラメータや、データベースに格納される情報や、SQL文を構成する全ての変数や演算結果に対し、エスケープ処理を行います。

エスケープ処理の対象は、SQL文にとって特別な意味を持つ記号文字(たとえば、「'」→「''」、「\」→「\\」等 )が対象です。

尚、特別な意味を持つ記号文字は、利用しているデータベースエンジンによって異なるので、それぞれに応じて対策を行います。


・対策3

たとえば、データ検索のみのケースでは、削除や更新系のSQLが使えないようにDBの権限設定を行います。


・対策4

あとは、SQLのエラーメッセージをWeb画面に表示しないとか、hiddenパラメータにSQL文をそのまま指定しないとか、があります。


◆ OSコマンド・インジェクション

たとえば、以下のソースで、$fromをWebページから入力(POST)される以下のopen文があったとします。

$from =~ s/"|;|'|<|>|\|| //ig;
open(MAIL, "|/usr/sbin/sendmail -t -i -f $from");

$from に「`touch[0x09]/tmp/foo`」と入力されたら、以下のように展開されます。

$from =~ s/"|;|'|<|>|\|| //ig;
open(MAIL, "|/usr/sbin/sendmail -t -i -f `touch[0x09]/tmp/foo`);

すると、touchコマンドが実行されてしまいます。


・対策1

OSコマンドを起動できる言語機能の利用を避けます。

たとえば、Perlでは、open関数でなくsysopen関数を使用すれば、OSコマンドを起動することができません。


・対策2

対策1が利用できない場合は、引数に埋め込む前にチェックをかけ、本来想定する動作のみが実行されるようします。


◆ HTTPヘッダ・インジェクション

たとえば、以下のソースで、$numをWebページから入力(POST)される以下のHTTPのLocationがあったとします。

$cgi = new CGI;
$num = $cgi->param('num');
print "Location: http://example.jp/index.cgi?num=$num\n\n";

$num に「3%0D%0ASet-Cookie:SID=evil」と入力されたら、以下のようなクッキーが発行されてしまうのです。

Set-Cookie: SID=evil

・対策1

ヘッダの出力を直接行わず、Webアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用します。


・対策2

対策1が利用できない場合は、ヘッダの出力時に想定外の改行を許可しないようにします。

これは、HTTPヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィールドや任意のボディを注入される原因となるからです。



■ クロスサイト・スクリプティング
◆ クロスサイト・スクリプティングとは

普通CGIなどWebアプリケーションは、Webページから検索のキーワード入力や個人情報の登録入力などを処理して、Webページとして出力します。

ここで、Webページへの出力処理に問題があると、そのWebページにスクリプトなどを埋め込まれてしまうことがあります。

このようなスクリプトのインジェクション(注入)を、特にクロスサイト・スクリプティング攻撃と言います。


対策としては、入力されたHTMLテキストを出力する際にエスケープ処理を行い、HTMLテキストを許可しない方法があります。

どうしても、HTMLテキストが必要な場合は、構文解析を行い、「ホワイトリスト方式」で許可する要素のみを抽出します。

また、共通の対策としては、HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行います。


◆ 補足

・エスケープ処理

エスケープ処理には、Webページの表示に影響する特別な記号文字(「<」、「>」、「&」、「"」、「'」など)を、

HTMLエンティティ(「&lt;」、「&gt;」、「&amp;」、「&quot;」、「&#39;」など)に置換します。

また、URLを出力するときは、「http://」や 「https://」で始まるURLのみを許可するようにします。

これは、「javascript:」の形式で始まるURLがあるからです。


以下は、上記の置換をするPerlでのソースです(前に書いた記事の引用です)。

sub htmlf {
    my ($strhtml) = @_;
    $strhtml =~ s/&/&amp;/g;
    $strhtml =~ s/>/&gt;/g;
    $strhtml =~ s/</&lt;/g;
    $strhtml =~ s/"/&quot;/g;
    $strhtml =~ s/'/&#39;/g;
    return $strhtml;
}
http://d.hatena.ne.jp/chaichanPaPa/20080329/1206748795

・ホワイトリスト方式

リストに登録された内容に一致する文字列の通過を「許可」する方式です。

未知の攻撃パターンにも有効であり、漏れが生じにくい点で安全性は高いです。

ちなみに、ブラックリスト方式は、ホワイトリスト方式の逆で、リストに登録された内容に一致する文字列の通過を「禁止」する方式です。

これは、未知の攻撃パターンを検出できない可能性があり、漏れが生じやすいという性質あります。


・HTTPレスポンスヘッダの文字コード指定

HTTPレスポンスヘッダに文字コードを指定していないと、ブラウザは、文字コードを推測して画面表示を処理します。

たとえば、UTF-7に推測された場合、上記のような「エスケープ処理」を施してもエスケープをスルーしてしまうケースがあるとのことでした(参考リンク参照)。



■ セッション・ハイジャック
◆ セッション・ハイジャックとは

HTTPは、ステートレスなので、普通は、ステートを引き継ぐセッション管理ができません。

しかし、ログインが必要なサイトでは、セッション管理がないと実現ができません。

そのために、クッキーが考案され、クッキーにステート(セッションID)を保存することにより、セッション管理を実現します。


しかし、セッション管理がクッキーにより実現できても、その不備を狙うWEB脆弱性があり、それをセッション・ハイジャック攻撃と言います。

セッション・ハイジャック攻撃には、以下の3通りがあります。

  1. セッションIDの推測
  2. セッションIDの盗用
  3. セッションIDの固定化(Session Fixation)

◆ セッションIDの推測

悪意のある人は、セッションIDの生成規則を割り出し、有効なセッションIDを推測します。

これにより、善意の利用者に成りすましすることができるのです。

対策:セッションIDは、生成アルゴリズムに安全な擬似乱数生成系を用いるなどして、予測困難なものにします。


◆ セッションIDの盗用

悪意のある人は、罠を仕掛けたり、ネットワークを盗聴したりし、利用者のセッションIDを盗みます。

これにより、善意の利用者に成りすましすることができるのです。

対策:セッションIDをURLパラメータに格納しないようにしたり、HTTPS通信で利用するCookieにはsecure属性を加えます。


◆ セッションIDの固定化(Session Fixation)

悪意のある人は、以下のような『何らかの方法』で、自分が取得したセッションIDを善意の利用者のセッションIDに送り込みます。

これにより、善意の利用者に成りすましすることができるのです。

対策:ログイン成功後に、新しくセッションを開始するようにします。


・『何らかの方法』の一例

  1. 悪意の利用者が、BBS掲示板等へ「セッションIDを送り込む細工をされたURL」を貼り付けます。
  2. 善意の利用者は、そのURLをクリックし、ログインします。
  3. 悪意の利用者は、送り込んだセッションIDを使って善意の利用者のページを閲覧できるようになります。

・細工されたURLの例

<a href="javascript:document.cookie='PHPSESSID=aaa;expires=Thu, 1-Jan-2011 00:00:00 GMT';location.href='login.php'">click me!</a>

・説明

悪意のある人が、予め用意したセッションID(例ではクッキーのPHPSESSID=aaa)をdocument.cookieで善意の利用者のに送り込み、ログインページに遷移します。

するとその後、悪意の利用者は、そのセッションIDでログインすることにより、善意の利用者に成りすましすることができるようになるのです。



■ アクセス制御や認可制御の欠落
◆ アクセス制御の欠落と対策

アクセス制御の欠落とは、ログインが必要なサイトでは、ログイン情報によりアクセス制御を掛けますが、たとえば、そのログイン情報がメールアドレスだった場合は、他人にも知られ得る情報であり、そのような情報の入力だけでログインできてしまうのは、アクセス制御機能が欠落していると言えます。

アクセス制御の対策は、他人にも知られ得る情報でなく、パスワードなどの入力を必要とするように、Webアプリケーションを設計する必要があります。


◆ 認可制御の欠落と対策

認可制御の欠落とは、上記の「アクセス制御の欠落」をなくして、ログインを実装しても、ログイン者が他のログイン者の情報(データベース)にアクセスできてしまうことがあります。このような実装は、認可制御機能が欠落していると言えます。

認可制御の対策は、ログイン者がアクセスできる情報(データベース)の範囲をつねに考慮するように、Webアプリケーションを設計する必要があります。



■ ディレクトリ・トラバーサル(Directory Traversal)
◆ ディレクトリ・トラバーサルとは?

「../../」のような相対パスを使用し、システム内の任意ファイルへアクセスする攻撃手法をディレクトリ・トラバーサルと言います。

システム内のディレクトリ間を自由に横断(トラバース)できることが攻撃名称の由来で、パス・トラバーサルとも呼ばれます。


対策は、CGIでは、GET(引数)とPOST(hidden)で、ファイル名のみで、ファイルパスを指定しないように設計します。

また、万が一、ファイル名にファイルパスを付加された場合を想定して、そのようなパスを削除するように設計します。


◆ ディレクトリ・トラバーサル対応のサンプルプログラム
#!c:/perl/bin/perl.exe
use strict;
use File::Basename;
use CGI;

my $form = new CGI;
my $file_name = $form->param('file_name');
local $/;

my $dir = 'c:/wk/';                # パス情報をプログラム内で持つ
$file_name = basename($file_name); # パスを指定されてもファイル名だけにする
                                   # openは、パス名とファイル名で連結する
open(my $fh, '<', $dir . $file_name) or die "$file_name, open err ($!)";

my $wk = <$fh>;
print <<"HERE1";
Content-type: text/plain; charset=Shift_JIS;

<html>
<body>
<h1>test</h1>
<p>$wk</p>
</body>
</html>
HERE1

尚、上記は、XSS対応にはなっていませんので、ご注意を!

XSSに関しては、『クロスサイト・スクリプティング』を参照してください。


◆ 補足

『./』は自ディレクトリです。

『../』は、親ディレクトリです。

たとえば、bbbディレクトリにtest.txtがあったとします。

すると、

cat /aaa/bbb/test.txt

cat /aaa/bbb/ccc/ddd/../../test.txt

は、同じになるのです。



■ CSRF(クロスサイト・リクエスト・フォージェリ)
◆ クロスサイト・リクエスト・フォージェリとは?

普通、Webページの入力項目に対して入力をして、書き込みを押すと、その入力データがサーバーに送られます。

たとえば、このWebページで、入力をしないで、悪意のあるページにアクセスしたとします。


すると、それだけで悪意のある入力データがサーバーへ送られる可能性があるのです。

そして、このような攻撃をCSRF(クロスサイト・リクエスト・フォージェリ)と言います。


たとえば、確認のページが、以下のようになっていたとします。

<form action="commit.php" method="post">
<input type="hidden" name="new_name" value="脆弱 太郎">
<input type="hidden" name="new_address" value="大阪府">
<input type="submit" name="back" value="戻る">
<input type="submit" name="commit" value="実行">
</form>

このときに、実行を押さず、以下のような悪意のページにアクセスしたら…。

<form action="http://○○/commit.php" method="post" name="f1">
<input type="hidden" name="new_name" value="いぱくん">
<input type="hidden" name="new_address" value="東京都">
</form>
<script>document.forms['f1'].submit();</script>

アクセスしただけで、submit()が実行されて、脆弱 太郎・大阪府でなく、いぱくん・東京都が書き込みされてしまうのです。


これ、mixi(ミクシィ)のような会員制のサイトでは、自分のIDで悪意の第三者に書き込みがされてしまうのです。

当然、その書き込みが、不正送金、商品購入、退会処理の場合があるわけです!


CSRF対策としては、使用者と開発者では以下があります。


◆ 使用者としてのCSRF対策

とにかく、会員制のサイトにログインしたら、ログアウトするまではサイト以外のページにアクセスしない。


◆ 開発者としてのCSRF対策

更新ページで、秘密情報挿入やRefererチェック等で、なりすましを厳しくチェックします。



たぶん相互リンク

2010-05-08 長男、ラジオ出演!!

長男こと小池啓仁は、4月28日に『かわさきFM』というラジオ局の『羽純☆My Little Blossom』という番組に出演しました!!

第109回目はa pool parのギター&ボーカル、小池啓仁にお越し頂きました〜!

a pool parはが全員がシンガーソングライターで結成されている4人組!

まだ結成して間もないとのことなので、これからの活動がとても楽しみですね

また個々でも活動はしているとのことで、小池さんは毎週吉祥寺でストリートをされているとのこと

今回生演奏で、ギター片手に歌ってくださいましたぁ

素敵でしたよ

http://blog.livedoor.jp/hasumi_blossom/archives/1487806.html

内容は、以下で聞けますよ!

Download


また、パーソナリティの羽純さんと路上ライブも行いました!!

D

2010-05-07 オレンジの謎の花

連休中、買い物や散歩などで、よく見かけた可愛らしいオレンジの花、ママも知らない謎の花…。

ネットで調べたら『ナガミヒナゲシ』と言うらしい…。


画像は、以下のフリー素材です。

2010-05-06 WEB脆弱性シリーズ見直し!

今日は、以下のWEB脆弱性シリーズに対して、誤字や言い回しを見直しました。

2010-05-05 WEB脆弱性のインジェクションとは?

前回の『WEB脆弱性のインジェクションとは?』に『対策』を追記してみました。

-------------------------------------------------------------------

インジェクション(injection)の意味は、内部に何かを注入することです。

そして、WEB脆弱性のインジェクションには、以下の3つがあります。

  1. SQLインジェクション
  2. OSコマンドインジェクション
  3. HTTPヘッダインジェクション

つまり、SQL、OSコマンド、HTTPヘッダの各々に、Webページから悪意のコマンドをインジェクションされることなのです。


◆SQLインジェクション

たとえば、$uidと$passhをWebページから入力(POST)される以下のSQLがあったとします。

$query = "SELECT * FROM usr WHERE uid = '$uid' AND pass = '$passh'";

$uidに「taro'--」と入力されたら、以下のように展開されます。

$query = "SELECT * FROM usr WHERE uid = 'taro'--' AND pass = ''";

すると、SQLで「--」はコメントになりますので、パスワードがなくても以下のSQLが発行されてしまうのです。

$query = "SELECT * FROM usr WHERE uid = 'taro'";

これ、Delete文もインジェクションされるケースもあり、私は実際にテストで体験しております。DBがクリアされました!


・対策1

バインド機構を利用します。

バインド機構とは、実際の値がまだ割り当てられていない記号文字(プレースホルダ)を使用して、あらかじめSQL文の雛形を用意し、後に実際の値(バインド値)を割り当ててSQL文を完成させるようにします。


・対策2

対策1のバインド機構が利用できない場合は、入力されるパラメータや、データベースに格納される情報や、SQL文を構成する全ての変数や演算結果に対し、エスケープ処理を行います。

エスケープ処理の対象は、SQL文にとって特別な意味を持つ記号文字(たとえば、「'」→「''」、「\」→「\\」等 )が対象です。

尚、特別な意味を持つ記号文字は、利用しているデータベースエンジンによって異なるので、それぞれに応じて対策を行います。


・対策3

たとえば、データ検索のみのケースでは、削除や更新系のSQLが使えないようにDBの権限設定を行います。


・対策4

あとは、SQLのエラーメッセージをWeb画面に表示しないとか、hiddenパラメータにSQL文をそのまま指定しないとか、があります。


◆OSコマンド・インジェクション

たとえば、$fromをWebページから入力(POST)される以下のopen文があったとします。

$from =~ s/"|;|'|<|>|\|| //ig;
open(MAIL, "|/usr/sbin/sendmail -t -i -f $from");

$from に「`touch[0x09]/tmp/foo`」と入力されたら、以下のように展開されます。

$from =~ s/"|;|'|<|>|\|| //ig;
open(MAIL, "|/usr/sbin/sendmail -t -i -f `touch[0x09]/tmp/foo`);

すると、touchコマンドが実行されてしまいます。


・対策1

OSコマンドを起動できる言語機能の利用を避けます。

たとえば、Perlでは、open関数でなくsysopen関数を使用すれば、OSコマンドを起動することができません。


・対策2

対策1が利用できない場合は、引数に埋め込む前にチェックをかけ、本来想定する動作のみが実行されるようします。


◆HTTPヘッダ・インジェクション

たとえば、$numをWebページから入力(POST)される以下のHTTPのLocationがあったとします。

$cgi = new CGI;
$num = $cgi->param('num');
print "Location: http://example.jp/index.cgi?num=$num\n\n";

$num に「3%0D%0ASet-Cookie:SID=evil」と入力されたら、以下のようなクッキーが発行されてしまうのです。

Set-Cookie: SID=evil

・対策1

ヘッダの出力を直接行わず、Webアプリケーションの実行環境や言語に用意されているヘッダ出力用APIを使用します。


・対策2

対策1が利用できない場合は、ヘッダの出力時に想定外の改行を許可しないようにします。

これは、HTTPヘッダは改行によって区切られる構造となっているため、これを許すと、任意のヘッダフィールドや任意のボディを注入される原因となるからです。


◆ 参考リンク

2010-05-04 WEB脆弱性のクロスサイト・スクリプティングとは

普通CGIなどWebアプリケーションは、Webページから検索のキーワード入力や個人情報の登録入力などを処理して、Webページとして出力します。

ここで、Webページへの出力処理に問題があると、そのWebページにスクリプトなどを埋め込まれてしまうことがあります。

このようなスクリプトのインジェクション(注入)を、特にクロスサイト・スクリプティング攻撃と言います。


対策としては、HTMLテキストの入力をエスケープ処理し、HTMLテキストを許可しない方法があります。

どうしても、HTMLテキストが必要な場合は、構文解析を行い、「ホワイトリスト方式」で許可する要素のみを抽出します。

また、共通の対策としては、HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行います。


◆ 補足
・エスケープ処理

エスケープ処理には、Webページの表示に影響する特別な記号文字(「<」、「>」、「&」、「"」、「'」など)を、

HTMLエンティティ(「&lt;」、「&gt;」、「&amp;」、「&quot;」、「&#39;」など)に置換します。

また、URLを出力するときは、「http://」や 「https://」で始まるURLのみを許可するようにします。

これは、「javascript:」の形式で始まるURLがあるからです。


以下は、上記の置換をするPerlでのソースです(前に書いた記事の引用です)。

sub htmlf {
    my ($strhtml) = @_;
    $strhtml =~ s/&/&amp;/g;
    $strhtml =~ s/>/&gt;/g;
    $strhtml =~ s/</&lt;/g;
    $strhtml =~ s/"/&quot;/g;
    $strhtml =~ s/'/&#39;/g;
    return $strhtml;
}
http://d.hatena.ne.jp/chaichanPaPa/20080329/1206748795

・ホワイトリスト方式

リストに登録された内容に一致する文字列の通過を「許可」する方式です。

未知の攻撃パターンにも有効であり、漏れが生じにくい点で安全性は高いです。

ちなみに、ブラックリスト方式は、ホワイトリスト方式の逆で、リストに登録された内容に一致する文字列の通過を「禁止」する方式です。

これは、未知の攻撃パターンを検出できない可能性があり、漏れが生じやすいという性質あります。


・HTTPレスポンスヘッダの文字コード指定

HTTPレスポンスヘッダに文字コードを指定していないと、ブラウザは、文字コードを推定して画面表示を処理します。

たとえば、UTF-7に推測された場合、上記のような「エスケープ処理」を施してもエスケープをスルーしてしまうケースがあるとのことでした(参考リンク参照)。


◆ 参考リンク

2010-05-02 ブログ4月分をWebページに変換、そして、「かなめ」と「ようし」とは?

まず、ブログ4月分をWebページに変換しました。


で、最近いろいろありまして……、以下を再引用しときます。

とある書誌(佼成6月号 2009)より引用

何か事が起こると、「さあ大変だ」と言うのが口癖になっている人がいますが、私は逆に難問がくると「これは、おもしろくなってきたぞ」と自分に言い聞かせるのです。そこの紙一重の差が大事だとおもうのです。


さあ大変だと思うと腰が引けてしまいます。反対に、「ようし」と心に決めると、すぐ行動がおこせるのです。行動を起こせば、必ずどこかに道が開けてきます。


「仏教は苦滅の道」であると学んで、「どんな苦も救うことができる教えを見つけた」と、躍り上がらんばかりだった当時の感動です。


その苦滅の道のかなめは、自分に不利なこと、つまり逆縁をも仏さまのご功徳であり、善縁なのだと受け取れるようになることにあります。

大不況の今だからこそ、こころに染みてくるお言葉ですね!

私も、「かなめ」を心に刻んで、「ようし」と心に決めて、頑張ってみます・・・。

http://chaichan.lolipop.jp/src/shikan905.htm#2009-05-26

以下も引用しときます。

努力を続けていないとチャンスはつかめない!?

人間には、一生のうちに何度かチャンスがめぐって来ると言われています。

しかし、そのチャンスは、普段から努力して実力を蓄えていないと通り過ぎてしまうそうです。

つまり、実力を蓄えていないとチャンスが来たことすら気がつかないのです。


人間の脳は、「出来る」と思うと、それを実現するために脳をフル回転させるそうです。

反対に「出来ない」と思うと、脳をフル回転させて、出来ない理由を考えはじめるそうです。


とにかく、自分の夢を「出来る」と思って、脳をフル回転させ努力すれば、きっとチャンスをつかめるのです。

努力を続けいれば、才能などなくても、きっと夢を実現することができるのです。


がんばれ! だれにともなく・・・

http://chaichan.lolipop.jp/src/oyabaka2008.htm#2008-04-10

2010-05-01 WEB脆弱性のセッション・ハイジャックとは

HTTPは、ステートレスなので、普通は、ステートを引き継ぐセッション管理ができません。

しかし、ログインが必要なサイトでは、セッション管理がないと実現ができません。

そのために、クッキーが考案され、クッキーにステート(セッションID)を保存することにより、セッション管理を実現します。


しかし、セッション管理がクッキーにより実現できても、その不備を狙うWEB脆弱性があり、それをセッション・ハイジャック攻撃と言います。

セッション・ハイジャック攻撃には、以下の3通りがあります。

  1. セッションIDの推測
  2. セッションIDの盗用
  3. セッションIDの固定化(Session Fixation)

◆ セッションIDの推測

悪意のある人は、セッションIDの生成規則を割り出し、有効なセッションIDを推測します。

これにより、善意の利用者に成りすましすることができるのです。

対策:セッションIDは、生成アルゴリズムに安全な擬似乱数生成系を用いるなどして、予測困難なものにします。


◆ セッションIDの盗用

悪意のある人は、罠を仕掛けたり、ネットワークを盗聴したりし、利用者のセッションIDを盗みます。

これにより、善意の利用者に成りすましすることができるのです。

対策:セッションIDをURLパラメータに格納しないようにしたり、HTTPS通信で利用するCookieにはsecure属性を加えます。


◆ セッションIDの固定化(Session Fixation)

悪意のある人は、以下のような『何らかの方法』で、自分が取得したセッションIDを善意の利用者のセッションIDに送り込みます。

これにより、善意の利用者に成りすましすることができるのです。

対策:ログイン成功後に、新しくセッションを開始するようにします。


・『何らかの方法』の一例
  1. 悪意の利用者が、BBS掲示板等へ「セッションIDを送り込む細工をされたURL」を貼り付けます。
  2. 善意の利用者は、そのURLをクリックし、ログインします。
  3. 悪意の利用者は、送り込んだセッションIDを使って善意の利用者のページを閲覧できるようになります。

・細工されたURLの例
<a href="javascript:document.cookie='PHPSESSID=aaa;expires=Thu, 1-Jan-2011 00:00:00 GMT';location.href='login.php'">click me!</a>

・説明

悪意のある人が、予め用意したセッションID(例ではクッキーのPHPSESSID=aaa)をdocument.cookieで善意の利用者のに送り込み、ログインページに遷移します。

するとその後、悪意の利用者は、そのセッションIDでログインすることにより、善意の利用者に成りすましすることができるようになるのです。


尚、本記事は、以下URL先を大変参考にさせて頂きました。問題があればコメント欄でご指摘ください。