脆弱性コラム - 第3回
サイト脆弱性をチェックしよう！ -- 第3回：開発工程におけるレビューやテストのコツ
前回、前々回と脆弱性の発生個所といった観点から脆弱性について考えてきた。今回からは、安全なアプリケーションを作るためのチェック方法について説明していきたいと思う。安全なアプリケーションを作成するには、ただ構築するだけでなく、各開発工程におけるレビューと適切なテストが必要になる。レビューを行うことにより、考慮漏れや誤りを見つけ出し、少ない工数で修正することが可能になる。
また、テストを行うことで、作成したアプリケーションに問題が無いことを確認することができる。しかし、実際にレビューやテストはどのよう行えばよいのか分からないのが実状ではないだろうか。
そこで、今回はレビューやテストのコツを紹介する。
「設計レビュー」と「コードレビュー」
レビューを分類すると「設計レビュー」と「コードレビュー」の大きく2つがある。セキュリティ対策という観点での設計レビューでは、存在する脅威に対して適切な対策が検討されているかを確認する。一方、コードレビューでは、設計フェーズで検討した対策が、設計したとおりに実装されているかということを確認する。これら2つのレビューを適切に行うことで、開発時のセキュリティ対策に必要なコストを低減しつつ、効果的な対策を行うことができる。
- 設計レビューのコツ
それではまず、設計レビューではどういったことに注意して確認する必要があるのか、そのポイントを説明する。
セキュリティ対策を行うには、「守るべきものは何か？」ということを明確にしておく必要がある。これが明確になっていないと必要な対策が取れていなかったり、必要以上に対策を行う可能性がある。
そこで、設計段階で必要な機能、データに対してリスク分析を行う。リスク分析を行った上で対策の必要があるものについて、対策を実施することで、セキュリティ対策に必要なコストを抑えることができる。
詳しくは、マイクロソフトの「TechNet」などを参照してほしい。
リスク分析を行い、設計が終わった段階でセキュリティ対策についてのレビューを実施することになる。
概要設計の段階では、以下のようなことに注意してレビューを行う。
1）各機能、使用するデータの機密性、可用性について適切な評価を行っているか？
既に組織でISMSを取り入れている場合は、それに準じた評価を行う必要がある。もし、組織がISMSを取り入れていない場合、たとえば以下のようにレベル分けを行う。
完全性については、ウェブプリケーションではほとんどの場合、高いレベルで必要となるので除外している。
| 機密性 |
|---|
| 低：公開情報や誰でも使用できる機能（たとえば、商品の価格情報、商品検索機能など） 中：漏えい、不正利用されても、多大な影響は出ないが特定のユーザーにしかアクセスできない情報や機能（たとえば、登録ユーザのみに提供する情報、買い物カゴ機能など） 高：漏えい、不正利用されると多大な影響が出る情報や機能（たとえば、ユーザの個人情報、管理者用メンテナンスメニューなど） |
| 可用性 |
| 低：常時必要としない情報や機能 たとえば、管理者用メンテナンスメニューなど 高：常時必要とする情報や機能 たとえば、ユーザーのログイン情報、各種ユーザーへ提供する機能など |
完全性については、ウェブプリケーションではほとんどの場合、高いレベルで必要となるので除外している。
2）各機能、使用するデータに対するリスクの洗い出しを適切に行っているか？
リスクの洗い出しが不十分な場合、対策しなければならないリスクが見過ごされ、脆弱性が残ることがある。リスクには、例えば、通信内容が暗号化されていないために盗聴される、商品検索機能のバグにより個人情報が漏えいするなどがある。
3）すべてのリスクに対して、評価を行い、対策を行っているか？
すべてのリスクを、ゼロにすることはアプリケーションを作らないこと以外にはない。被害が受容できないリスクは、何らかの対策でリスクを軽減して、受容できるようにしたり、他のサービスで代用してリスクを転嫁する必要がある。
対策すべきリスクの軽減は、次のとおり。
この段階でのレビュー結果が後の詳細設計やコーディングでの対策に影響を与えるので、十分な検討が必要となる。また、必要に応じてセキュリティ対策となる機能を追加する。
対策すべきリスクの軽減は、次のとおり。
| リスクの軽減を適切に実施しているか？ |
|---|
|
| リスクの回避を適切に実施しているか？ |
|
| リスクの転嫁を適切に実施しているか？ |
|
| 受容するリスクはすべて容認できるか？ |
|
この段階でのレビュー結果が後の詳細設計やコーディングでの対策に影響を与えるので、十分な検討が必要となる。また、必要に応じてセキュリティ対策となる機能を追加する。
詳細設計では、以下のようなことに注意してレビューを行う。
1）概要設計時に検討したセキュリティ対策が機能として取り込まれているか？
概要設計時にセキュリティ対策を検討していても、機能として実装されていなければ意味がない。概要設計ではセキュリティ対策を大まかに決定するが、詳細設計では実装レベルにセキュリティ対策機能を落とし込む。レビューでは、セキュリティ対策の内容だけではなく、対策に漏れが無いか確認する。2）各機能の構造は単純化されているか？
構造が複雑になることで、バグが混入する可能性が高くなる。バグが脆弱性につながることもあるので、単純な構造にすることがセキュリティの向上につながる。3）フェイルセーフの設計がなされているか？
アプリケーションの通常利用ではありえないことや、障害が発生した場合でも、被害を最小限にしたり、問題なく利用できるような設計にすることでセキュリティを向上することができる。フェイルセーフの例として、機密データを公開暗号方式で暗号化し、秘密鍵はサービス提供しているサーバ上に保存しないという万が一のデータの漏えいに備える方法がある。4）入力データが信頼できないものであれば、信頼できるようにする方法が明確になっているか？
信頼できない入力データ（ブラウザからリクエストされるパラメータだけでなく、ファイルやDBに格納されているデータも含む）を信頼して利用するためにさまざまな脆弱性を生むことになる。信頼できないデータを信頼できるようにする方法の1つは、第2回の記事で紹介したように、入力データの検証をおこない、許可されているデータかどうかを確認することだ。
このデータの検証方法には、次の4つの方法がある。
このデータの検証方法には、次の4つの方法がある。
- データの型が正しいか？：例えば、数値項目に英字、記号が含まれていないか？
- データに含まれる文字種類、データフォーマットが正しいか？：たとえば、メールアドレスを意味するデータに対して、メールアドレスで許可されていない文字は含まれていないか？
- 選択項目（チェックボックス、ラジオボタン、セレクトリスト）の場合、提示されている選択肢に含まれているか？
- データが想定している範囲内に収まっているか？：たとえば、データが自然数の場合、ゼロ以上の整数であることを確認しているか？
5）出力データが適切にエスケープ処理されているか？エスケープ処理の方法が明確になっているか？
第2回の記事で紹介したように出力データの処理漏れによっても脆弱性が発生する。自らエスケープ処理を実装しなければならない場合は、エスケープ対象となるデータが明確になっているか確認する必要がある。6）各機能、データに対するアクセス権は必要最低限のものしかないか？
不必要なアクセス権で各機能、データにアクセスすることは被害を拡大する原因となる。たとえば、DBのアクセスユーザーに管理者権限を設定していた場合、SQLインジェクションの脆弱性があると、データベースの破壊という被害に拡大する恐れがある。その他にも、機密情報を外部から直接アクセスできる場所に保存することで、数年前に多発した個人情報の漏えい事件のような多大な被害をこうむる危険性もある。
また、機密情報だけでなく、一時的な内部情報を外部からアクセスできる場所に保存することも同様に危険だ。攻撃者は、一時的な内部情報も攻撃の糸口として利用するためだ。
これらの設計レビューを行った後、コードを記述することで、設計段階でしか防げないような脆弱性をなくし、万が一コーディングミスがあったとしても、その被害を最小限にすることが可能となる。
次回は、引き続き各開発工程におけるレビューと適切なテストについて説明する。
イベント・セミナー
ニュース・キャンペーン
AppScanに
関するお問い合わせ
テクマトリックス株式会社
東京本社ネットワークセキュリティ事業部
第3営業部
セキュリティプロダクツ営業2課03-4405-7814
- メールでのお問い合わせ
- watchfire@techmatrix.co.jp