【パスワード管理システム】 に関して （【パスワードfile 自動更新】 による セキュリティ維持）
[ メニュー ]
１． “田中式 半自動の手順書ダウンロード” の、 パスワード管理システムの 概略
２． ＨＰで 隠しＣＧＩを使う人は 注意が必要。
３． 「破られない パスワードは 無い」 〜 と言われるが・・・。
４． 【パスワードの自動更新／初期化】 は、 なぜ 必要か？。
５． データfile／パスワードfile の 【パーミッション】 は、 ６０６ で良いのか？。
１． パスワード管理システムの 概略
◆【パスワード登録リスト】 は、 ２つのＣＧＩが連携して 管理・自動処理 しています。
１つ目は パスワードマネージャ本体。
２つ目は 隠しＣＧＩ。
その時の状況によって、 初期化／更新されたり 追記／更新されたりします。
（初期化／更新 ＝ 【上書きモード】。 追記／更新 ＝ 【追記モード】。）
【Ａ】．隠しＣＧＩは、 パスワードfileが ２５分以上 古かった時は、 常に 自動的に初期化／更新します。
【Ｂ】．パスワードマネージャ本体が パスワードfileを更新する時、
処理前のパスワードfile更新時刻が ２５分前より新しかった時は 追記／更新します。
（同じ時間帯に 複数の人が パスワード登録する可能性もある）
◇上記 Ａ、Ｂ の連携によって、 平均値として ３５分程度で パスワードfileが更新され、常に 新しい状態を維持します。
（ほとんどの場合、 初期化／更新です。）
【パスワードfile 自動更新】 と セキュリティが どう関連しているのか？ ・・・って？。
それについては、 最後の方で触れます。
さて、 あなたにパスワードを発行する時 と 自動更新する時の、【年月日時分】を記録しています。
そして、
いくつかのページで、“隠しＣＧＩ”が起動するように仕組んであり、
この 隠しＣＧＩが 上記の【年月日時分 記録ファイル】をチェックしています。 （１日に 約９００回）
※【年月日時分 記録ファイル】の記録形式
2003年 8月10日 2時30分 ⇒ ⇒ 10308100150 という形式で記録します。
（2003年 → 103。 8月10日 → 0810。 2時30分 → 2×60＋30・・0150・・４桁）
隠しＣＧＩが起動した時、“現在の年月日時分”を ↑同様のデータ形式に変換し、
記録ファイルと比較し、
現在の“年月日時分”の数値が ２６（分）以上 大きかった場合に、【パスワード登録リスト】 を勝手に初期化させています。
初期化〜とは、 乱数発生させて 文字列を生成し、１組のパスワード・ＩＤとして 上書きで記録します。
そして、自動初期化する場合は、 最初に 【最終パスワード更新（発行）の年月日時分 記録ファイル】を記録し直します。
23時59分の場合、 下４ケタ部分は 1439 として記録されます。 2003年12月10日なら、10312101439です。
翌日の 12月11日 00時00分では 10312110000 となりますから、下５ケタ部分は 01439 → 10000 に 一気に増えます。
つまり、たった１秒の違いで、 現在の【年月日時分】の数値が ２６（分）以上 大きい・・と認識されます。
こうすることで、日付の変化が “劇的に”数値に反映されます。
２． 自分のＨＰで 隠しＣＧＩを使う人は 注意が必要。
◆ボタンを押す形式にしても、“表示→ソース”で ＣＧＩの所在を知られますから、
連打されたり、巨大ＢＢＳにＣＧＩへのリンクを貼られた場合に、サーバーの負荷が高くなります。
ですから、
ＣＧＩの先頭部分で、【ＩＰ重複チェック】と【特定リンク先】を排除しておく必要があります。
【HTTP_REFERER をブラウザが返さない 不明なアクセス】 や、 ＩＰ重複／特定リンクを検知した場合や
直アクセス・お気に入りアクセスでは 何もさせずに終了させるようにし、
隠しＣＧＩのファイルサイズを１０ＫＢ程度にしておけば、起動回数がいくら多くても どうって事ありません。
◆また、 ファイルアクセスのロッキング （共有排他制御） も工夫する必要があります。
今回の 【隠しＣＧＩ】は ３０分ごとにパスワードを自動初期化する事が目的ですから、 ロッキング処理が不完全ですと事件です。
◆書き込み頻度が高い〜とか、 重要なファイルに対して ロック処理を行う場合は、 ファイルアクセスを ２段階にすれば良いでしょう。
（本体の記録ファイルに ダイレクトにアクセスさせない）
つまり、 早い者勝ちの１つのプロセスだけが、 【手付金】 を払ってから 本体の記録ファイルを更新する形にします。
【記録ファイルに対するロック】 を 単純に信用せず、
１バイトの小さなファイルで、 【記録ファイルに対して更新中です】〜という意味を持たせてから 本体の記録ファイルを更新するのです。
そして、 全てのプロセスは、 この内容を確認 ↑ してから 更新処理に入ります。
【更新中です】のフラッグが立っていたら、 待つようにします。
（“フラッグfile” の書き込みに失敗した可能性もあるので、 古い【更新中フラッグfile】は無視し、作成しなおす。）
◇この “フラッグfile” にも 書き込みロックをかけます。
タイミング的に 【更新中ではない】〜と認識したプロセスだけが、 【更新中です】のフラッグを 最初に立ててから、
本体の記録ファイルの更新処理にかかります。
更新処理が済んだら 【更新中ではない】〜という意味のフラッグに変更し、 “フラッグfile” の書き込みロックを解除します。
この “フラッグfile” は１バイトしかありませんから、
単純に symlink関数でロックをするだけでも、 書き込みミス や 読み込みミスの確率は うんと低くなるでしょう。
もちろん 本体の記録ファイルの更新処理にも ロック処理をしますから、
仮に 【ロック処理のミスの確率】 が10000分の１だとすれば、
２段階ですから、 第１段階で ロック処理ミスが発生しても もう一つのロック処理が待ち受けています （１億分の１）。
◆私の場合、 パスワードfileは “３０分に１回の自動更新”ですから、 そこまでする必要はありませんが、更新対象が重要なファイルです。
隠しＣＧＩに直リンクを貼られた時、 パスワードfileに頻繁なアクセスが発生すると 破損しないとも限りません。
（考え方は同じ。）
その意味で、 【年月日時分 記録ファイル】の記録時刻 と 現在時刻を比較チェックする動作は 【防波堤】 の役割も果たします。
１つのプロセスが 【年月日時分 記録ファイル】 を更新してしまえば、 他のプロセスは ２５分分間は パスワードfileに全くアクセスしません。
では、 猛烈なアクセスで 【年月日時分 記録ファイル】 が破損したら、 どうしましょうか？。
大丈夫。 【年月日時分 記録ファイル】 は 自動修復されます。
また、 【年月日時分 記録ファイル】 が破損して チェックが素通りする事があっても、
そのあと、 パスワードfileの更新日時をチェックしています。
いわば ２段構えの検査なのですが、
パスワードfileに触れる “頻度” を低くする意味で、
【パスワードfile更新】 が決定した時だけ、 “念のため” という意味で パスワードfileの更新日時をチェックします。
特定のファイルへのアクセスが短時間に集中すれば、 そのファイルが破損する確率も高くなりますから。
※【年月日時分 記録ファイル】 が更新されるのは ２６分（以上）に１回であり、 それ以外のアクセスは “読み込み” だけです。
◆停電・落雷による サーバーダウンは別にして、
symlink関数／mkdir関数／flock関数に依存した ロック処理でない限り、 事実上 記録ファイル破損の可能性はゼロに近いでしょう。
なぜでしょうか？
それは、 【プロセス番号のテンポラリーファイル生成】 の説明を よく読めばわかります。
symlink関数／mkdir関数／flock関数だけに依存したロック処理であれば、
同じファイルに対して 複数のプロセスが同時にアクセスした時、 【時間的な隙間】 で ロック処理失敗〜データファイルが狂う可能性があります。
※つまり 複数の人がＣＧＩに同時にアクセスした時、 読み込み動作 と 書き込み動作が競合する。
あるいは、 書き込み動作 と 書き込み動作が競合する。
しかし 私は、
【“記録更新の内容”が後の動作に影響する 重要な記録ファイル】 は、 symlink関数／mkdir関数／flock関数に依存していません。
プロセス番号のテンポラリーファイルは、 他のプロセスは読み書き しません。
このファイル↑に対して上書きし、最後に リネーム処理する動作では、 更新前のファイルが破損していても、関係ないのです。
（それまでの記録ファイルは 破棄される。）
また、 ファイル破損が原因で記録ファイルを読めなかった場合、 読み取り前に与えた初期値によって 常に “終了する流れ” となりますが、
１日のうち 特定時刻の前後は 通常のファイルアクセスを休止させ、 【自動修復〜終了】 の時間として割り当てています。
停電・落雷によって 記録ファイル／パスワードファイルが破損しても、 ２６分 （最長でも１日） で自動的に復旧します。
◆ＣＧＩ の用途によっては、 【ＩＰ重複検査／reffer検査】 も 少し工夫する必要がありますが、
これについては、 ２ｃｈ連中に 手の内を見せる事になりますので 書きません。
４． 「破られない パスワードは 無い」 〜 と言われるが・・・。
かつて 私のＨＰの掲示板が 激しく荒らされた当時、安直なレンタルＢＢＳでしたし、見張っている訳にもいかず、
【投稿パスワード】をかけました。
６ケタの英数字パスワードでしたが、いつのまにか、管理パスワードが破られ、掲示板は消滅していました。
ケタ数を不特定にして ２組のパスワードにすれば、各々が１０ケタ程度でも 破られる心配は激減します。
８ビットの最大認識数値＝２５６ですが、
１６ビットの最大認識数値＝６５５３６ であり、２５６×２ ではありません。
２進数８ビット・・２の８乗
８ケタの英数字・・３６の８乗・・・78364164096 × 36
２０ケタの英数字・・３６の２０乗・・・78364164096 × 78364164096 × 2176782336 ← コンピュータ用語の“爆発”。
↑
これを１０ケタ前後の２組のパスワードにしますと、さらに複雑になります。
◇【アルファベット ａ 〜 ｚ】 が２６通り ＋ 【０〜９】 ・・・ ３６通り ・・・ ３６の２０乗 と書きましたが、 違いました。
大文字と小文字の区別がありますから、６２の２０乗ですね。 もっと数値は大きくなります。
３６の４乗 ＝ 1679616。 ６２の４乗 ＝ 14776336。
これだけでも ほぼ１０倍の数値です。
２０乗＝４乗×４乗×４乗×４乗×４乗 ですから、
たぶん、 ６２の２０乗 ＝ 78364164096 × 78364164096 × 2176782336 × 約 100000 でしょう。
あなたに発行されたパスワードは８ケタであり、 ＩＤは他人は知りませんから、これもパスワードの機能を果たしますが、
初期化／自動更新させる場合のパスワード・ＩＤ は、ケタ数を２０ケタより多くしてあります（笑）。
このケタ数で ３０分ごとに自動更新させているのですから、絶対に破られません。
荒らし目的で、 １秒に１回 【メクラ打ち】で、 パスワード自動入力のパターンを繰り返したと仮定しましょう。
１日＝24時間＝60分×24＝60秒×60×24 ＝ 86400秒 です。
78364164096 × 78364164096 × 2176782336 × 100000 を 86400 で割り算すると、
( 906993 × 78364164096 × 2176782336 × 100000 ) 日 です。
365で割り算して、
パスワード解明に必要な 【所要年数】 は、 【2485 × 78364164096 × 2176782336 × 100000】 年 です。
パスワードを自動更新するペースは３０分ですから、↑ これを３０分で処理しないと破れません。（笑）
５． 【パスワードの自動更新／初期化】 は、 なぜ 必要か？。
現在のセキュリティシステムが完成しかけた頃のことです。
自宅サーバーを運営する知人に、 『荒らし人間になったつもりでテストして下さい』 〜 と頼みました。
回答は、 次のような内容でした。
「ダウンロード中に ○◇△ で通信を監視すると、 サーバーとブラウザ間での通信が バレバレになります。
ファイルをダウンロードできる限り、 ＵＲＬアドレスが露呈する 可能性が高いでしょう。
・・・・・ （以下 省略。）」
回答文を読んで ガッカリし、 思いました。 ↓
それじゃ、 一般的な 【パスワードＣＧＩスクリプト】 を使っている人は、 保護したつもりでも 実は 【気休め】か・・。
私の返事 ↓
「それじゃ、何をやっても駄目じゃないですか〜。
〜〜〜〜
仮に暗号化できても、 ダウンロードする人が それと“対”になるデコード方法を
知っている必要があるのではないでしょうか？。
それに、 ブラウザ自身は暗号化されたＵＲＬを解読する機能は持っていませんから、
間に介在させるツールの側で工夫すれば ＵＲＬは露呈するでしょ。」
回答 ↓
「そうなんです。 最終的にHTTPを使わない方法を考えないと駄目かもしれないです。
こういう場合、 完璧にするのは難しいです。
〜〜〜〜
このツールはいたずらの為に作られたものではありません。
ネットワークの管理やセキュリティーホールの発見などで 役立っているはずです。
ツール操作の難易度は わりと難しい部類に入るでしょう。」
◇最初の回答文が指す 【ＵＲＬアドレス】 とは、
ＣＧＩのアドレスではなく、 パスワードで保護した ＬＺＨモジュール のＵＲＬアドレスです。
ＣＧＩの方は、 仮に ＵＲＬが露呈しても ＣＧＩ自身が “ガード機能” を持っているので問題は無いのです。
しかし、 普通のページや画像とか ガード機能を持たないＣＧＩ では駄目なのです。
パスワード保護をしようが何をしようが、
サーバーとブラウザの間で 【ＵＲＬアドレス】 のデータ授受があれば、 アドレスが露呈する・・という事になります。
（ツールを使えば）
不特定の人間に パスワードを発行するシステムでは、
ブラウザに ＵＲＬを表示されないように工夫しても、 外部から 直接ダウンロードされてしまいます。
その後 頭を捻って考え、 現在のように 【パスワード自動更新】 の仕組みにしました。
完成後、 もう一度 テストを依頼しました。
回答 ↓
「なるほど、面白い方法ですね。 こんな方法もあったのかと、びっくりです。 これなら 完全です。
コロコロと 【パスワード】 が変化するので、 ツールを使って ＵＲＬを把握しても無意味ですし、
荒らし２cherも目を白黒させるでしょう。」
とのことでした。
◇【参 考】 ： ↑ この人は、 かつて ２ｃｈ連中による 【荒らし被害】 を受けた事があります。
「最近 2cherによる被害はすごいですね。 実は一回やられた事があります。
ＨＰを潰されちゃって・・・クッソーという経験があります。」
６． データfile／パスワードfile の 【パーミッション】 は、 ６０６ で良いのか？。
◆多くの場合、
フリーウェアでも シェアウェア販売でも、 データfileのパーミッションを 【６０６】 に設定される事が多いようです。
（あるいは ６６６）
『ファイル名が外部に知られなければ大丈夫』 〜 という考え方でしょうが、 不安ですね・・。
だったら、 Perlスクリプトの記述を変更すれば良いのです。
※実に簡単です。 Perlスクリプトの知識がほんの少ししか無い人でも出来ます。
こんな簡単なこと、 なぜ ネットで教えないかな〜？？。
こんな簡単なこと、 スクリプトを提供する側は なぜ、 最初から そのように設定しないかな〜？？。
横着してるとは思えないし、
それとも、 【chmod関数】を実行できないサーバー ってあるのかな？。（そんな ！！）
UNIXサーバーなら、chmod関数（命令）を実行できないという事は無いと思いますよ。
（もし 実行できないサーバーがあったら御免なさい。）
読み書きする直前に 【６０６】 にし、
読み書きが終ったら 【４０４】 に設定されるように、 少しだけ 記述を追加（変更）するだけです。
もうひとつ、 データfileの拡張子を、 .dat とか .txt とか .log に設定される事が多いようですが、
.cgi に変更してしまいましょう。
【拡張子が .cgi のデータfile】 だからと言って、 読み書き出来ない〜なんて事ありません。（関係ない。）
特に、 パスワードfile の場合は、 拡張子dat や 拡張子txt は危険です。 （何のためのパスワード？）
【拡張子 .cgi 、 パーミッション ＝ ４０４】 のデータfile／パスワードfileは非常に安全です。
パスワードfile に限らず、
こうしておけば、
仮に その所在を知られ、ファイル名を知られても、 外部から ダウンロードも閲覧も出来ません。
（Perlスクリプトの中で読み書きするだけ。）
もちろん、削除や書き換えられる事もありませんし、 パーミッション＝４０４ですから、実行も不可能です。
※ cgi は実行ファイルとしての拡張子。 【実行権】 を設定してないと、 外部から呼んでも サーバーが拒否する。
“ダウンロードツール”で ダウンロードしようとしても サーバーが拒否する。
通常 【.htaccess】 の パスワードfile は 【.htpasswd】ですが、 これも 【htpasswd.cgi】 で大丈夫です。
※以下、 htpasswd.cgi と書いた時は CGIプログラムではなく、 .htpasswd のファイル名を変更した物を指します。
そして、
htpasswd.cgi 自体を 【.htaccess】 の配下に置いておけば、
htpasswd.cgi に対する 不正なアクセスが連続した場合でも “.htaccessによるパスワード入力” を要求されます。
◇この時、 htpasswd.cgi が自動的に初期化される形にしてあれば、 どんな不正なアクセスでも防衛できます。
つまり、不正アクセスする側からすれば、
仮に 外部でＣＧＩを作成して htpasswd.cgi に直アクセスしたとしても、
htpasswd.cgi にアクセスするためには “.htaccessによるパスワード入力” の要求に答える必要があります。
でも、 パスワードは自動的に初期化／変更されていますから、
ダウンロードツールで自動応答するように設定しても、 答えるべきパスワードが 不明な状態です。
◇【.htaccessファイル／htpasswd.cgi （.htpasswd） を外部から閲覧させないための記述】 を
.htaccessファイルの中に 入れておきましょう。
そうすれば、 外部から .htaccessファイルを閲覧しようとしても サーバーが拒否してくれます。
（具体的には、 【Filesコマンド】 を使います。）
.htaccessファイルの中には .htpasswd （htpasswd.cgi） の存在するパスが記述されていますから、
最低でも、 .htaccessファイルを 外部から閲覧させない事が重要です。
（私のサイトの inner_Pageフォルダのように パスワードを公開する場合は別。）
※.htaccess について勉強できるサイト → http://www.mikeneko.ne.jp/~lab/ http://www5.big.or.jp/~m_kono/
【.htaccessで設定できる命令】 → http://www5.big.or.jp/~m_kono/cgi/htaccess.html http://www.mikeneko.ne.jp/~lab/web/htaccess/
（Limitコマンドの説明がサイトによって大幅に違う場合もあるので、 注意。）
◇【基本的な知識の確認】
.htpasswd を htpasswd.cgi に変更する場合は、
〜〜.cgi （.pl） の初期設定部分で、 “ファイル名の指定記述” を変更し、
.htaccess の中に記述されている “ファイル名の指定記述” も変更します。
転送する時は、
最初に htpasswd.cgi （パスワードfile） を転送し、 次に 〜〜.cgi （.pl） と .htaccess を転送します。
動作を確認した後、 不要となった .htpasswd を削除します。
htpasswd.cgi （.htpasswd） の配置場所は、 【.htaccess保護 の配下のフォルダ】 がベストです。
【.htaccess のパーミッション】 は 404・444（次善は604・644） にする事は御存知でしょう。
【.htpasswd（htpasswd.cgi） の置かれたディレクトリのパーミッション】 は、 基本的に 755 (705) でＯＫ。
（.htpasswd（htpasswd.cgi） 自体を保護属性にしてあれば 無理に厳しくする必要も無い。）
ただし、
〜〜.cgi 等によって .htpasswd（htpasswd.cgi） を更新させる場合は、
【.htpasswd（htpasswd.cgi） の置かれたディレクトリのパーミッション】 は ７０７に設定する。
※【.htpasswd（htpasswd.cgi） の置かれたディレクトリのパーミッション】 を例えば 704 に設定すると、
.htaccess で保護されたファイルに対して ブラウザでの 【パスワード入力】 も不可能となる。
【.htaccess の置かれたディレクトリのパーミッション】 は、755 (705) でＯＫ。
※【ディレクトリのパーミッション】については、
実行権は “そのディレクトリに移動する権限” という意味です。
◆では、 先ほどの ６０６・・・４０４ の方法です。 これは .htpasswd（htpasswd.cgi） に対しても通用します。
（Perl の知識が無い人でも大丈夫）
データfileを読み書きする 〜〜.cgi のファイルで、 先頭の 【初期設定】 の すぐ後ろあたりに、 下記の４行を追加します。
（１行目と２行目の順番を変更したりしないでネ。）
※chmod命令を実行不可能なUNIXサーバーも存在するかも。 （書き換え前の CGI を保存してネ）
$writeMODE = '0606';
$perWrMODEset = oct($writeMODE);
$guard404MODE = '0404';
$perGuardMODEset = oct($guard404MODE);
◇説明 ：
0606 は 【呼び出し＋書込み】モードの パーミッション。
0404 は 【呼び出しだけ】モードの パーミッション。
※どちらも、８進数であり、ＦＴＰツールで表示される値です。
共有サーバーでは、 606 や 404 を設定できず、666 や 444 の設定しかできないサーバーもあります。
その場合は、 上記の $writeMODE の右辺 0606 を 0666 に変更し、 $guard404MODE の右辺 0404 を 0444 に変更。
※行末のセミコロン 【;】 を忘れずに。
文字・記号は 全て 半角英数字で。 【'】と【"】は意味が違います。 行の途中の空白は 半角の空白。
大文字・小文字は区別されます （A とa は区別される）。
他に追加する記述は ほんの少しですが、 注意事項があります。
以下の注意事項を読むのが面倒な人は、 後述するように、 パーミッション設定を 【数字で直接 記述】 しましょう。
そうすれば、 話は 非常に単純になります。
$writeMODE 、$perWrMODEset 、$guard404MODE 、$perGuardMODEset の ４つの変数名は、
編集対象の ＣＧＩスクリプトの 他の部分の 【変数名】 や 【サブルーチン名】 と 名前が重複しないようにして下さい。
（サブルーチン は、 sub サブルーチン名 という記述で始まる。 ⇒ 例 ／ sub LinkCHK ）
同じ意味で、
該当の ＣＧＩスクリプトの中に、 require □□□ という記述があったら、 その □□□ファイルの中も確認します。
（□□□ファイル中の記述と比べて 名前が重複しないように・・。）
ただし、 例外として、
□□□ファイルの拡張子が pl （ピーエル） であり、 なおかつ その □□□.pl の先頭行が package □□□; となっている場合
（例えば、 tanaka.plファイルの先頭行が package tanaka; となっている場合）は、
【その □□□.pl の中に記述された変数名・サブルーチン名】 は、 その □□□.pl 以外のスクリプトとの 【名前の重複】 は無視できます。
説明がややこしいですが、
大文字・小文字を混ぜて、 「やや長過ぎるかな？」 〜 と感じるような名前にすれば 大丈夫でしょう。
もっと単純明解な方法もありますが、 後述。
（日本語の苦手な人へ ・・【なおかつ】 という言葉は、 and という意味。）
変数名には、 “ハイフン”や “マイナス” を使わず、 使いたいなら、 代わりに アンダーバー （ _ ） を使います。
半角ハイフンは 引き算の “マイナス” として認識されます。
local関数／ my関数によって定義された変数も、 今回の 【名前 重複】 の心配は無用ですが、 ここでは言及しません。
詳しくは、 【ライブラリのパッケージ化】 と、 サブルーチン や 変数の 【名前空間】 を読んで下さい。
※スクリプト同士の 【名前 重複】 を検査するには、 エクスプローラの検索機能 か エディタの検索機能で・・。
※$〜〜 = oct($〜〜); の oct と 後で登場する chmod を変更しては ダメですよ。
oct と chmod は、 名前ではなく “命令そのもの” を意味する単語です。 （予約語といいます。）
$〜〜 の 【$】 の文字は、 削除したり 他の文字に変更してはいけません。
$ と 名前の間に “空白”を入れてはいけません。
$ で始まる文字列は 変数名として認識されます。
Perlの文法上の 【予約語】 を、 変数名として命名してはいけません。
（私の知る他の言語 BASIC／Pascal／FORTRAN でも同じ。）
変数名を変更する人は、 $Myguard のように、 $ の次の１文字目を“大文字”にすれば、 その心配がありません。
（Perlの予約語は、 先頭は小文字。）
write は予約語ですが、 write と writeMODE は “別の名前” として認識されます。
１つの名前の中に “半角の空白” を含めることは出来ません。
行の途中にある “カッコ” を うっかり削除したりしないように。
あなたのスクリプトを 文字列検索で チェックして、
【上記の追加４行と これから追加する記述】 と、 あなたのスクリプトとで、 お互いに 【名前】 が重複する事があるならば、
上記追加４行の ４つの変数名の 名前を変更して下さい。
このＣＧＩが requireで呼ぶ “他のＣＧＩ・他のＰＬ” も、 チェックして 同様に。
（わからない人は、 同じフォルダにある全てのＣＧＩ・ＰＬファイル内で、 上の４つの変数名と 名前が重複しないようにすれば良い）
※名前を変更する場合は、 下記に記述する変数名も 同様に変更して下さい。
次に 〜〜.cgi のファイルの中で、 データfileに読み書きしている部分を捜します。
多くの場合、 次のようなブロックになっているでしょう。
ロック処理を開始
〜〜〜〜
データfile読み込み
〜〜〜〜
読み込んだデータについて、利用するか 加工するなどの処理
〜〜〜〜
データfile書き込み
〜〜〜〜
ロック処理を解除
↑ 上の “処理の流れ” をいじる必要はありません。
データfileの パス/ファイル名を格納された “変数名” が 仮に $datafile であったとすれば、
【データfile読み込み】の直前か 【データfile書き込み】の直前に、
chmod $perWrMODEset, "$datafile";
の １行を追加します。
そして、
【データfile読み込み】の直後か 【データfile書き込み】の直後に、
chmod $perGuardMODEset, "$datafile";
の １行を追加します。
◇たった これだけです。
要するに、
データfileを処理する直前に 【呼び出し＋書込み】モードの パーミッションに設定し、
データfileを処理した直後に 【呼び出しだけ】モードの パーミッションに設定するだけです。
即ち 上で登場したブロックは、次のようになります。
（コメント行の先頭の # は、便宜上 削除。）
ロック処理を開始
〜〜〜〜
chmod $perWrMODEset, "$datafile";
$datafileの読み込み
〜〜〜〜
読み込んだデータについて、利用するか 加工するなどの処理
〜〜〜〜
$datafileの書き込み
chmod $perGuardMODEset, "$datafile";
〜〜〜〜
ロック処理を解除
◇読み込み と 書き込みの間の “読み書き以外の処理部分” が長い場合は、
【呼び出し＋書込み】モードに設定されている時間が長いので、
最大限 安全にするには、
最初の 読み込みの直後に 【呼び出しだけ】モードに設定し、
次の 書き込みの直前に 再び 【呼び出し＋書込み】モードに設定すれば良いでしょう。
※読み込みしか行わない処理の前には 【呼び出しだけ】モードだけで充分ですが。
このようにしても、
私が行っている手法よりも、 【呼び出し＋書込み】モードに設定されている時間は 長いでしょうが、
大々的に攻撃されるサイトでなければ充分でしょう。
◇chmod の命令行は、 ロック処理の “開始〜解除” の内側に記述しましょう。
◇データfile読み込み と データfile書き込み とが、
それぞれ独立した形で “ロック処理の 開始〜解除”で囲まれている場合もあるでしょうが、
やはり同様に、 chmod の命令行は、 ロック処理の “開始〜解除” の内側に記述しましょう。
●ひとつ、 注意事項があります。 ↓
▲“特定のデータfileに対する 読み書き処理” が １つのＣＧＩの中だけでなく、
▲そのＣＧＩから呼ばれて 変数を共有する “別のＣＧＩ”でも 同一のデータfileにアクセスしたり、
▲【〜〜.plファイル】 も 同一のデータfileにアクセスしている場合です。
（文字列検索すれば判明する。）
特に plファイルの場合は、
【サブルーチンだけで構成された 〜〜.plファイル】 の場合や、
plファイル先頭の package宣言の有無で、 上記の変数名の使い方について 微妙に話が変わります。
詳しくは、 【ライブラリのパッケージ化】 と、 サブルーチン や 変数の 【名前空間】 を読んで下さい。
ですから、 上記の 【▲３行】に該当する方は、 chmod を実行する行を 変数で指定せず、 単純化しましょう。
（Perlを会得している人は 除外して。）
つまり、
chmod 0666, "$datafile";
という風に、
0666 とか 0404 の値を 直接 数字で指定して chmod を実行すれば良いでしょう。
（ただし、 0666 を 0606 に変更する時や サーバー変更する時は、 chmod実行の 数字の部分を 全て 記述を書き換える。）
そのように 直接 数字で指定する場合は、 最初の 【変数設定 の４行】 も不要です。
つまり、
上記の 【▲３行】に該当する方は、 ↓ 最初に追加するハズだった下の４行は 不要。 （パーミッションを 直接 数字で指定するから。）
$writeMODE = '0606';
$perWrMODEset = oct($writeMODE);
$guard404MODE = '0404';
$perGuardMODEset = oct($guard404MODE);
上記の 【▲３行】に該当する方は、 データfileに対する読み書き処理 の部分は 次のようになります。
※【666 や 444 の設定しかできないサーバー】では、 ＦＴＰ転送した後、 606 や 404 の設定を拒否されます。
その人は、 下記の 0606 を 0666 に、下記の 0404 を 0444 に変更しましょう。
ロック処理を開始
〜〜〜〜
chmod 0606, "$datafile";
$datafileの読み込み
〜〜〜〜
読み込んだデータについて、利用するか 加工するなどの処理
〜〜〜〜
$datafileの書き込み
chmod 0404, "$datafile";
〜〜〜〜
ロック処理を解除
◇さて、 以上の作業を完了したら、 ＣＧＩをアップロードします。
自分で書き込みテストを行い、 その後 パーミッションが４０４ （４４４） に設定されていれば ＯＫです。
404（444） に設定されている・・という事は、 外部からの 書き換え・削除は不可能です。
さらに、 データfileや パスワードfileの拡張子が cgi なら、 外部からの 閲覧もダウンロードも不可能です。
|
