ブログの更新を一時中断します。次回の更新は、8月上旬を予定しています。
では、また!!!
2023年07月14日
2023年07月13日
sudo [セキュリティ研究室]
こんにちは!
ナビゲータのEVEです。
昨日までは、バッチ処理を管理するためのプログラムの作り方をご紹介し、その中で、OSコマンドを利用するんだけれど、その行為は非常に危険だという話をしています。
本日は、具体的に使うツールと、そのツールを使った場合の問題点について、書きたいと思います。
[sudo]
今回使うツールは、sudoです。sudoは、Linuxユーザなら、一度は利用するツールです。
どんなツールかというと、別のユーザの権限でOSコマンドを実行することができます。
通常、Llinuxサーバーへのsshによるログインは、rootユーザではログインできないようにするのが通常です。但し、root権限でしかできない作業などがあり、その場合は、まず、自分のIDでログインし、その後、sudoコマンドで管理者権限が必要な作業を行います。これにより、rootのパスワードを使い回すような危険な行為をすることなく、管理者権限の作用をすることができます。加えて、複数のユーザが作業する場合では、誰がどんな作業をしたのかと言うことを、ログから確認することが可能になります。
[sudoの危険性]
何でもそうですが、リスクはあります。そのリスクを把握し、適切に理解した上で、利用します。それでは、どんなリスクがあるのか、ChatGPTに聞いてみました。
❶権限の濫用
sudoを使用することで特権ユーザー権限を得ることができるため、悪意のあるユーザーが意図せずに特権を乱用する可能性があります。誤ったコマンドや操作によってシステムが破損する可能性もあります。
❷パスワードの漏洩
sudoを実行するためには通常、ユーザーのパスワードが必要です。悪意のあるプログラムや攻撃者がこのパスワードを取得すれば、システム全体にわたって権限を乱用される可能性があります。
❸設定の不備
sudoの設定が不適切な場合、予期しない特権の付与や不必要な特権の提供などが発生する可能性があります。適切な設定を行わないと、攻撃者が特権ユーザーとして実行できるコマンドの範囲を拡大する可能性があります。
❹コマンドの認証
sudoを使用して特権ユーザーとしてコマンドを実行する際、認証が行われますが、この認証方法にも問題が存在します。パスワードの再入力など、セキュリティ上のリスクがある認証方法を使用している場合、攻撃者がユーザーの特権を取得する可能性があります。
以上です。そして、インターネットを調べてみると、危険だという事例がありましたので、ご紹介します。
NECのサイトで、具体例などを紹介しています。その内容については、サイトで閲覧していただくとして、見ていただくと分かりますが、いろいろなリスクが潜んでいることが分かります。
以上のレポートを否定するわけではないのですが、サーバーサイトプログラムを実行するには、sudoを利用するのが、一番セキュリティが高いと現時点では考えています。
[あとがき]
NECの方のサイトを見ていて気づきましたが、NECでは、実際の攻撃テクニックを学んでいるのですね・・・。情報処理安全確保支援士として私ができることは、既知の攻撃の識別と、その対策についてです。その攻撃が具体的にどんな方法で行われるかまでは、知りません。ことわざに、「彼を知り己を知れば百戦殆からず」というのがありますが、やはり、攻撃事態も勉強したほうがいいのでしょうか?
ただ、これを始めた場合、他のことが全く何もできなくなります。既知の攻撃だけなら勉強するだけで済む可能性がありますが、未知のものを想定した場合、アプリケーションがリリースされるたびに、対応しなくてはなりません。世の中にアプリケーションが1つならいいのですが、その数は無限に等しいのです・・・。
私のスタイルとしては、使用するツールを厳選し、その厳選したツールを正しく使うということに心がけるというぐらいしかできないような気がします。ただ、情報をできるだけ早く入手するということぐらいは、できそうです。
日本ハッカー協会に加入しようかな???現在検討中です。
では、また!!!
■本当は怖いsudoコマンド(NEC)
https://jpn.nec.com/cybersecurity/blog/201023/index.html
■日本ハッカー協会
https://www.hacker.or.jp/
■2023年7月12日現在
修正ファイル本数 21/28(1ファイル修正)
修正関数本数 45/78(14関数修正)
2023年07月12日
サーバーサイトプログラムからOSコマンドを多用してはいけない理由 [セキュリティ研究室]
こんにちは!
ナビゲータのEVEです。
昨日は、バッチ処理のプログラムをどう製造するのかお話ししました。その話の中で、サーバーサイトプログラムからOSコマンドを実行するのは危険だという話をしました。。その理由について、自分として理解はしていますが、不足している点があるかもしれないので、ChatGPTになんで、サーバーサイトからOSコマンドを実行するのは危険なのか聞いてみました。
❶セキュリティリスク
サーバーサイドのプログラム内でOSコマンドを直接実行すると、悪意のあるユーザーが意図しないコマンドを注入し、システムやデータを攻撃する可能性があります。例えば、外部からの入力値が適切に検証やエスケープ処理されていない場合、攻撃者はコマンドインジェクションと呼ばれる手法を使って、任意のコマンドを実行できます。
❷特権の権限拡大
サーバーサイドのプログラム内でOSコマンドを実行する場合、そのプログラムが実行されているユーザーの権限でコマンドが実行されます。もし不適切な権限でプログラムが実行されている場合、攻撃者は特権の昇格を試みることができ、システムの制御を乗っ取る可能性があります。
❸互換性と可搬性の問題
サーバーサイドのプログラム内でOSコマンドを直接使用すると、そのプログラムは特定のオペレーティングシステムに依存してしまいます。異なるオペレーティングシステムを使用する場合、同じコマンドが利用できない可能性があり、プログラムの可搬性や互換性に問題が生じる可能性があります。
❹プログラムの信頼性
サーバーサイドのプログラム内でOSコマンドを実行すると、プログラムの複雑性が増し、バグやエラーが発生する可能性が高くなります。バグが存在する場合、意図しない動作や予期しない結果が発生し、システムの安定性や信頼性に影響を与える可能性があります。
以上です。❶❷については同意しますが、❸❹はどうでしょうか?❹は違うと思いますし、❸については、他のシステムへの移植を考慮しての回答だと思いますが、現在考えていませんし、サーバーサイトプログラム内で、OSコマンドを多用するつもりはないので、気にする必要はないでしょう?
この質問に対して、ChatGPTは、対策についても提示してくれました。見てみましょう。
@セキュアなAPIを使用する
サーバーサイドのプログラムが他のシステムやサービスと対話する必要がある場合、セキュアなAPIやライブラリを使用して、直接OSコマンドを実行する代わりに、API経由で操作を行います。
Aユーザー入力の適切な検証とエスケープ処理
外部からの入力値は適切に検証やエスケープ処理を行い、不正なコマンドやインジェクション攻撃を防ぐ必要があります。
Bサーバーの権限管理
サーバーサイドのプログラムが実行されるユーザーの権限を適切に制限し、最小限の特権でプログラムを実行するようにします。
Aは、今回の事例から外れますが、@とBについては、今まで製造してきたシステムのセキュリティポリシーと合致します。
[あとがき]
ChatGPTが提示してくれた、@Bの方法に対して、実際にどんな対策をするのか、本日は、時間がなくなってしまったので、明日きちんと解説をします。
プログラムを作る場合、いろいろとセキュリティを考えたうえで開発をしなくては、いけません。セキュリティを考慮しないでプログラム製造をして、会社から損害賠償請求をされたという事例が過去にあります。裁判では、損害賠償請求を認め、会社だけでなく、開発担当責任者も損害賠償請求を負いました。
セキュリティエンジニアとしてできるだけ知っている情報は発信していきますので、時々でもいいですから、ブログを読んで、感想などいただければ、うれしいです。
なお、損害賠償に訴えられた事例については、以前、動画、YouTubeで作りました。もし、ご興味がございましたら、ご覧ください。
では、また!
■【情報処理安全確保支援士資格取得のすすめ】[セキュリティ研究室]
https://youtu.be/L_yM6-ojK04
■2023年7月12日現在
修正ファイル本数 21/28(1ファイル修正)
修正関数本数 45/78(14関数修正)
2023年07月11日
Prototype EVEバッチ処理システム [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
本日も、プログラム修正をしたのですが、いつもよりすごく進捗しているって思った人います???甘い!修正プログラムのカウントをミスっていて、修正済みの関数の累積を本日すべて計上しました。
意外と進んでいるので驚いています。ただ、手戻りの手戻り修正が1〜2日ぐらい加算されそうです。
[Linux上でバッチ処理システムを製造する]
今日は、Linux上でバッチ処理を作る方法について解説しましょう。普段からLinuxを使用している人は想像できると思いますが、以下の流れとなります。
@起動したいバッチプログラムをDBに登録する。
A@の情報を、crontab実行形式に編集するプログラムを製造する
BAの編集結果を、crontabで読み込むためのプログラムを製造する
以上です。簡単でしょ?
@では、crontabの実行情報をDBに登録します。Prototype EVEでは、HTML画面から入力しDBへ登録します。めんどくさければ、Insert文で直に登録するでもいいと思います。
Aでは、@DBへ登録した情報を下記のような形式で編集し、ファイルへ出力するプログラムを製造します。
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin:
MAILTO=xxxxxxxxxxx@xxxxxx.com
HOME=/
00 4 * * * bash /var/www/html/vv/EVE0001.sh
Prototype EVEでは、毎日実行するプログラムを、上記のように登録しています。ただ、DBに登録し、必ず毎日crontab実行用のファイルを生成するなら、当日実行すべきプログラムを同ファイルに列記するだけでいいかなって感じています。次期システム、EVEシステムでは、当日実行するプログラムを列記する形式で製造しようと考えています。
Bは、Aで作成した、crontab実行ファイルを、サーバーサイトプログラムから実行します。
#sudo crontab /usr/eveExe.cnt
sudoで実行しているファイルが、Aで編集したファイルのファイル名です。
ここで気をつける点があります。サーバーサイトプログラムから、むやみにOSコマンドを実行させないと言うことです。それについては、本日長くなりましたので、明日書かせていただきます。
[あとがき]
意外と簡単でしょ?強いて難しい点をあげると、crontabをきれいに整形するのが難しかったです。当日実行する各プログラムを、同じ桁位置からきれいに列記されている状態にするのに、一番時間を費やした記憶があります。
まっ、きれいに並んでいないから実行できないというわけではないのですが、見ていて気分がいいのと、障害の時、見やすいと状況判断がしやすいということがあります。時間があるなら、プログラムでcrontab実行ファイルはきれいに整形してください。
これと似たようなシステムを、さくらインターネットで見かけました。多分同じような作りだと思います。使ったことはないのですけれどね(笑)。他に作りようがないもんね・・・。
明日は、LinuxのOSコマンドをプログラムから実行する場合の、セキュリティについて解説します。
では、また!
■2023年7月11日現在
修正ファイル本数 22/28(12ファイル修正)
修正関数本数 38/78(14関数修正)
2023年07月10日
Prototype EVEフレームワーク管理システム [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
現在、Prototype EVEの1日の修正の目標を10件としていますが、時間内に修正するのが難しい状況です。いろいろな方法をためしていますが、力仕事の修正作業なので、これ以上進捗を進めるのは無理かもしれません。
[Prototype EVEフレームワーク管理システム]
フレームワーク管理ステムにログインしたらまず最初に、バッチ処理管理システムを利用したいと考えているのですが、1人で使うことを想定し製造したため、クオリティが高いモノとは言えません。当初は、クオリティを高くするための修正も考えたのですが、Yahooクローニング処理をバッチ登録することのみを目的としているので、そのまま利用しようと考えています。Yahooクローニング処理自体も、次期システム、EVEシステムの位置づけで製造する予定なので、次製造するのは、EVEシステムの管理システムになるんじゃないかなって想像しています。
ようは、Prototype EVEで使えるモノはつかって、Prototype EVEログイン成功後に作るシステムは、すべてEVEシステムとして製造しようと考えているのです。
[EVEシステムとして製造するシステム]
EVEシステムは、以下のように考えています。
@作るシステムは、すべてオブジェクト指向で実現する
A画面表示は、すべてスタイルシートで実現する
BFRAMEをすべて排除する
細かい点を上げたらきりがありませんが、今ブログを書きながらパット浮かんだ、大きな製造の変更点は、以上でしょうか?
[@作るシステムは、すべてオブジェクト指向で実現する]
@は実は、迷っています。オブジェクト指向のプログラムを利用するときって、必ずインスタンスを作るのですが、それって、今までのロジックからすると、複数行長くなるんですよね?ただ、返却値をtrueとfalseに統一するとか、今後のシステムの統一規格を考えると、オブジェクト指向の方がよさそうだし・・・。これについては、もうしばらく検討の余地があります。
[A画面表示は、すべてスタイルシートで実現する]
Prototype EVEを最初に作り始めたときって、確か、HTML3の時でした。そのため、CSSなんてものはなく、実は、Prototype EVEの場合、画面表示の統一性は、サーバーサイトで実装していました。その後、CSSが出てきて、それも取り入れたりして、現在は、統一性の取れていないシステムとなっています。それを、Aで、CSSに統一しようとしています。
[BFRAMEをすべて排除する]
HTML5から、FRAMEタグは禁止になりました。禁止になったからと言って使えないわけではなく、現在も、管理システムで利用しているのですが、セキュリティの面からもあまり良くないのは知っています。ただ、同じような仕様の、IFRAMEタグは推奨利用されているんですよね???なんでだろうということで、ChatGPTに聞いてみました。
HTML5の仕様では、<frame>タグが廃止され、代わりに<iframe>タグが推奨されています。これは、ブラウザのセキュリティとパフォーマンスの向上を目的としています。
<frame>タグは、古いバージョンのHTMLで使用されていましたが、いくつかの問題がありました。主な理由は以下の通りです。
❶セキュリティ
<frame>タグは、外部のウェブページをフレーム内に表示するため、クロスサイトスクリプティング(XSS)攻撃やクリックジャッキングなどのセキュリティ上の脆弱性を引き起こす可能性があります。
❷パフォーマンス
<frame>タグは、ブラウザのページの構造や読み込み方法を複雑にする傾向があります。また、複数のフレームが同じページ内で使用される場合、ユーザーエクスペリエンスが低下する可能性があります。
一方、<iframe>タグは、<iframe>タグと同様に外部コンテンツを表示する機能を持っていますが、いくつかの改善がなされています。
❸セキュリティ
<iframe>タグは、セキュリティ上の脆弱性を低減するための機能を追加しています。例えば、sandbox属性を使用して、表示されるコンテンツの制限やセキュリティポリシーの設定が可能です。
❹パフォーマンス
<iframe>タグは、ブラウザのページ構造に対してより柔軟に組み込むことができます。また、非同期読み込みや遅延読み込みなどの最適化手法も使用できます。
したがって、<frame>タグが廃止され、<iframe>タグが推奨されている理由は、セキュリティとパフォーマンスの向上にあります。新しい仕様に従うことで、より安全で高性能なウェブページを作成することができます。
っだそうです。ChatGPTの回答だと、今まで使用していた、FRAMEタグをIFRAMEに変更し、フレームは、引き続き利用できそうです。
画面を分割して利用するのって便利なんですよね!ただ、何があるのか分からないので、フレームは、管理者または会員向けといった限定された空間のみとしたいと思います。それと、使い方を事前に十分調べたうえで利用したほうがよさそうです。
[あとがき]
次期システムですが、こんな感じで考えています。まっ、ブログを書きながら、1人ブレインストーミング状態で思考しているので、どうなるか分かりませんが、思いついたことを適時このブログで書いていきたいと思います。
では、また!
■2023年7月10日現在
修正ファイル本数 10/28(5ファイル修正)
修正関数本数 24/78(7関数修正)
2023年07月09日
ファーストペンギン [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
昨日あれから、ブログを見直していて、おかしい点が多々あったので、修正しました。修正していて気づいたのですが、暗号化ファイルでパスワードをクライアントで暗号化する以外って、現在標準となっていませんか?当然、今から15年前のセキュリティの教本には、ストレッチングのことも記載されていませんでしたし、SALT値のことも記載されていませんでした。ブログの記述を修正しながら、時代の先をいっていることにちょっと、喜びを感じてしまいました。たいしたコトではないことは分かっているのですけれどね(笑)。昨日、EVEシステム、次期システムではこんな事をしますという紹介をしましたが、実はそれ以外にもセキュリティを追加する予定です。基本的にセキュリティ情報は特許として申請しませんし、公開しません。セキュリティの仕様公開は、セキュリティリスクにつながるからです。ただ、以前、YouTubeを作るときに、セキュリティの特許申請を調べたら、各社予想以上に特許申請しているのには驚きましたが・・・?その特許の中身を見ていないので、何とも言えないのですが、大丈夫なのでしょうか?
[将棋界]
将棋界の藤井君調子がいいですね?まだ、誰も達成していない、8冠を達成しそうな勢いです。
その裏で、プロ棋士に慣れない方も多くいるようです。NHKの番組で「ねほりんぱほりん」という番組があるのですが、その番組で、プロを目指したけれど、結局プロになれなかった人達のその後ということで番組をやっているのを見ました。
将棋をする人って、頭脳明晰で、瞬時に盤面を覚え記憶に留めることができる記憶力、そして論理的思考は一般社会では考えられないレベルの人が多々います。だから、プロになれないからといって、それで人生が終わりというわけではなく、バラ色な人生を送っているのかと思いきや、意外と苦労している事をその番組で知りました。
その番組に出演している2人とも飲食関連に勤めていました。なんで、飲食なんでしょうか?今まで培ってきた、記憶力とか論理的思考が全くいきません。
[企業経営論]
企業経営論という学問がありますが、自分たちの仕事をモノとして定義する場合と、コトと定義する場合で大きく違うという話があります。
例えば、IBMは、昔はハードウェアメーカーでした。そのとき、IBMは自分たちの事業を技術軸(モノ)で考えていたのですが、ハードウェアの事業が行き詰まり、彼らは、ソリューションビジネスへドメイン転換を行います。そのとき、IBMの方々は、自分たちのビジネスを機能軸(コト)としてとらえ、事業転換がうまくいきました。
[あとがき]
プロ棋士になれなかった方々ですが、事業転換がうまくできていないというか、選択が誤っています。自分たちの能力をよく考え、その能力がどんな分野で生きるのか考えるべきです。
私も将棋をやったことがあります。その時の記憶を呼び起こせば、彼らは、システムエンジニアに向いていると思います。もしかしたら、私よりも向いている人もいるかもしれません。
実際に、システムエンジニアを目指した場合、勉強することは多いのですが、今まで培った能力を使うことができ、知識さえみにつければ、かなり優秀なエンジニアになると思います。
今、若い優秀なエンジニアが足りません。成功事例が1人でも出てくれば後に続く人がでてきます。ファーストペンギンになりませんか?
では、また!!!
■2023年7月9日現在
修正ファイル本数 10/28(1ファイル修正)
修正関数本数 24/78(5関数修正)
2023年07月08日
ログインシステム [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
今日も、Prototype EVEの修正作業を実施しましたが、まだまだって感じです。ただ、経験曲線効果のおかげで、少しずつ速度を上げています。予定よりは遅れそうですが、なるべく早く、作業を完了できるように頑張ります。
[ログインシステム]
管理システムのログインシステムを解説する前に、まずは、通常システムと共通の部分について解説をしましょう。
ちょっと、見にくいですが、下記の図には、ログインまでの流れが書かれています。
順を追ってみてみましょう。
❶クライアントがログイン画面にアクセスします。
❷ログイン画面にアクセスしたことにより、サーバーは暗号化ファイル(JSON)をクライアントへ発行します。
❸クライアントは、パスワードを入力します。入力を完了し、ログインボタンを押下したときに、暗号化ファイルに基づきパスワードを暗号化します。
❹暗号化されたパスワードを、データベースの暗号化情報に基づき復号し、復号したパスワードを今度は、MD5によりハッシュ値を取得します。
❺MD5のハッシュ値と、データベースに予め登録してある、パスワードのハッシュ値を比較します。
❻ハッシュ値が等しい場合、セキュリティコードと、❺のハッシュ値を連結し、再度ハッシュ値を求めます。
❼❻で求めたハッシュ値をクライアントに送付しログインが成功です。
❼以降、サーバーは認証コードが正しいことを確認することにより、クライアントの真正性を確認します。
以上が、通常、管理システムで共通のシステムの部分になります。これ以降、管理システムでは、予めエクセルファイルで渡しておいたセキュリティ情報を画面の要求に基づき入力し、ログインします。
めんどくさいといっていたのは、このセキュリティ情報を事前にユーザーに配布しなければいけない点と、何回も、パスワードを入力するのと同様の操作をしなくてはいけないという点です。
このフレームワーク管理システムで使用しているログインシステム、映画ターミネータで使用されていた、システムをパクっています(笑)。
[次期システム]
次期システムでは、以下の変更を考えています。
@最新ハッシュ関数の導入
AセキュリティコードからSALT値への変更
B認証コードの定期的な変更(1時間位?)
@現在最新ののハッシュ値は、SHA3(512)だと思いますが、リリース時には何になっているか分かりません。そのため、最新という記述になっています。
Aセキュリティコードは、Prototype EVEで共通のコードとなっています。そのため、セキュリティコードが漏洩した場合、ユーザー全員のパスワードが脅威にさらされます。そのため、SALT値を導入することにより、ユーザ1人1人をセキュリティリスクから守ります。
Bですが、Prototype EVEの認証コードは、リプレイ攻撃に非常に弱い構造となっています。しかも、以前は、SSL/TLSによる暗号も行われていなかったため、非常に脆弱なものでした。ただ、今回は、SSL/TLSを導入したことにより、多分、このリスクはかなり低減されていると考えています。これは、SSL/TLSの仕様が、ハイブリッド型認証方式となっていることが前提です。このように、セキュリティが環境に左右されるのは当サイトのセキュリティポリシーとしては問題があるので、認証コードを定期的にかえるような仕様にしたいと考えています。
[あとがき]
昔のシステム、Prototype EVE(2006年〜2009年に追加)の仕様について、かなり、深い部分レベルの仕様について公開させていただきました。見ていただいて分かると思いますが、ハイセキュリティなシステムとなっています。そのため、既存のPrototype EVEシステムでも、十分なのですが、これから開発するEVEシステムは、より安心して使えるセキュリティを用意しています。
また、EVEシステムに先立ち、Prototype EVEの公開バージョン、New Prototype EVEでは、@Aの仕様を取り入れた形で公開します。SSL/TLSを導入済みという状況から考えても、現状でも普通のサイトよりはかなりセキュリティが高いですので、そちらも安心してご利用ください。
では、また!
■2023年7月8日現在
修正ファイル本数 10/28(5ファイル修正)
修正関数本数 19/78(8関数修正)
※修正対象関数が2本増えました。
2023年07月07日
今後の開発〜Prototype EVE〜 [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
Prototype EVEのプログラム修正ですが、悩むことがなくなったので、本日は、進捗が多少ありました。ただ、進捗状況を公開していないと、ずるずると伸びてしまいそうなので、関数の本数で、進捗状況を報告することにしました。修正するポイントについては、以下の5点です。
❶記述の統一
❷判定方法の統一
❸引数の入力データチェック
❹セッション開始判定の記述の追加
❺返却値の見直し
以上の修正ポイントを、74本の関数に対して実施します。っで、本日までの修正本数は、11関数・・・。少な!3日間で11関数って・・・。まっ、昨日までどうしようかなって悩んだこともあったのですが、1週間ちょっとで終える予定だったので、遅すぎます。
これから、1週間で以上の関数を対応するとしたら、1日10本以上のプログラム修正が必要です。
[プログラム修正後]
プログラム修正後は、今までいろいろ書いてきましたが、Prototype EVEのフレームワーク管理システムにログインすることが目標になりそうです。
Yahooから日々の情報をダウンロードするという話をしていますが、そのダウンロードするには、バッチ処理を利用します。手動でもバッチ処理を設定することは可能なのですが、手間がかかる上に、本数が増えた場合、管理が大変です。そこで、既存のPrototype EVEシステムのバッチ処理を利用することにしました。
このシステムを利用することにより、バッチ処理の設定が楽になる上に、管理することが楽になります。問題点があるとすると、以前は、バッチ処理が正常に起動しているのか、正常に終了したのか、グラフィカルに画面から確認できたのですが、現在それが動いていません。利用しているシステムが昔と違って少なくなったということもあり、今まで修正してこなかったのですが、それを復活させるのにどのくらいの労力が必要なのか分かりません。
当初は、復活させずに、Yahooのクローニング処理を作る予定ですが、Yahooのクローニング処理を作った後は、対応しなくてはいけないでしょう?
[あとがき]
Protototype EVEのフレームワーク管理システムのログインシステムは以前のものをそのまま利用する予定です。セキュリティレベルを多少上げる予定ですが、多少です。
理由は、ApacheのBasic認証を利用するのと同時に、認証方法が通常よりかなり高いセキュリティレベルのシステムとなっているからです。一般ユーザ向けにそのシステムを利用していないのは、複雑で面倒くさいので、それだとユーザビリティという観点から、利用するのが難しくなると考え、一般ユーザ向けには利用していません。
明日、その管理者向けログインシステムについて解説しましょう。セキュリティに影響がない範囲内ですが・・・。
では、また!!!
■2023年7月7日現在
修正ファイル本数 5/28(3ファイル修正)
修正関数本数 11/78(6関数修正)
2023年07月06日
Prototype EVEの修正見直し作業 [プログラム研究室]
こんにちは!
ナビゲータのEVEです。
ちょっと、いろいろと遅れています。
2023年7月3日のブログの中で、Prototype EVEの手戻り修正があり、その手戻り修正のポイントについて、語っています。
❶記述の統一
❷判定方法の統一
❸引数の入力データチェック
❹セッション開始判定の記述の追加
❺返却値の見直し
以上がプログラム修正のポイントなのですが、❶〜❹は順調に修正できそうだが、❺がどうなっているのか心配だという話をしています。
[プログラム修正の経緯]
修正後の関数を修正前の関数と同様のインターフェースにしようとしていましたが、データベースのインターフェースが変わったことにより、全く同じというわけにはいかなくなってしまいました。そこで、見直すのがめんどくさいと思っていたのですが、いい案がでてきました。
それは、異常時にはすべてfalseで返却するということ・・・。Prototype EVEでは、関数でエラーが発生した場合、falseであったり、エラーステータスであったり、エラーメッセージであったり、仕様がまちまちでした。そのため、修正を困難なものにしていたのですが、今回の修正したプログラムについては、エラー時には、すべてfalseを返却するように修正します。
[ユーザにエラーメッセージを見せないのがトレンド]
これにより、修正後のプログラム分析をする手間が省けるのと同時に、バグの数を減らすことができます。
現在のシステム開発では、エンドユーザーにエラーメッセージを見せないというのがトレンドとなっています。理由は、攻撃者に対して、攻撃のヒントや、攻撃のタイミングを与える原因になるためです。そのため、今回のこの決定は、エンドユーザには全く迷惑をかけません。
困る点があるとしたら、開発の途中で、どこでどんな障害があるのか瞬時に分からないこと・・・・。これは困ったものなのですが、そこは、フレームワークで用意しているデバッカで探すことにします。
[あとがき]
これで、あとはエイヤ〜♪でなんとかなりそうです。じゃ、明日からスピードアップして、修正を行います。
では、また!!!
タグ:プログラム修正
2023年07月05日
福島原発冷却水の海への放出 [Coffee Time]
こんにちは!
ナビゲータのEVEです。
昨日あれから、VMWare Workstationを起動しようとしたのですが、起動しませんでした。
そのため、VMWare Workstationの再々インストール作業を実施しています。
今回は、前回と違い、VMWareとついている、ファイルのすべてを削除しました。Windows配下でアクセス権がついているファイルは削除しないなんて、けちなことはしていません。とりあえず、すべてのファイルを削除しています。
昨日は、再々インストール後、うまく起動することを確認してから寝ています。
っという状況で、本日から、Prototype EVEの手戻り修正をしています。
[汚染水放出]
昨日、福島原発冷却水を海へ放出するというニュースを、かなりの本数見ています。
ニュースの内容は、福島原発を冷却した汚染した水をためるタンクがいっぱいになったから、基準値以下に薄めて海に捨てたいというのです。
捨てるに際し、今までは、ステークフォルダに理解してもらうまで、放出はしないと言っていたけれど、8月には放出するというのです。
この理解という言葉が非常に曲者ですね。納得、了承、承諾ではなく、理解なんです。その作業の内容を理解するという意味で使っていたのかもしれません。だから、我々は嘘は言っていないと・・・。屁理屈も理屈のうちだとはいいますが、政府がそんなことをするなんて・・・。
[福島原発冷却水放出の概要]
実際には、どんなことが行われるのでしょうか?古い情報かもしれませんが、ChatGPTに聞いてみました。
福島原発事故に関連して、使用した冷却水を海に捨てる計画が検討されています。具体的には、汚染物質を取り除いた上で放射能汚染のあるトリチウムを含む冷却水を海洋に放出するという処理方法が提案されています。
ニュースでは、汚染水とひとくくりにしていて、詳細な内容まで踏み込んでいないようですが、2021年までは以上の検討があったようです。
それでは、汚染物質はどのようなモノなのでしょうか?引き続き、ChatGPTに聞いてみました。
❶トリチウム(放射性同位体)
主な放射性物質であり、冷却水中に含まれる場合があります。
❷放射性セシウム
原子炉事故によって発生する放射性物質で、環境中に広がることがあります。
❸放射性ヨウ素
原子炉事故によって発生し、短い寿命であるため、時間の経過とともに減少します。
❹その他の放射性核種
ストロンチウム、プルトニウムなど、原子炉事故によって発生する他の放射性核種も含まれる可能性があります。
❺有機物
冷却水中には、原子炉の運転中に生成された有機物や残留薬品などの化学物質も含まれることがあります。
加えて、それぞれの半減期について聞いてみました。
❶放射性トリチウム ⇒ 12.3年。
❷放射性セシウム-137 ⇒ 約30年。
❸放射性ヨウ素 ⇒ 約8.02日
❹放射性ストロンチウム-90 ⇒ 約28年。
放射性プルトニウム-239 ⇒ 約24,000年。
知っているとは思いますが半減期とは、放射能が半分になる年月です。
[ハーレーの法則]
ハーレーの法則をご存じでしょうか?以下は、ChatGPTから得られた、ハーレーの法則です。
水は蒸発・沈降・降水・流出・浸透・蒸散を経て循環し、地球上に存在し、失われず、持続的に再分配される。
以上の法則から考察できることは、水を分母、放射性物質を分子の比率で求めると、分母の水は不変であるが、分子の放射性物質は、数千年、数万年にわたり増え続けるということです。但し、分子が、分母に対して、無視できるぐらい小さい値ならいいのですが、実際のところはどうなのでしょうか?今回の件、当然、科学者の方々にも相談しているのでしょうから、無視できるぐらい小さいのだと思っています。
[地域住民の反応]
当然、反対しています。理解なんてしてないと・・・。韓国は、了解したみたいです。韓国政権の現在の方向性から考えると、驚く内容ではないでしょう?
中国は、反対しています。
科学的に問題ないとされてはいますが、生理的にはいやだというのは理解できます。それは、一度便所で使ったスリッパを、応接間で使うのはいやだといった感覚と同じなのかもしれません。
[小型原発]
現在、株式の注目テーマに、「小型原子炉」というテーマがあります。どういうものかというと、チェルノブイリも福島原発も大きかったから事故が起こった時問題になったので、小さければ問題ないだろうというものです。
発電量にすると、福島原発を100として考えた場合、25〜35%ぐらいの出力のものをめざしており、現在各国導入に躍起となっています。アメリカは2030年に市場に投入するという話があり、各国も現在追随中だそうです。
ただ、その小型原子炉も核廃棄物は出て、その捨て場はまだ決まっていないという状況は変わっていません。人類発展のためには、懲りてはいけないとはいえ、ちょっと、人類の先行きが心配です。
[あとがき]
いろいろ検討をしましたが、海に排出する以外ないようです。永遠にためるということもできないでしょうし・・・。
ただ、汚染水を基準値以下に薄めるって、ハーレーの法則からいったらあまり意味がないような・・・?海に排出するとき薄めるのは、捨てた瞬間だけの影響を考えてなのだと思います。
宇宙戦艦ヤマトに、コスモクリーナーをイスカンダルへ取りに行ってもらいましょうか(笑)?冗談を言っている場合ではないですね?難しい問題です。
では、また!
2023年07月04日
VMWare Workstaionの調子が悪い??? [ソフトウェア研究室]
こんにちは!
ナビゲータのEVEです。
今日でPrototype EVEのPHP5からPHP8へのプログラムの修正対応が完了しました。ただ、また、VMWareの調子が悪い・・・。すぐにハングアップする・・・。
今回の調子の悪い原因は、プログラム修正作業を終え、バックアップを取ったあと、シャットダウンコマンドを実行しました。そのシャットダウンの途中で、システムが停止してしまったことが、トリガーになっています。
シャットダウンの途中でシステムが停止した場合、何もできないので、普通のパソコンで言ったら、電源を切るという作業を実行しています。
今回もVMWare Workstationを再インストールしようかとも思いましたが、今回は、インストールから日数があまりたっていないので、修復することにしました。Windowsの[プログラムの追加と削除]からVMWareを選択し、その中に、[修復]というメニューがあります。その機能を利用するのです。
[実施結果]
1度目実施後、VMWare Workstationの調子が悪いという状況から、サーバーのスナップショットをとった方がいいと判断し、スナップショットのメニューを選択したところ、またハングアップしています。10分ぐらいでしょうか?放置していましたが状況が改善されないので、強制終了を実行しています。これにより、システムファイルが壊れた可能性があるので、再度修復作業を実施しています。むかつくな・・・。古いパソコンのせいかな?ただ、つい最近まで、問題なく動作していたのに・・・。
[1度目の修復作業の失敗]
1度目の修復作業後正常に起動してこない理由は、起動直後、いろいろなアプリケーションを起動中に、VMWare Workstationを起動したのが悪いかもしれない。っと今は考えています。VMWare Workstation起動中に、タスクマネージャーや、一太郎を起動しようとすると同様にハングアップの状態になったから・・・。ただ、タスクマネージャーや一太郎はその後正常に動作しているのですが・・・・?
[あとがき]
今日は、予定を変更し、VMWare Workstationについて書きました。非常に便利なソフトウェアなのですが、先月ぐらいから使用することに苦労をしています。ハードウェアの問題かな???壊れていないんだけれどな・・・?
2度目の修復作業が完了し、このブログアップロード後、パソコンを再起動します。再起動後、今回は、時間をあけてから起動したいと思います。一度起動してくれば、安定すると思うのですが・・・?どうでしょう???もし、それでも正常に起動してこない場合は、再々インストールを行います。
では、また!!!
★DB関連関数以外の修正状況(7/4までの進捗)
修正ファイル本数 28/28本(1本ファイル修正)
修正箇所 396/396(2箇所修正)
※Prototype EVEのPHP5からPHP8へのバージョンアップ作業は本日で完了です。そして、その報告も本日で最後とさせていただきます。
2023年07月03日
Prototype EVEの修正は、明日完了しそうです [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
明日、Prototype EVEの暫定修正が終わる予定です。
なぜ、暫定か・・・・?修正をして日がたつと、いろいろと気づくことが多く、手戻りって感じでしょうか?
[手戻り修正ポイント]
手戻りの修正のポイントとして上がったのは以下の点です。
❶記述の統一
❷判定方法の統一
❸引数の入力データチェック
❹セッション開始判定の記述の追加
❺返却値の見直し
❶〜❹までは、それほど時間をかけずに、1〜2日で修正できそうなのですが、問題は、❺・・・。途中で気づいたのですが、呼び出し元は関数からの返却値を見て次の挙動を決定します。そのため、返却値が、どんな形式で渡すのかということは非常に重要です。
例えば、false、エラーステータス、またはエラーメッセージなのかっていうことです。修正していてここの統一が取れていない関数が意外と多いのに驚きます。呼び出し元を一つ一つ調べればいいのですが、それをやってしまうと、今まで修正してきた時間と同じぐらいかかってしまいそうなのでやめておきます。できることといえば、従来のPrototype EVEと同じ方法で返却値を設定するということです。
同じ仕様で修正しているつもりだったのですが、ちょっと自信がない・・・。もう一度最初から、返却値を見直します。
[次期システム EVEシステム]
次期システム、EVEシステムはそこの仕様はしっかりしています。オブジェクト指向言語で作るので、基本返却値は、true、falseです。但し、詳細なエラーを見たい場合があります。その場合は、詳細なエラーを格納するグローバル変数を用意しているので、そちらを見るようにしています。
だから、次期は問題ないのですが、問題は現在です。
[あとがき]
明日すべてのプログラムの修正を終えて、明後日から手戻り修正に入りますが、1週間を予定しています。❺の返却値の見直しは、古い修正前のプログラムと比較して、修正したプログラムが問題ないことを確認します。
危惧していた点に、問題なければ、1週間もかからないかもしれませんが、そうでなければ、1週間を超えると思われます。
っという状況です。
その修正完了後は、New Prototype EVEのログイン画面の製造に入ります。
明日は、その話をしましょう!
では、また!
★DB関連関数以外の修正状況(7/3までの進捗)
修正ファイル本数 27/28本(1本ファイル修正)
修正箇所 394/396(6箇所修正)
2023年07月02日
Samba [ソフトウェア研究室]
こんにちは!
ナビゲータのEVEです。
昨日ブログをアップロード後、斎藤秀夫さんのウィッキペディアの情報を見ていたら、私が知らない情報が載っていました。
今まで、斎藤秀夫さん1人で製造していると思っていた秀丸エディタですが、富士通時代の同僚と一緒に作っているそうです。
そして、サイトー企画としての売上が、1996年から1998年のピーク時で、年間1億5,000万円の売上があったそうです。いやらしい話ですが、ウィッキペディア記載の金額を合計しただけでも、7億2,000万円の収入があったようです。ただ、この金額は売上なので、法人税、所得税、住民税を減算すると、サイトー企画所属の2人に入ってきたお金は、3億ちょいって感じでしょうか?
それは、ピークの話であり、それ以外の年も当然収入はあったわけで、それを合計するとサラリーマンの生涯賃金を稼いだから、まっ、いいかって感じなのでしょうか?欲のない方々です(笑)。
[Samba]
なんて、昔を懐かしみながら、今日のブログ何を書こうかなって考えていたのですが、Sambaなんてどうでしょうか?Windowsユーザにはなじみがないソフトウェアなのですが、Linuxユーザとしては、便利に使わせていただきました。
フリーウェアとして提供されているSambaの使用方法は、ファイルサーバーとして利用するケースが多いと思っています。現在はどうか分かりませんが、昔は、Linuxサーバーは古いパソコンを再利用するケースが多々ありました。その使用方法の一つとして、古いパソコンにSambaをインストールしファイルサーバーとして利用していたのです。使い方は、Windowsのファイルサーバーと同じです。特定のディレクトリ、ディスクを共有設定すれば、ネットワーク上で検索し、「ネットワークドライブの割り当て」として設定すれば、ファイルサーバーとして利用することが可能です。
現在、Sambaをウィッキペディアで調べてみると、ドメインコントローラーとして利用できたようです。Active Directoryとして利用できるのでしょうか?Active DirectoryをLinux上に構築するためには、LDAPなどを利用すると考えていたのですが、ちょっと、驚きです。
Sambaを導入するだけで、ネットワーク上の資源管理ができるとなれば、リソース管理がかなり楽になります。
[現在は?]
Active Directoryの話を知っていれば、引き続きSambaを利用していたと思いますが、現在は、Sambaの代わりに、SSHサーバーをWinSCPで利用しています。
WinSCPは、ポート番号22番、プロトコルSSHを利用し、セキュアなデータ通信を実現します。公開鍵暗号方式、ホスト認証方式、パスワード認証方式と複数の認証方式を提供していますが、WinSCPは、公開鍵暗号方式を採用しています。ただ、以前、この公開鍵暗号方式について、いろいろな疑問をブログで書いていますが、最高にセキュリティが高いというものではありません。通信は暗号化しているのですが、PKIの技術が導入されていないので、機密性が完全に保証されないのです。
まっ、自宅で使うならあまり関係ないのですが、Xserverのように外部にホストがあれば話は別です。
[あとがき]
30年弱前から使用している、秀丸というエディタから、懐かしいつながりで、Sambaについて本日紹介しました。
Active Directoryが利用できて、運用負荷がWindows Serverと変わらないなら、簡単に導入できるSambaは会社などの組織においてかなり費用を下げることができそうです。
私は調べるつもりはないのですが、誰か調べて報告してくれたら、うれしいです。
では、また!!!
■秀まるおのホームページ
https://hide.maruo.co.jp/software/hidemaru.html
■斉藤秀夫(ウィッキペディア)
https://ja.wikipedia.org/wiki/%E6%96%89%E8%97%A4%E7%A7%80%E5%A4%AB#:~:text=%E6%96%89%E8%97%A4%E7%A7%80%E5%A4%AB%EF%BC%88%E3%81%95%E3%81%84%E3%81%A8%E3%81%86%E3%81%B2%E3%81%A7%E3%81%8A%E3%80%811967,%E4%BC%9A%E7%A4%BE%E3%82%B5%E3%82%A4%E3%83%88%E3%83%BC%E4%BC%81%E7%94%BB%E3%81%AE%E4%BB%A3%E8%A1%A8%E3%80%82
★DB関連関数以外の修正状況(7/2までの進捗)
修正ファイル本数 26/28本(1本ファイル修正)
修正箇所 388/396(5箇所修正)
2023年07月01日
開発環境〜秀丸エディタ〜 [システム開発研究室]
こんにちは!
ナビゲータのEVEです。
Prototype EVEの環境を、PHP5からPHP8へバージョンアップするために、日々少しずつではありますが、プログラミングを進めています。その作業も、やっと、終了が見えてきました。あと、3ファイル、13項目の修正でバージョンアップは完了します。
[バージョンアップの状況]
はじめてこのブログを見てくれる人もいると思うので、最初から説明しましょう。
当初PHP8のシステム、EVEシステムを造ろうとも考えたのですが、初めから作るのは時間がかかりそうだと言うことで、まずは、Prototype EVEのバージョンアップをすることにしました。このシステムをバージョンアップすることによって、システム開発で普段から利用しているデバックシステムを利用することができます。なんか、すごく仰々しく話していますが、実行したいプログラムにデバックポイントを挿入し、プログラムを実行することにより、実行プログラムの途中経過を見るといった簡単なものです。
Eclipseとか、Visual Studioでもファンクションキーを押下しながら、プログラムの実行状況をビジュアル的に見る機能がありますが、Prototype EVEでは、秀丸で開発しているため、自前でそのような機能を実装しています。
[なんで秀丸で開発?]
若い人は知らないと思いますが、Eclipseは当初IBMで開発をしていました。それを、version3だったと記憶していますが、Eclipse Foundationに移管しています。そのときの状況がひどかった・・・。バージョンアップを保証してくれなかったので、Eclipse Version3以前で製造したプログラムは、自分たちでバージョンアップをしなくては、引き続きEclipseは利用できなかったのです。そのときの状況を知っているものとしては、開発環境も含めて、できるとこは自分で作ると言うことをコンセプトに開発を進めてきました。そのため、デバックシステムは、Prototype EVEに実装し、プログラミングは秀丸で製造という形式を取っています。
[優秀な秀丸エディタ]
秀丸を知らない人もいると思うので、秀丸について御紹介しましょう。
秀丸は、元富士通エンジニアの斉藤秀夫さんが製造しているエディタです。サイトー企画から提供されているソフトウェアで、私は、使い始めてから、はや30年たとうとしています。
そのソフトウェアは、一貫とした操作性、便利な機能、軽いソフトウェアと私が求める機能をすべて実装しています。
しかも、現在は、英語版も登場し、海外の人も利用できる状況です。
ライセンスについては、フリーで利用することも可能ですが、一応シェアウェアです。私がお支払いしたときは、4,000円でしたが現在はどうなのでしょう?今ホームページで確認しましたが、400円高くなっていました。ただ、この400円、税金だそうです。30年前と変わらず、4,000という価格・・・。頭がさがります。
そして、一度購入したライセンスは、生涯利用できるそうです。バージョンアップしたから新たにライセンスを支払ってなんてケチなことを言いません。
多分ですが、サイトー企画という会社組織ではありますが、その会社は、税金等の関係で作っただけで、秀丸などのシステムは、1人で作っているのでは?っと思っています。だから、一度支払ったらライセンス料を求めていないという販売の仕方をしているのだと想像しています。
全世界には、数十億の人がいて、その人口は日々増えている状況です。その増えている人たちの数パーセントでも、秀丸を知り、利用し、ライセンスを支払ってくれれば採算があうのかもしれません。
[あとがき]
本日は、秀丸エディタについてご紹介しました。
斉藤秀夫さんは、実は、秀丸エディタだけでなく、以下のような製品も製造し販売しています。
・秀丸ファイラー
・秀丸メール
・パスワード総合管理
・秀Caps
・秀見え
・Twinset
・Plane Checker
・Ctrlキーを2回
・Ini2Reg
・イメぐる修理
・KeepCaretBlink
・パスワード総合管理
・パスワード総合管理(ストアアプリ版)
・秀丸ネットモニター
・秀丸ランサムガード
・秀Term Evolution
・秀Termリーダー
・サイトー企画セキュリティライブラリ
・秀インストール
・マクロサーバ
・正規表現/あいまい検索DLL
・横取り丸
・InetSpy
加えて、各ソフトのライブラリなども提供しています。
私は、秀丸以外では、秀Termを利用させていただきました。まだインターネットがなかったとき、PC-VAN、ニフティが最盛期の時代で、電話回線でホストコンピュータに接続しサービスを利用するときに利用していました。それも、インターネットを利用するようになってから、使用しなくなりましたが・・・。
懐かしい話です・・・。ただ、すごい量のソフトウェアです。実は提供しているソフトウェアが、こんなにたくさんあることを初めて知りました。
パスワード統合管理なんて使ってみたいなって思いました。あなたは、どうですか?
では、また!!!
■秀まるおのホームページ
https://hide.maruo.co.jp/software/hidemaru.html
■斉藤秀夫(ウィッキペディア)
https://ja.wikipedia.org/wiki/%E6%96%89%E8%97%A4%E7%A7%80%E5%A4%AB#:~:text=%E6%96%89%E8%97%A4%E7%A7%80%E5%A4%AB%EF%BC%88%E3%81%95%E3%81%84%E3%81%A8%E3%81%86%E3%81%B2%E3%81%A7%E3%81%8A%E3%80%811967,%E4%BC%9A%E7%A4%BE%E3%82%B5%E3%82%A4%E3%83%88%E3%83%BC%E4%BC%81%E7%94%BB%E3%81%AE%E4%BB%A3%E8%A1%A8%E3%80%82
★DB関連関数以外の修正状況(7/1までの進捗)
修正ファイル本数 25/28本(0本ファイル修正)
修正箇所 383/396(3箇所修正)