2004/11/14(日)Ruby インストールメモ
2004/11/13 24:00
http://arton.hp.infoseek.co.jp/indexj.html
2004/11/11(木)Cookieあれこれ
2004/11/10 27:00
まずクッキーの仕様から。
HTTPヘッダに以下を書くことによってブラウザにクッキーを食わせる。
Set-cookie: 変数名=値 [; [変数名=値;] [expires=有効期限(GMT);] [path=URLパス;] [domain=サイトドメイン;] secure]
設定したクッキーはドメイン名とペアで記録される。ドメイン名とPathに該当するURLにリクエストを出す際に、ブラウザはHTTPリクエスト中に
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...
を含める。この値は環境変数HTTP_COOKIEにセットされる。従って、expiresの値などはサーバ側から知ることは出来ない（多分）ということだ。
クッキーのセットに関して、デフォルト値と気をつけることをいくつか把握しておく必要がある。
・expires省略時はセッションを閉じるとcookieが消える
・path省略時は設定したページのフォルダ
・domain省略時は設定したページのドメイン
・pathに/を設定すると該当ドメインの全サイトに対してcookieが送られる。認証情報をcookieに入れる際には非常に危険
・secureはhttpsでないと意味がない
さて、cookieを用いて認証情報を管理する場合２通りが考えられる。
1.expires無指定で、パスワード入力から同一セッションでのみ管理者と認定
2.expiresに値を入れて、そのcookieを持つブラウザを管理者と認定する
多くのCGIで実装されている、2を採用したいところ。
んで、どこら辺から穴が開くかを考えると、
A.cookie盗まれる
B.通信路盗まれる
C.サーバデータ盗まれる
D.ブルートフォースアタック
A.は2.特有の問題。
B. C.はどちらでも発生するしcgiで考えることはpermission位。無視。
D.はどちらでも発生するが、フォームでのパスワード入力にブルートフォースをかけるのは難しい。認証失敗ページに飛ばすようにすれば、まず問題ないだろう。となるとこれも2.だけの問題でcookieを偽装生成してブルートフォースをかけるという手段が残る。これは比較的やりやすい。
各論。
A.cookie盗難はもうどうしようもない。これがイヤなら、別の通信方法を考えるか2.の実装を止める必要がある。ユーザが気をつけること、で終了するしかないだろう。
cookieを偽装する場合のD.ブルートフォースに関して言うと、名前と値をペアで生成する必要があるためcookie名が"password"など一般的なものでない限り、そう脆くもない。cookie名は多少ひねっておこう。
passwordを平文でcookieに保存するのがイヤであるなら、MD5値（ハッシュ関数）などを設定するようにする。短いパスワードの危険性が多少軽減されるほか、pathの設定ミスによる同ドメイン他者へのパスワード漏洩の危険が下がる。
最初セッションごとにidを生成し、セッションidをcookieとサーバ上に記憶しておいて照合、ということを考えたが、複数管理者の実装が難しい（サーバのファイルにゴミが残りやすい or 管理者１人のみ）となる。passwordハッシュ値が多分妥当な線だろう。
……さて、怪しい知識でここまで書いてしまったが危なかったら指摘して欲しい。
それにしても私が使っているCGI(KShiki,Nicky)は皆、パスワードを平文のままクッキーにつっこんでいる。……こんなんでいいんだろうか？
P.S.友人からRemotehost情報加えてハッシュにかけてはどうかという提案がありました。この場合、cookieを抜かれても、抜いたユーザのリモートホストまで偽装をしなければいけないので、クラックのハードルはぐんと上がりますのでこちらの方が妥当です。ただ、定期的にproxyを切り替えるユーザやプロバイダ２契約でセッションを切り替えるユーザには使えなくなりますか。最近だと、後者が結構居るという話ですが、実態は不明（Flet'sには２セッションはれるのに、プロバイダが１セッション契約な為）
＜参考URL＞
http://www.yanagisawa.ws/WBL/ASP/session.asp
http://akademeia.info/main/security_lecture.htm
http://www.futomi.com/lecture/cookie/specification.html
2004/11/07(日)Ruby offline mode
2004/11/06 27:00
結論から言ってしまえば、Unix環境等だとCtrl+Dなのだが、Win32環境だとCtrl+Z Enterとする必要がある。
以下、再現する状況。
CGIを作る時にtest.cgi?a=bという風に引数を指定出来る物を作りたいとする。
そうすると、require 'cgi'で、params = CGI.paramsとするのが一般的だが、これを記述するとconsole実行ではofflineモードとなり先に進めなくなる場合がある。
2004/11/06(土)Eclipse3.0.1 日本語化
2004/11/05 24:00
Eclipse展開、Language Pack展開の順で普通に問題ないのだがLanguage Packが少々特殊なZIPファイルのようでアーカイバによっては（NG:春Ｍ OK:詩子さん）解凍に失敗し、出力ファイルが0byteになる。
さらに、正常に展開できた場合でも事前にEclipseを起動してしまっていると中途半端な日本語化になる(ex.ソース -> Source）。これは、configurationフォルダの削除で直すことが可能。
2004/10/26(火)csc日本語環境整備
2004/10/26 16:00
まず、やっぱりというかメインをLANG=Cにして、アプリごとに切り替えるなんてのはだめだった。netscapeはLANG=jaでないと意地でも日本語入力窓が開きやがりません。勿論表示もおかしい。
[fail]
.cshrcの
LANG C
を
LANG ja
に修正して…… 失敗。
しまった、.tcshrcがあればそっちを見るのだった。
[success]
.tcshrcの
LANG C
を
LANG ja
kinput2 &
に修正。
この間、.Xresouces辺りまで含めてあちこち書き換えてしまったほか、~/lib,~/manを消したらemacsがsegmentation faultで立ち上がらなくなったりとか。
emacs問題は、結局LANGが原因の頻出でjaにすると大丈夫でした。なんかユーザ辞書消しちゃって作れなくて怒られてるという話なのかな…… しかしLANG環境が変わるとsfするなんて、やっぱりunixに一般ユーザが乗り換えるの無理なんじゃなーいの！？
2004/10/26(火)tgif format(.obj) -> eps
2004/10/26 16:00
tgifがある環境で、コマンドラインから
$ tgif -print -eps *.obj
で一括変換可能。
しかし、tgifはwindows版無いのな。そろそろcygwin包囲網が狭まっている予感。
2004/10/18(月)WOL断念
2004/10/17 26:00
ここで一応区切りをつけて断念することとする。
さて、進行状況を書いてみよう。
・リモートからの電源断・再起動・休止・スタンバイはどのマシン->どのマシンでも可能
・電源オン・スタンバイ復帰は個体差が大きい
・VersaPro VA80J/VH(Nintz)においては、電源ON・休止状態からの復帰が可能
・自作PC（ikumi）においてはスタンバイからの復帰のみ出来たり出来なかったり。あとは不可
・VAIO(型番忘失）においては復帰・オン全て不可
特にikumi(M/B A7V333)に関しては
LCI-TXI(intel 82558)
GBE-PCI(VIA VT6122)
それぞれについて調査したが、状況は変わらなかった。
さてWOL成功の可否は以下の要素による。
・M/B
・電源
・NIC
・OSおよび電源管理方式
相性問題もあるのだがPCI Rev2.2以降、2.1以前どちらであるかで状況が変わる。Rev 2.2以降のM/B+NICならば、WOLケーブルが必要なく、それ以前のRevであるとWOLケーブルがないとWOL出来ないと思ってよい。少なくともLCI-TXIはここに引っかかっている可能性が高い(WOLコネクタ有り、マニュアルにはRev2.0以降と記載）。
また電源がATX2.01対応（5VSBがある程度の電流を確保していること。諸説あるが0.75A Over?）であること。
さて、ikumi上での大きな問題として、
デバイスマネージャ－LANアダプタのプロパティ
「このデバイスで、コンピュータのスタンバイ状態を解除できるようにする」以下の２チェックを入れると、スタンバイ・休止で再起動してしまう。これは、あらゆるパケットでNICがwakeしている可能性と、何らかの相性問題が悪さしている可能性がある。これのチェックさえ通れば、休止からの復帰は出来そうだ。
LCI-TXI,GBE-PCI 共に発生していることから、M/Bが悪いのかもしれない。M/B・電源・NICでクロステストをするのが原因の切り分けへの最短ルートだろう。まあそんな時間はないので、exit。うへえ。
※その他現象。BIOSでPower ControlのPCIから起動をONにすると電源が切れずに再起動する。ここらへんもM/Bがあやしいと思う理由。
<参考>ネットに落ちているWOL情報は古かったり、微妙なものが多い
http://www001.upp.so-net.ne.jp/hwada/
http://plaza.across.or.jp/~kusunoki/wol_1.htm
2004/10/08(金)リモートデスクトップをするには
2004/10/08 4:00
間違ってもリモートアシスタンスにチェックを入れてはならない。非アカウントユーザに操作を許可する危険なオプションだ。
・繋ぐ際は
アクセサリ→通信→リモートデスクトップ接続
Win2k等でも接続は可能であるが、通信ソフトがインストールされていない。インストールには「XP」のインストールCD-ROMが必要。
・ログインマシンで、ログインしようとして「このシステムのローカルポリシーはこのユーザーが対話的にログオンすることを許可していません」と表示される時、
[ホストマシンの設定]
管理ツール→ローカルセキュリティポリシー
セキュリティの設定→ローカルポリシー→ユーザー権利の割り当て→ターミナルサービスを通したログオンを許可する
に許可するユーザ名を追加
2004/10/05(火)next task
2004/10/05 19:00
sources.list
log監視のポリシーと、セキュリティ情報のキャッチの具合
内容があれなので、対処が終わるまで非公開で。
2004/10/01(金)ブラウザからftpが見られないとき？
2004/10/01 11:00
にチェック。自分でiptablesをできるだけ堅くってやったジャンか……