脆弱性チェック - ikepyonのだめ人間日記

某所のネタを他の人からもらうために、書きなぐってみるw
脆弱性のチェック方法として、レビューとテストという二つがあると思う。
まあ、レビューがチェックなのか？という突っ込みは別にして、ソースコード監査も一種のコードレビューだからレビューもチェック方法のひとつとしよう。
そのうち、レビューは設計レビューとコードレビューに分かれるだろう。
とまあ、その時どういった観点でレビューするかというのをつらつら書き出してみると以下のようになるかな？

設計レビュー

・基本設計

- 機能設計／リソース
  - 機能・リソースへの脅威に対する対策が十分か？
  - 特に重大な被害を及ぼす脅威に対して複数の対策を施しているか？
  - 不要な機能はないか？
  - 機密性・完全性・可用性について適切な評価を行っているか？
- I/O関連
  - 信頼できるInputか？
    - ユーザから入力されるものは信頼できない
    - ファイルから読み込まれるものはファイルを作成する機能が信頼できるのであれば、信頼できる
    - ネットワーク越しのデータは信頼できない
  - Output時に気をつける必要があるか？
- 使用するツール・言語の適正確認
  - 使用するツール・言語で難しい機能はないか？

・詳細設計

- 機能設計
  - 構造が単純か？
  - フェイルセーフの考えが取り入れられているか？
  - I/O関連
    - Inputが信頼できない場合、信頼できるものにする方法は？
    - Output時にどうすれば安全にできるか？
    - アクセス権限の確認
      - 必要最低限の権限か？
      - 機密情報が外部からアクセスできないか？

コードレビュー

・コーディング規約

- 間違って見えるようにする方法
- 安全なライブラリ・フレームワークの使用
  - バインドメカニズム
  - 暗号ライブラリ
  - セッション管理ライブラリ

・ソースコードレビューのコツ

- 入力データの追跡
- 出力データの追跡
- 境界条件の確認
- エラー処理の確認

さて、一方テストはというと、基本的には異常系のテストになる。
ということで、実施する項目はこんな感じだろう。

テスト項目

・入力データのテスト

- 型チェック
- 特殊文字チェック
- 選択肢以外のデータチェック
- Hiddenフィールド、Cookie書き換えチェック
- 桁数チェック
- 境界値チェック
  - 大きい値
  - 小さい値

・呼び出しのテスト

- 処理フローを無視した呼び出し
- 同時呼び出し

こんな感じかな？抜けがあるかと、考え方が間違ってないかもうちょっと考えないと

(2007/8/16追記)
ちといろいろアイデアもらったり、考え直したりしたので、修正したFreeMindのマインドマップを公開してみる
http://www.geocities.jp/ikepy0n/docs/vulnerabilitycheck.pdf
[?]は疑問、[!]は例、[アイディア]はまんまアイデア、[危険]は問題点といったところかな。