公開ファイルや設定面のWebアプリケーションのセキュリティ

アプリケーションのセキュリティはSQLインジェクションやXSSのような脆弱性だけ対応していればOKとはなりません。

作った人はまずいものを作ろうとしていないはずですが、結果的によくない状態になっていることがあります。

以下、事例の紹介と対応策について書きます。

不要なファイルがドキュメントルートに配置されている

運用中のシステムでダンプしたMySQLのデータや、フォームから入力された内容が出力されたファイルがドキュメントルート配下に保存されていて、http://example.com/dump.sqlでアクセスすると見える状態になっていたりしませんか?

そんなバカなと思う人もいるかもしれませんが、こういう状態が現実に存在します。

対策

・本当に取られて困るファイルをドキュメントルートに出力することをやめる。

・出力しているファイルがあれば削除する。

変更前のファイルを別名でサーバに置いている

例えば、config.phpというPHPがあり、中にDBの接続情報が書かれています。このファイルはドキュメントルート配下にあります。

config.phpに更新があったので本番アップする時に、古いファイルをconfig.php.bkとしてサーバ内に残しました。

さて、このファイルをhttp://~/config.php.bkでアクセスされたらどうなるでしょう?

答え:PHPとして実行されないため、コードが丸見えになる

丸見えはまずいですよね。

対策

・古いファイルは本番サーバ内に残さない。

・一時的に残す場合でも拡張子を変えない。もしくはアクセスしてみてどう見えるか確認する。

管理画面のURL・パスワードが単純

Webシステムの管理画面のURLが

http://example.com/admin/ のように単純になっていませんか?

こういう状態が現実n(以下略

対策

・推測しやすい管理画面のURLは避ける。

・できればベーシック認証でID・パスワードを入力させるか、接続できるIPアドレスを制限する。

単純なURLになっている場合はログインID・パスワードも単純だったりします。しっかりと複雑なパスワードを設定しましょう。16文字以上で半角大小英数字と記号を含んでいるようなものがいいです。

さいごに

こういうことが実際にあります。しっかり脆弱性対策をしていても正しいID・パスワードで正面突破されたら意味がありません。

普段なんとなくやっていることがセキュリティ的にどうなのか考えるきっかけになればと思います。

コメント

タイトルとURLをコピーしました