データベースエンジニアが行く

某レンタルサーバ会社のサーバを使用している。

管理者画面にログインすると移行処理についての説明されている。

OSやミドルウェアをバージョンアップしてくれるらしい。

注意事項として移行後に動作しなくなる可能性がある機能についても記述されている。

深く考えずに移行処理の実行のボタンを押した。



移行に1時間以上かかった。

管理者画面からログアウトして、PCの前を離れたので、正確な時間は分からない。

移行実行行中は管理者画面にログインできなくなった。



サーバ上に置いているシステムを確認したところ、見た目は問題なかったのだが、

Mysqlのデータベースにアクセスできなくなっていた。

当然、phpMyAdminにもログインできない。

調べてみると、次のことが起きていた。

・データベースのパスワードに使用する文字の規則が変わっていた。

・データベースサーバ名が変わっていた。

移行処理の後、サーバの設定を数か所変更しているので、

移行処理が原因と断言することはできない。

パスワードを変更し、変更後のデータベースサーバにアクセスすることで

データベースにアクセスできるようになった。phpMyAdminにもログインできた。

顧客にサービスを提供しているサーバでは、安易に移行処理を実施しない方が良さそう。

オブジェクト
　関連する変数（値）と関数（動作）を一まとまりにして、そのまとまりに名前を付けたもの。

クラス（設計図）とインスタンス（実物）
　オブジェクトの設計図をクラス、それを実体化したものがインスタンス。
　設計図だけでは役にたちません。実体化してから使用します。

プロパティとメソッド
　オブジェクトに含める変数をプロパティ 、関数をメソッドと呼ぶ。

オブジェクト指向プログラミング
　オブジェクトをいくつも使用するプログラミング手法。


上の説明文、今は何とか理解できる。

この文章ではないが、初めて読んだオブジェクト指向についての説明は全く理解できなかった。
10度読んでも、20度読んでもできなかったので、
オブジェクト指向プログラムは自分には合わないものとみなした。

その数年後、クラスをふんだんに使って作成されているシステムを保守する立場になってしまった。
ソースの修正と実行を繰り返すことで、クラスの宣言と実体化を理解できるようになり、
そのシステムを改修できた。

まさに、からだで覚えたと言える。

単語を _ でつなぐ。
　例　$seconds_three_days


2単語目以降の先頭文字を大文字にする。
　例　$secondsThresDays

どちらかに統一した方が良い。
変数の用途をすぐに想像、理解できるような名前をつけること。
英語を使うこと。

脆弱性試験の結果レポートを見ると

リクエストを修正（不正なコードを埋め込み）した内容とそのレスポンスが記載されている。

レスポンスには、あってはならない結果が含まれているのだが、

同時にどうやったらこのようなコードの埋め込みができるのだろうと考えた。

何年も前にそのようなツールをPCにインストールした記憶があるのだが、

そのPCはすでにない。

Webを検索して、Fiddler というツールを見つけた。

同種のツールは他にもあったが、これが一番簡単そうだった。

補足）このようなツールをローカルプロキシーツールと呼ぶらしい。

Fiddler をダウンロード、インストールしてみた。

参考）　https://qiita.com/taketakekaho/items/397bc6e9afa32329edd0

POST送信をブレークして、結果レポートに記載されているとおりに修正して、

再実行すると、レポートと同じ結果が返ってくる。

脆弱性試験を再現できるようになったので、対策を考えるのが容易になった。

前回、脆弱性を受けたのは2019年。2年ぶりに受験。

結果は

大きな被害を受けることが懸念される危険性の高い脆弱性が確認されております。

しかも、その原因は「特殊文字がエスケープされていない」という超基本的な理由。

恥ずかしいこと、この上ない。

エスケープは実施しているのに何でこうなる？。



原因は1か所だった。

入力フォーム中に入力項目以外に、

ページ遷移を管理するための変数を埋め込んでいた。

この変数をエスケープしていなかった。

おかげで、痛烈なメッセージをいただいてしまった。

反省！

だが、よく考えてみるとこの変数はサーバ上のプログラムで生成している。

ユーザ側からこの変数を操作することはできない。

この脆弱性試験、厳しすぎるというか、エスケープしていない項目を機械的にチェックしているだけでは？。