SST連載・解説記事

  1. HOMEHOME
  2. SSTコラムSSTコラム
  3. SSTなるほど!コーナー
  4. 08 Struts2への現実的な対策は脆弱性診断?WAF?

(2017年7月13日公開)

08 Struts2への現実的な対策は脆弱性診断?WAF?

Struts2への現実的な対策は脆弱性診断?WAF?

ここ数年、WebアプリケーションフレームワークのStruts2について危険度の高い脆弱性が立て続けに報告されています。

Webサイトを構築した後は脆弱性診断とWAFでセキュリティを向上させることができます。では、Struts2を使ったWebサイトでは、脆弱性診断とWAFのどちらがより効果的でしょうか?脆弱性診断を行えば、Struts2の脆弱性についても対策できると考えて良いのでしょうか?

Struts2の脆弱性に対して、脆弱性診断で対応が難しい

結論から言うと、Struts2の脆弱性については、以下のような理由で脆弱性診断を行っても対応が難しいとSSTでは考えています。

  • Struts2の脆弱性への対応有無が診断会社によって異なる。
    • 診断会社によっては、診断内容としてStruts2の脆弱性に対応していないケースがあります。SSTのWebアプリケーション/プラットフォーム診断がこれに該当します。対応有無が分かれる理由としては診断対象の違い(Webアプリケーションのビジネスロジックか、全部か)、診断手法の違い(ブラックボックステストか、ホワイトボックステストか)、検査コストの問題などがあります。
  • WebアプリケーションとStrust2とで開発のライフサイクルが異なる。
    • Struts2はオープンソースとして開発されているため、Struts2の新バージョンが公開される前に予め脆弱性診断を実施することができません。また、公開されてから攻撃が始まるまでの期間は短くなっており、その間に脆弱性診断を実施して影響の有無を調べるのも現実的ではありません。そもそも、使用しているStruts2が影響を受けるバージョンかどうかは、診断会社ではなく、ソースコードを管理している開発・運用側の方が素早く・正確に判断できます。

OS/ミドルウェア/プログラミング言語/ライブラリまで含めたライフサイクル管理が理想だが・・・

ライフサイクルの話はStruts2だけにとどまりません。理想的には、使用しているOS/ミドルウェア/プログラミング言語/ライブラリまで含めたライフサイクル管理が必要で、各レイヤー毎に、使用しているコンポーネントの更新情報を把握し、自分たちのシステムで更新が必要か確認するサイクルを回す必要があります。しかしながら、現実的には人的・時間的なリソース不足でこのサイクルを回せない現場がほとんどでしょう。

使用しているコンポーネントが脆弱性対応のために更新された場合、Webアプリケーションの開発者・運用者は2つのリスクを天秤にかけます。

  • (A) コンポーネントをアップデートした場合
    • →Webアプリケーションに不具合が発生するリスク
    • (→テストやお客様サポートにかかるコストが発生)
  • (B) コンポーネントをアップデートしなかった場合
    • →脆弱性を攻撃されてセキュリティ事故を引き起こすリスク
    • (→情報漏えい被害などへの対応コストが発生)

Struts2についてはコード実行など危険度の高い脆弱性が多く発見されている上に、脆弱性の情報公開から実際に攻撃が始まるまでの時間は短くなる一方であることから、(B)のリスクがあまりにも大きくなりすぎたコンポーネントであると考えられます。

ライフサイクル管理もリソース上難しく、迂闊にアップデートしたことでWebサイトに不具合が発生する可能性と常に背中合わせという状況の中、新バージョンが公開されたらすぐに攻撃が始まる可能性もあり、時間的に非常に厳しい状況に置かれているのがStruts2を使ったWebアプリケーションであると言えます。

このような状況で脆弱性診断がうまく効果を発揮しないのは先に紹介した通りですが、ではWAFはどうでしょうか?WAFは時間的に厳しい状況に、どのような解決策を切り開いてくれるでしょうか?

WAFで時間を稼ぎ、現実的な対策を!

WAFは防御に特化しており、攻撃パターンを検知する「シグネチャ」を組み込むことで、防御が可能になります(シグネチャでは対応できない脆弱性もあります)。Struts2で新たな脆弱性が発見された場合、攻撃パターンを調べることでシグネチャで防御可能か判別し、防御可能であればシグネチャを組み込み防御します。 新しいシグネチャをどう組み込むのかはWAFの仕様によりけりですが、Scutumでは自動でシグネチャをアップデートする仕組みで、WAFの利用者が手を動かす必要はありません。 最近の例として、S2-045の脆弱性が公開された時点で、Scutumでは既存のシグネチャで攻撃を防ぐことができており、その後もタイムリーにシグネチャをアップデートしています。 脆弱性情報の公開から防御シグネチャを組み込むまでの間の、僅かな隙間を狙った攻撃についても防御することが可能です。

さらにScutumでは、今後もStruts2についてはOGNLの扱いに起因する脆弱性と攻撃が発生する可能性が高いことから、OGNLインジェクションを全般的に止められる基本ルールを強化しました。

本記事執筆時点で新たに公開されたS2-048についてもOGNLに起因する脆弱性のため、Scutumでの防御に成功しています。

このように、WAFを使うことで「今、すぐ」やってくる攻撃を防ぎ、時間を稼ぐことができます。時間を稼いだ上で、Struts2の新バージョンに入替えてじっくりとテストすることが可能となります。あるいは、Struts2ではない別のWebアプリケーションフレームワークに乗り換えるという長期的かつ抜本的な対策をすすめることも出来るでしょう。

まとめ

Struts2などのWebアプリケーションフレームワーク、ライブラリ、ミドルウェアなどは、外部で開発や脆弱性対応が進められているため、脆弱性診断ではセキュリティを担保することが難しいコンポーネントになります。 これらのライフサイクルやセキュリティ情報を適切にウォッチ・管理していくのが理想ですが、そこまでリソースを投入するのは難しいのが現実です。 しかし攻撃者はそのような状況を待ってくれません。「今、すぐ」やってくる攻撃に対処できなければ、現実的な対応とは言えません。 そこで、WAFでまずはStruts2への攻撃を防いで時間を稼ぎ、その間に短期・長期のバランスを考慮した対策を進めていくのが、現実的で有効なアプローチとなります。

今までのコラム

Webセキュリティをざっくり理解するための3つのMAP

Page Top