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

今回も詳しい事情は省くが

3度目の脆弱性試験を受けることになった。

2度目の受験結果がボロボロだったので、

脆弱性試験用の動作テストを実施してから、試験に臨んだ。

ノーミスでクリアするはずだったが、一点指摘された。



初耳の用語。

他のWebページから iframeで呼び出されることを

許可するかどうか設定できるそう。

.htaccessに



を追加した。

httpd.confに記入しても良いということだが、

Apacheを再起動しなくてはならないので .htaccess を選んだ。

3度目の脆弱性試験はあっさりと終了し、システムは運用を開始した。



ブログに書いたように、脆弱性試験を受験して多くの知識を得ることができた。

これらを知らないまま、今後もシステム開発を行っていたと思うとゾッとする。


関係者の皆様

多くの指摘を受けてしまい、ご心配をおかけしましたが

たいへん勉強になりました。

受験の機会を与えていただき、ありがとうございました。



脆弱性試験�@ -試験前-
脆弱性試験�A -実施中-
脆弱性試験�B -結果-
脆弱性試験�C -続編-

細かい経緯は省略するが別のシステムで再度、脆弱性試験を受けることになった。

２度目なので余裕で構えていたら、大きな見落としと不具合が重なり、

"運用開始不可"

と判定されてしまった。

初回と同様に指摘事項を列挙する。

1.認証が必要なページに認証を通さずにアクセスできる。
　デバッグモードを解除していなかったためなのだが、ログイン後に行う処理が
　ログインしなくても行える状態になっていた。これが"運用開始不可"を導いた。

2.ロックアウト機能がないので、何度でもログインを試みることができる。
　ロックアウト機能は実装していたのだが、バグがあり動作しなかった。

3.エスケープ処理を行っていない。プレースホルダーもhtmlspecialcharsも使用していない。
　初回試験のときと同じミス。エスケープ処理が頭から抜けていた。

4.テキストファイル、EXE形式ファイルをアップロードできる。
　アップロードするファイルの中身をチェックする方法があるとは知らなかった。
　参照　https://fanblogs.jp/to70/archive/503/0

5.セッションCookieにHttpOnly属性が設定されていない。
　恥ずかしながらHttp Only属性が何なのか知らなかった。
　JavaScriptからCookieを参照や操作できなくするための設定らしい。
　.htaccess に php_flag session.cookie_httponly On を追加した。

運用開始不可となり、関係者に迷惑をかけたのだが

修正は割と簡単だった。

1,2,3は修正方法を理解していたし、5は.htaccessの修正だけ。

4は対応方法を調べることから始めたので時間がかかったが、

1から5までを併せて半日で修正を終えることができた。

そして、何とか運用を開始できる運びとなった。



脆弱性試験�@ -試験前-
脆弱性試験�A -実施中-
脆弱性試験�B -結果-

脆弱性試験の結果が返ってきた。

何と、パスしてしまった。

問題箇所はあるもののリスクレベルが低く、

現時点では軽微な影響に留まるということで

システムを運用開始できる運びとなりました。

自分でもびっくり。



1.ロックアウト機能がないので、何度でもログインを試みることができる。

2.ログイン画面のFormで、autocomplete="off" が指定されていない。

3.エスケープ処理を行っていない。プレースホルダーもhtmlspecialcharsも使用していない。

4.入力ルールに反するデータを登録できる。

5.パスワードポリシーに問題がある。


1はロックアウト機能を追加すれば解決できるし、2と3は簡単に修正できる。

4と5は時間がかかったが対応した。




データ登録画面ではエラーチェックを行っている。

メールアドレスを@なしで登録しようとするとエラーメッセージが表示される。

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

@なしで登録できている。

なぜだろう？

どうやら、ローカルプロキシツールを使用してPOST値を書き変えたようだ。

ブラウザのデバッグツールで試してみると、同じ現象を再現できた。

　登録画面 → 確認画面 → 登録完了画面

と遷移するが、エラーチェックは登録画面と確認画面の間で行い、

確認画面と登録完了画面の間では行っていない。

確認画面の値をデバッグツールで書き変えると、入力ルールを満たさない値を登録できた。

そこで、確認画面と登録完了画面の間でもエラーチェックを行うようにシステムを修正した。




脆弱性試験を行う人が操作し易いようにと思い、

ログインパスワードをアルファベット１文字にしてあげたところ、

パスワードポリシーに問題ありと認定された。


アルファベット、数字、記号の各１文字を含むこと。
アルファベットは大文字と小文字を区別すること。
これらのルールを満たすようにシステムを修正せよとのこと。


パスワードはDB内のテーブルに保存しているので、システムを修正する必要はなく、

指摘されたルールを満たすパスワードに変更した。

しかし、なぜか顧客からはシステムの修正を要求され、

パスワードを変更するだけで済むことを説明するのに骨が折れた！


脆弱性試験�@ -試験前-
脆弱性試験�A -実施中-

脆弱性試験を任されたのは中堅SIer。（以後、A社とします。）

業界内ではそれなりに有名な会社。

A社のプロジェクトに十数年前に1メンバーとして参加した記憶もある。



試験中はソースの変更は禁止されているため、

暇なので、データベースに接続して中をのぞいて見た。

まずは、テストデータの量に驚いたが、

何より驚かされたのは、データの変更状況。





有り得ないはずのデータ変更が行われている。

売上伝票の一番上の行にはAタイプの商品を登録することになっており、

Aタイプ以外は登録できないようにシステムで制限をかけている。

にもかかわらず、一番上の行にBタイプやCタイプの商品が登録されている。

なぜ、こんなことができるのか。

システムがバグがある?。

自分の作ったシステムは疑いたくないのだが、

動かぬ証拠を突き付けられた真犯人みたいな心境になってくる。

システムをデバッグしたくなったが、脆弱性試験の終了を待つことにした。


脆弱性試験 -試験前-

tarコマンドでディレクトリを圧縮すると、



と表示される。

少し、嫌な感じ。

以下のページを参考にして解決した。

　http://daybreaksnow.hatenablog.jp/entry/2014/03/01/204940


　tar -cvzf /home/backup/dir_name.tgz /home/public_html/dir_name

　　　dir_name　 : 圧縮するディレクトリ名
　　　dir_name.tgz : 新しく作成する圧縮ファイル名


　tar -cvzf /home/backup/dir_name.tgz -C /home/public_html dir_name

これでエラーメッセージが消えた。