Jtest －Java対応自動テストツール－
今月のピックアップ
Parasoft Jtest 8.3 技術資料
セキュアコーディングのすすめ 2
前回の「今月のピックアップ」においてOWASP TOP 10やMITRE 2006の脆弱性の報告件数を基にWebアプリケーションの脆弱性は以前と変わらず増加傾向にある、という事を書きました。
その記事の中にもありましたが、OWASP Top 10 2007と2004を比較すると、クロスサイトスクリプティングとインジェクション系の脆弱性が増加傾向にあります。
その記事の中にもありましたが、OWASP Top 10 2007と2004を比較すると、クロスサイトスクリプティングとインジェクション系の脆弱性が増加傾向にあります。
表 1 OWASP Top10 ⁄ 2007 と 2004 の比較
これらのWebアプリケーションの脆弱性は、Webアプリケーションが一般的に利用されるようになった当初から脆弱性として認識されている問題で、特に目新しいというわけではありません。古くから脆弱性として認識があるにも関わらず、いまだに報告される脆弱性として上位を占めており、さらに増加傾向にあるようです。また、近年では、Cross Site Request Frogery（CSRF）といった比較的目新しい脆弱性も確認されています。
では、こういったWebアプリケーションの脆弱性に対してどのような対応を行う必要があるでしょうか。OSやアプリケーションサーバのバグによるセキュリティホールを突かれ、攻撃をされる場合は事前に対策を行うことはなかなか難しいかも知れません。
しかし、アプリケーションレベルでの脆弱性を防止する手段は、いくつかの方法が考えられます。例えば、WAFやIDSなどが導入といった事も有効な手段です。これらのシステムは開発者がセキュリティ対策へ掛ける負担を軽減し、アプリケーションの安全性を高め、脆弱性を防御する事ができます。
では、こういったWebアプリケーションの脆弱性に対してどのような対応を行う必要があるでしょうか。OSやアプリケーションサーバのバグによるセキュリティホールを突かれ、攻撃をされる場合は事前に対策を行うことはなかなか難しいかも知れません。
しかし、アプリケーションレベルでの脆弱性を防止する手段は、いくつかの方法が考えられます。例えば、WAFやIDSなどが導入といった事も有効な手段です。これらのシステムは開発者がセキュリティ対策へ掛ける負担を軽減し、アプリケーションの安全性を高め、脆弱性を防御する事ができます。
図 1 WAF（Web Application Firewall）
もちろん、これらのシステムが導入されたからといって、100%脆弱性を防御できるという訳ではありません。WAFやIDSなどを使ってアプリケーションへ到達する前にリスクを防いでも、アプリケーションそのものが脆弱性を持ったままでは意味がありません。これらのシステムに検知されないような攻撃もあるかも知れませんし、そもそも予算の関係などで導入できない場合もあるかも知れません。
つまり、アプリケーション自体もセキュアなものである必要があります。
アプリケーションの脆弱性はコーディングの段階で（ソースコードレベルで）実装方法に気をつける事によって多くのリスクを減らす事ができます。しかし、実際のプロジェクトの中ではセキュリティを意識したコーディングを行う事がなかなか難しいという話をよく聞きます。
その理由としては以下の様な事が考えられます。
つまり、アプリケーション自体もセキュアなものである必要があります。
アプリケーションの脆弱性はコーディングの段階で（ソースコードレベルで）実装方法に気をつける事によって多くのリスクを減らす事ができます。しかし、実際のプロジェクトの中ではセキュリティを意識したコーディングを行う事がなかなか難しいという話をよく聞きます。
その理由としては以下の様な事が考えられます。
- 開発者の技術レベルにバラつきがある
- プロジェクトに参加している開発者全員がセキュアコーディングに関する知識が有り、技術レベルが高いというのは稀で、多くの場合は開発者ごとに技術レベルにバラつきがあると思います。技術レベルの高い開発者がチーム内にセキュアコーディングのノウハウを浸透させるというのは大変な作業であり、ソースコードレビューやテストなどに多くの時間を割く事になります。
- セキュリティに関してまでテストしている余裕がない
- 納期のあるシステム開発の中で顧客の要求を満たす機能を実装しながら、単体テストや機能テストを行う必要があり、さらにはパフォーマンスに関しても考慮しなければなりません。そんな状況で、セキュリティに関するテストも行うとなるとそこにかける工数に余裕がない、という場合もあります。また、テストに漏れがある場合も考えられます。
それではどうすればセキュアなコーディングが実現できるのでしょうか。
これらの問題に対処してセキュアなコーディングを行うためにはツールの利用が効果的です。
ツールを使う事で実装したコードがセキュアなものかを検証できます。ツールによってソースの検証を自動化する事により、上記に挙げた問題である技術レベルのバラつきや、テスト漏れ、考慮漏れといった部分を減らし、一定のレベルまで引き上げることができるようになります。
また、一番の問題である工数もツールによる自動化を行うことで大幅に削減することが可能です。ツールによる検証もまた、セキュリティ上の脆弱性が100%防御できるというわけではありませんが、脆弱性を防御する上で守らなければいけない社内ルールの準拠の検証や、脆弱性の検証を行うことにより、品質を確保できます。
このような検証を行うためにParasoft Jtestは有効なツールであると言えます。
Jtest8.3では以前は有償であった静的解析におけるセキュリティルールが無償で付属する様になりました。それによって、脆弱性対策としてソースコードに対して以下の検証を行う事ができます。
これらの問題に対処してセキュアなコーディングを行うためにはツールの利用が効果的です。
ツールを使う事で実装したコードがセキュアなものかを検証できます。ツールによってソースの検証を自動化する事により、上記に挙げた問題である技術レベルのバラつきや、テスト漏れ、考慮漏れといった部分を減らし、一定のレベルまで引き上げることができるようになります。
また、一番の問題である工数もツールによる自動化を行うことで大幅に削減することが可能です。ツールによる検証もまた、セキュリティ上の脆弱性が100%防御できるというわけではありませんが、脆弱性を防御する上で守らなければいけない社内ルールの準拠の検証や、脆弱性の検証を行うことにより、品質を確保できます。
このような検証を行うためにParasoft Jtestは有効なツールであると言えます。
Jtest8.3では以前は有償であった静的解析におけるセキュリティルールが無償で付属する様になりました。それによって、脆弱性対策としてソースコードに対して以下の検証を行う事ができます。
- バグ探偵を使って実行パスから実際に発生する様な脆弱性の検出
- 静的解析から脆弱性に繋がりやすい、バグとなりやすい実装の検出
また、アプリケーションの品質を確保する上で欠かすことのできない単体テストのテストケースを自動生成することで、高い堅牢性も確保する事ができます。