頭でっかちな論理武装している人より、良く分かっていない人の方が、実は危険を回避していることは良くある話だと思います。
つまり、頭でっかちな論理武装している人は、無駄なことをしないのでスマートにみえるけど、結局、無駄なことをしていることで助かった事例をみれば、その程度はやっておいたほうがよいかな？と僕は思う。
そう思わない人は、自己責任でそうすればよい。
ただし、組織で決まっている、サービスで決まっている場合は、そのルールに従うしかないと思う。
いくら無駄だといっても、責任を取れるのは無駄だと言っている人たちで無くて、管理している側だから。
責任を追及できる相手は、管理している側で、無駄だといってルールを変えさせる側ではないのだから。実際に責任を取るかどうかは別にしても・・・。
パスワードを定期的に変更するのは、無駄なのか？
パスワードを変更する必要があるとき
パスワード(の全部もしくは一部)がバレたとき、で良いと思うんだよね。
例えば、全然家に寄りつかないドラ息子が妙にATMでお金をおろさせようとする。
金をおろした後、なんかスマホで撮ってたような気がする。なんてときは、サーモグラフィで数字4つはバレたかもしれない。
すると、たかだか24通りなので、1日3回ミスでロックがかかる（つまり2回までは試せる）なら、6日でほぼクラックされる。
こういう時は、即変更するべき。
パスワードはバレてから変更すれば良い派(最適変更間隔変じゃね)
実際は、スマホでとられていても気づかないかもしれないわけで、
気づけば変更するのは当然なんだけど、
気づかない場合のことも考えて、定期的に変えるのは、ダメなことなんでしょうか？という問題に関しては
どう考えますか？
そういう単純なことなんですね。
まあ、パスワードを定期的にかえるより、そういう風に撮影されないように用心すべきだという論理も作れるんだけど、それって、リスク回避とかいう話ではないと思う。パスワードを定期的に変えたくないという論理がさきにあるだけでは？と思う。
「セキュリティ対策」は、些細なことの積み重ねだと思う
「不正な入力に対して脆弱性を発生させないようセキュリティ対策としてバリデーションを行う」。アホか。プログラマならセキュリティ対策とか気にするな。いや、気にするなというのは言い過ぎだけれど、ほとんどの場合においてあなたの書くコードはセキュリティ対策の必要性はない。
攻撃者の細工した入力によってSQL/HTML/JavaScriptが壊れるとかバッファオーバーフローが発生するとか、そういった脆弱性と呼ばれるほとんどのものはただのバグだ。
もちろん例外もあるかもしれないけど、それはあくまでも例外だ。日常的に書くコード － 長さやフォーマット、範囲のチェックだったり、次の処理系に適したエスケープを施したり － は全てセキュリティ対策のためのコードではない。アプリケーションが正しく動くための処理だ。それができていないのはただのバグだ。
「セキュリティ対策」
入力値のチェックは、セキュリティ対策になることもあるって言う話で問題ないと思うんですが違うんでしょうか？
仕様以外の入力値を許さない、仕様以外の動作を許さないというのは、僕はセキュリティ対策だと思います。
いうなれば、プログラマーができるセキュリティ対策だと思います。
入力値のチェックも、要所要所で行うことが重要で、
こういう入力値しかこないからという想定では危険だということを認知させるためにも、セキュリティ対策で問題ないと思います。
WEB系なら、
1.javascriptでチェック
2.PHPでチェック
3.SQLを発行する前にもチェック
とかがあるかと思います。
１のチェックはすり抜けることができるので２は必要だけど
３は必要かな？といか言う論理もあるのですが、
３でもチェックしたほうが安全なのは安全でしょう。
２のチェックをすり抜けるのはバグだけど、３でチェックしていればそのバグですり抜けてきてもまだ防御できるという論理ですね。
「入力値以外は動作は保障されません」というのは、バグではなくて仕様だと解釈する人たちもいるので、そのバグはユーザー視点でのバグだと思います。
入力値といっても、関数レベル、オブジェクトレベルの引数のチェックだと考えることもできるかと思う。
もし、「セキュリティ対策という視点で入力バリデーションをしていない」ということに対して不安を覚える開発者がいるのであれば、セキュリティ対策など考えなくていいので今すぐテストを書け。
「セキュリティ対策」
揚げ足取るようでわるいけど、文意の意味では、テストを書く意味はないと思う。
・「SQLインジェクション対策漏れ」の重過失認定は妥当か?! | ただの通りすがり
を書くときにしらべたけど、
結局、クレジットカードの番号が漏れ出した状況証拠はあっても、どうやって漏れたのかが分からないという感じでした。SQLインジェクションが原因だと特定されていないということですね。
ただ対策がされていないので、重過失ありだと判断されています。
「SQLインジェクション対策」も、実際には変数（入力値）のチェックであって、そのチェックをしていませんという話だと思います。
もちろん、単なる入力チェックと、セキュリティ対策という視点でも入力チェックの違いというのをあげれるとはおもうけど、その違いにあまり意味はないと思うんですね。
ただ、セキュリティ対策という視点でこうゆう入力値はチェックする必要があるというのはあると思います。
業務仕様という観点での入力チェックに加えて、プログラムよりのセキュリティよりの入力チェックというのは存在しているかと思います。
絶対に大丈夫なはずなのに、暗号化してDBに格納するとかそういう路線とにていると思うんですね。
どんなに頑張っても、バクを0にはできないというのはある
テスト項目があって，合格しているという事実以外何の意味があるのか？合否の結果が正しいというのは信じるしかない．テスト項目に漏れがないことも証明不可能だ．
論理で論理（コード）が正しいことは証明できない．なんでも理由とか根拠とかを求める論理的な人は，論理を理解していないのだ．*1
そうは言っても，バグってたら困るから，バグを少なくする工夫は当然する．
コードが正しいことは証明できない - 超ウィザード級ハッカーのたのしみ
バグは少なくできても、0にはできないという事情がある。
テスト至上主義者？も、この辺りを理解できていないような気がする。
スポンサーリンク
コメントを残す