web-dev-qa-db-ja.com

OWASP-2013トップ10番号A9に関するコメントまたはアドバイス

このOWASPトップ10アプリケーションセキュリティ脆弱性リストの反復（ https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project ）では、新しいカテゴリ「A9既知の脆弱性を持つコンポーネントの使用」導入されました。これは、コンプライアンスを保証するために、すべてのライブラリとインポートされたコードをアプリケーションで調査する必要があるようです。

PCI-DSS監査要件のために、OWASPトップ10を使用して、クレジットカードの支払いを処理するように記述されたコードベースの部分に対して、独自のソフトウェアプラットフォームのセキュリティを確保するクライアントがたくさんいます。この新しい一連の要件により、インポートされたすべてのライブラリ（あるインスタンスではCPANからのPerlモジュール、別のインスタンスではJava libs））を検索/一覧表示し、それらを実行する必要があるように見えます行ごと-おそらく何百万行もの誰かのコード！.

これは実用的ではないか、おそらく非常に便利です。 OWASPは、独自のアプリケーションを作成し、共通ライブラリをインポートする組織が、すべてのサードパーティライブラリコードを確認する必要があることを真剣に示唆しているのでしょうか。

他の誰かがこの問題に遭遇したことがありますか？私はこれにどのように対処できると思いますか？

complianceauditowasp
18
David Scholefield

アプリケーションのセキュリティの正式なレビューでは、すべてのライブラリでセキュリティの欠陥を調査する必要があります。しかし、これはOWASP-2013 A9のポイントではありません。 OWASP-2013 A9の中核は、過失によってアプリケーションが侵害されないようにするポリシーを整備することです。 OWASPは次のよ​​うに述べています。

  1. すべての依存関係を含め、使用しているすべてのコンポーネントとバージョンを特定します。 （バージョンプラグインなど）。
  2. パブリックデータベース、プロジェクトメーリングリスト、セキュリティメーリングリストでこれらのコンポーネントのセキュリティを監視し、最新の状態に保ちます。
  3. 特定のソフトウェア開発プラクティスの要求、セキュリティテストの合格、許容可能なライセンスなど、コンポーネントの使用を管理するセキュリティポリシーを確立します。
  4. 必要に応じて、コンポーネントの周りにセキュリティラッパーを追加して、未使用の機能を無効にしたり、コンポーネントの脆弱な側面や脆弱な側面を保護したりします。

番号2が最も重要です。ライブラリまたはプラットフォームに依存している場合は、これらのコンポーネントを定期的に更新する必要があります。内部的には、すべてのコンポーネントとバージョンを確認し、これらが完全に更新されるようにするサイクルが必要です。これらのコンポーネントを確認する月次サイクルが理想的です。

簡単に言えば、4はuntrustedライブラリへの入力の強力な検証を必要としています。ライブラリのセキュリティ欠陥が完全にテストされていない場合は、このライブラリに渡されるデータを検証する必要があります。これは、すべての入力に対してこれを行う非常に優れたセキュリティプラクティスです。この例では、すべての入力に OWASP ESAPI検証ルーチン を使用しています。したがって、メールアドレスの場合は、メールアドレスの正規表現と一致する必要があります。

27
rook

監査人の観点からは、使用済みライブラリーのコードの1行ごとを通過することは期待していません[〜＃〜] if [〜＃〜]ライブラリーは一般的に使用され、吟味されています。トランザクションシステムに「インターネットで見つけたランダムコード」を使用している場合は、コードのレビューがあったはずです。

次に、よりよく使用され、吟味されたライブラリについて、ライブラリのバージョンを確認し、既知の脆弱性があるかどうかを確認します。少なくともすべてのセキュリティアップデートで定期的にライブラリを更新する必要があります。

この問題に利用できるセキュリティアップデートがない場合は、次のことを行うためのアクションプランを用意する必要があります。

  • 悪用が発生したかどうかを監視します（場合によっては、セキュリティアップデートが使用されていないコンポーネント用である可能性があります）
  • リスクの軽減（コンポーネントの無効化またはWAV/IPSの変更）
4
Lucas Kauffman

Rookはあなたの質問に素晴らしい答えを提供しました。そして、すべてのコンポーネントのコードをレビューするよりも、パブリックデータベースやその他の手段を使用してコンポーネントを監視する方が確かに簡単ですが、それでもまだ大きな仕事です。どうして？現在、アプリケーションは主にコンポーネントで構成されているため、平均的なアプリケーションは80％以上のオープンソースコンポーネントで構成されていることが調査で示されています。また、アプリケーションに取り込むコンポーネントだけでなく、他のすべての依存コンポーネントも含まれます。量、種類、リリースの頻度（多くのプロジェクトは年に4回更新される）を考えると、何らかの形の自動化が必要です。

DASTやSASTなどの既存のアプリケーションセキュリティテクノロジーは、別の問題用に設計されています。これらのコンポーネントは、コンポーネントを接着するカスタムコードに重点を置いています。継続するには別のアプローチが必要です。これは、ライフサイクル全体を管理するアプローチと、開発サイクルの後半に配信される特定時点のスキャンです。

OWASP A9および新しいPCI 3.0コンポーネント要件の背景をさらに詳しく説明する2つのホワイトペーパーが利用可能です。さらに、金融サービス会社であるCrosskeyからの情報を含む、このトピックに関するウェビナーも利用できます。

http://www.sonatype.com/resources

ありがとう、Mark Troester Sonatype @mtroester

0
user34678