ソフトウェアアプリケーションのセキュリティリスク TOP 10

作者 Abel Avram , 翻訳者 吉田 英人 投稿日 2010年3月11日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

HTTP ,

W3C ,

Web Server ,

Architecture ,

仕様 ,

セキュリティ

共有 |

原文(投稿日：2010/03/04)へのリンク

ソフトウェアアプリケーションのセキュリティ評価・改善を目標とするオープン組織 OWASP が，OWASP Top 10 アプリケーションセキュリティリスク - 2010 RC1 (PDF) をリリースした。この白書は Web アプリケーションのセキュリティリスクのトップ10と，そこから想定される脆弱性を攻撃者(threat agent) が利用する方法の詳細，さらにその防止策の例とアドバイスを文書化したものだ。

Creative Common Attribution ShareAlike 3.0 ライセンス の元にリリースされた OWASP Top 10 Web アプリケーション セキュリティリスク – 2010 の内容は次のようなものだ。

資料では，これらのセキュリティリスクに対するサイトの脆弱性を判断して攻撃を防ぐ方法と合わせて，攻撃者が行うアタックの例についても説明している。例えばインジェクションセキュリティリスクについては，次のような脆弱な SQL クエリがベースとして利用される。

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") +"'";

攻撃者はブラウザの ‘id’ パラメータに ' or '1'='1 を設定することでこの脆弱性を利用する。これによってクエリの意味が，指定されたユーザだけではなく account データベースのすべてのレコードを返すように変更される。

http://example.com/app/accountView?id=' or '1'='1

結果として実行されるのは 次のような SQL になる。

SELECT * FROM accounts WHERE custID='' or '1'='1'

このようなインジェクションリスクへのアドバイスとして，資料では “信頼性の低いデータをコマンドやクエリから分離する” ことを推奨している。

1. 安全な API を使用するか，あるいはパラメータインターフェースを設けるなどして，インタプリタへの全面的な依存を回避するのが望ましい。ただしストアドプロシージャのように，パラメータ指定であっても内部的にはインジェクションが可能な API に注意が必要だ。
2. パラメータ化された API が利用できない場合は，インタプリタ固有のエスケープ方法を使用して，特殊文字を注意深くエスケープする必要がある。OWASP の ESAPI では，この種のエスケープルーチンがいくつか提供されている。
3. 適切な正規化の後に妥当性チェックや “ホワイトリスト” 検証を行う手法も，インジェクションの防止に効果的だ。ただし特殊文字の入力が必要なアプリケーションでは完全な効果が期待できない場合が多い。OWASP の ESAPI には，ホワイトリスト入力検証ルーチンの拡張ライブラリがある。

本書のトップ10リストは，ソフトウェアアプリケーションのリスク識別・評価方法である OWASP リスク評価手法 に基づき，以下のステップに従って作成されたものだ。

1. リスク識別
2. 可能性予測係数
3. 影響予測係数
4. リスク重要度判定
5. 対処方法決定
6. リスク評価モデルのカスタマイズ

2007 年にリリースされた資料と比較すると，トップ10リストにはいくつか変更された点がある。注目すべきは “悪意のあるファイルの実行” と “情報漏洩と不適切なエラー処理” の２つが削除され，“不適切なセキュリティ設定” と “未検証のリダイレクトとフォワード” が新たに追加されたことだ。

オープンWebアプリケーション・セキュリティ・プロジェクト（Open Web Application Security Project，OWASP)は OWASP 基金の支援する，ソフトウェアアプリケーションのセキュリティ向上を目標とした非営利慈善団体であり，セキュリティツールや規格の無償提供，アプリケーションのセキュリティテスト/セキュアなコード開発/コードレビューなどの書籍出版，セキュリティに関するコントロールとライブラリの提供，カンファレンスの開催，調査研究，メーリングリスト運営などの活動を行っている。