編集部からのお知らせ
記事まとめPDF「日本のスタートアップ」
お勧め記事まとめPDF「マイクロサービス」

サイト脆弱性をチェックしよう!--第3回:開発工程におけるレビューやテストのコツ(その1) - (page 3)

池田雅一(テクマトリックス)

2007-08-30 12:00

 詳細設計では、以下のようなことに注意してレビューを行う。

1)概要設計時に検討したセキュリティ対策が機能として取り込まれているか?

 概要設計時にセキュリティ対策を検討していても、機能として実装されていなければ意味がない。概要設計ではセキュリティ対策を大まかに決定するが、詳細設計では実装レベルにセキュリティ対策機能を落とし込む。レビューでは、セキュリティ対策の内容だけではなく、対策に漏れが無いか確認する。

2)各機能の構造は単純化されているか?

 構造が複雑になることで、バグが混入する可能性が高くなる。バグが脆弱性につながることもあるので、単純な構造にすることがセキュリティの向上につながる。

3)フェイルセーフの設計がなされているか?

 アプリケーションの通常利用ではありえないことや、障害が発生した場合でも、被害を最小限にしたり、問題なく利用できるような設計にすることでセキュリティを向上することができる。フェイルセーフの例として、機密データを公開暗号方式で暗号化し、秘密鍵はサービス提供しているサーバ上に保存しないという万が一のデータの漏えいに備える方法がある。

4)入力データが信頼できないものであれば、信頼できるようにする方法が明確になっているか?

 信頼できない入力データ(ブラウザからリクエストされるパラメータだけでなく、ファイルやDBに格納されているデータも含む)を信頼して利用するためにさまざまな脆弱性を生むことになる。信頼できないデータを信頼できるようにする方法の1つは、第2回の記事で紹介したように、入力データの検証をおこない、許可されているデータかどうかを確認することだ。

 このデータの検証方法には、次の4つの方法がある。

  • データの型が正しいか?:例えば、数値項目に英字、記号が含まれていないか?
  • データに含まれる文字種類、データフォーマットが正しいか?:たとえば、メールアドレスを意味するデータに対して、メールアドレスで許可されていない文字は含まれていないか?
  • 選択項目(チェックボックス、ラジオボタン、セレクトリスト)の場合、提示されている選択肢に含まれているか?
  • データが想定している範囲内に収まっているか?:たとえば、データが自然数の場合、ゼロ以上の整数であることを確認しているか?

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]