---

もう掲示板の技術的な話で特筆すべきところは、昨日問題を見つけて改良したバリデーション周りぐらいしかないと思うので、そんなのはTipsみたいな感じで後で書こうかなと。

今日からはまた別の話をします。といってもタイトルに書いてますね。エラーです。
この12月は、今まで全く触れてこなかったエラーについての話をしていきたいと思っています。



現段階では、バリデーションはエラー表示が返ってきますけど、それ以外のエラーって特に何も定義してないんですよね。
エラーが起きたら、フレームワークのエラー画面が表示されるはずなので、別に変な処理が続行されるってことはたぶんないと信じたいです。



じゃあ別にいいんじゃね？って思われるかも知れませんがエラー画面はハッキングの大きなヒントになるんですよ。
どこでエラーが起きたかとかは隠さなければならないんですね。




例えば、存在しないページにアクセスしようとすると、こんなエラーが出ます。
どこどこでエラーが起きてる･･････なんて人に教えてやる道理はありません。404エラーって言っておけば通じます。

ということで、まずはこのテスト用の機能を切ることから始めましょう。




まぁこれに関しては簡単です。.envのAPP_DEBUGという項目をfalseにすれば良いだけです。




すると、こんな風になんも表示されなくなります。



さらに、エラー画面はハッキングの大きなヒントになる、こともあるのですがそもそもエラー画面自体が脆弱性というパターンがPHPにあります。
具体的な事例はPHPのdisplay_errorsが有効だとカジュアルにXSS脆弱性が入り込む(徳丸浩の日記)にも書かれていますが、display_errosは本番では切っておくべきでしたね。
まぁこんなのはphp.iniの設定でどうにかなります。プログラム内で設定はできるんですが、サーバー側で設定しとかないとFatalErrorでは無視されます。(プログラム自体が実行されないため)

このことからわかるのは、エラーメッセージの出力がアレだったら、充分に脆弱性たりえる、ということですね。
まぁ、Laravel使ってると、さっき画像で挙げたようなエラーがたぶん優先されて表示されるような気がするので関係ないかも知れませんが、とりあえずローカルと本番環境では設定は変えた方が良いというのを認識しましょう。当たり前のことですね。



じゃあエラー対策ってそれだけで良いのかって話になりそうですね。
表示の問題だけならいざしらず、例えばデータベースへの挿入が通信エラーで失敗した時のトランザクションとかどうしますか･･････？



といった話を、これから数度に分けてやりたいなーと思ってます。（笑）