詳細設計では、以下のようなことに注意してレビューを行う。
1)概要設計時に検討したセキュリティ対策が機能として取り込まれているか?
概要設計時にセキュリティ対策を検討していても、機能として実装されていなければ意味がない。概要設計ではセキュリティ対策を大まかに決定するが、詳細設計では実装レベルにセキュリティ対策機能を落とし込む。レビューでは、セキュリティ対策の内容だけではなく、対策に漏れが無いか確認する。
2)各機能の構造は単純化されているか?
構造が複雑になることで、バグが混入する可能性が高くなる。バグが脆弱性につながることもあるので、単純な構造にすることがセキュリティの向上につながる。
3)フェイルセーフの設計がなされているか?
アプリケーションの通常利用ではありえないことや、障害が発生した場合でも、被害を最小限にしたり、問題なく利用できるような設計にすることでセキュリティを向上することができる。フェイルセーフの例として、機密データを公開暗号方式で暗号化し、秘密鍵はサービス提供しているサーバ上に保存しないという万が一のデータの漏えいに備える方法がある。
4)入力データが信頼できないものであれば、信頼できるようにする方法が明確になっているか?
信頼できない入力データ(ブラウザからリクエストされるパラメータだけでなく、ファイルやDBに格納されているデータも含む)を信頼して利用するためにさまざまな脆弱性を生むことになる。信頼できないデータを信頼できるようにする方法の1つは、第2回の記事で紹介したように、入力データの検証をおこない、許可されているデータかどうかを確認することだ。
このデータの検証方法には、次の4つの方法がある。
- データの型が正しいか?:例えば、数値項目に英字、記号が含まれていないか?
- データに含まれる文字種類、データフォーマットが正しいか?:たとえば、メールアドレスを意味するデータに対して、メールアドレスで許可されていない文字は含まれていないか?
- 選択項目(チェックボックス、ラジオボタン、セレクトリスト)の場合、提示されている選択肢に含まれているか?
- データが想定している範囲内に収まっているか?:たとえば、データが自然数の場合、ゼロ以上の整数であることを確認しているか?