Skip to main content

.NETエコシステムで確認された脆弱性の3分の2は、リモートコード実行、クロスサイトスクリプティング、サービス拒否

著者
Headshot of Hayley Denbraver

Hayley Denbraver

2019年7月25日

0 分で読めます

新しいセキュリティレポート「.NETオープンソースのセキュリティに関する分析」をご紹介します。この記事は、次の3つの投稿に分かれています。

丁寧に作成したPDFレポートには、こうした情報をはじめ、さらに多くの内容がまとめられています。無料でダウンロードできます。

Snykが明らかにする.NETエコシステムのセキュリティとは?

最もよく見られる脆弱性を確認したところで、.NETエコシステム全体を俯瞰してみましょう。このエコシステムでは、どのような種類の脆弱性がよく見られるのでしょうか。エコシステム全体で見た場合も、深刻度の高い脆弱性が多い傾向は変わらないのでしょうか。

脆弱性の種類

次の表は、.NETエコシステムで1%以上を占める種類の脆弱性について、その内訳を示しています。Snykの脆弱性データベースで確認された各種類の脆弱性の件数と、全体に占める割合を掲載しています。種類は多岐にわたりますが、確認された脆弱性の大半は、わずか3種類で占められています。リモートコード実行(RCE)、クロスサイトスクリプティング(XSS)、サービス拒否(DoS)の脆弱性は、Snykの脆弱性データベースで確認された.NETの脆弱性の3分の2を占めます。

脆弱性の種類を示す棒グラフ。リモートコード実行が41%で最多、続いてクロスサイトスクリプティングが13.2%、サービス拒否が12.4%。

リモートコード実行(RCE)、クロスサイトスクリプティング(XSS)、サービス拒否(DoS)の脆弱性は、Snykの脆弱性データベースで確認された.NETの脆弱性の3分の2を占めます。

注目すべき脆弱性

.NETエコシステムで最も多く見られる上位3種類の脆弱性について、詳しく知りたい方に向けた概要をご紹介します。

リモートコード実行

リモートコード実行とは、攻撃者がアプリケーション内で任意のコマンドやコードを実行できる脆弱性です。ネットワーク経由でコードが実行されるため、特定の地理的条件には左右されません。関連する脆弱性として、コマンドインジェクションがあります。

「ProcessBuilder()」「exec」「bash」と表示されたコードウィンドウとターミナルコマンドが開いたノートパソコンのイラスト

クロスサイトスクリプティング

クロスサイトスクリプティング攻撃は、攻撃者が正規のWebアプリケーションやサイトをだまして、信頼できる送信元からのリクエストであるかのように受け入れさせる攻撃です。Webアプリケーションのコンテキストを抜け出すことで、アプリケーションはそのデータを検証しないまま、ほかの信頼できる動的コンテンツとともにユーザーへ配信してしまいます。

コードとマスクをかぶったスクリプトが表示されたノートパソコンのイラスト。クロスサイトスクリプティングを表す「<script>」と「document.cookie」の文字が見えます。

サービス拒否

サービス拒否とは、正当なユーザーがシステムを利用できない状態にすることを目的とした攻撃の総称です。ほかの脆弱性とは異なり、DoS攻撃は通常、セキュリティの侵害を目的とするものではありません。正規のユーザーがWebサイトやサービスを利用できない状態にして、サービス停止を引き起こすことを狙います。

ハードドライブ、メモリモジュール、進入禁止マークがネオンの線でつながったアイソメトリックイラスト。サービス拒否攻撃への対策を表しています。

既知の.NET脆弱性は深刻度が高い傾向に

先ほど、最もよく見られる上位20件の脆弱性を調べたところ、その大半は深刻度が高いことがわかりました。Snykのデータベースにある.NETの脆弱性全体でも、この傾向は当てはまるのでしょうか。答えは「はい」です。全体の70.7%を深刻度「高」の脆弱性が占めています。次に多いのは深刻度「中」で、26.9%です。Snykのデータベースにある.NETの脆弱性のうち、深刻度「低」とされるものはわずか2.4%です。

深刻度「高」の脆弱性が全体の70.7%を占め、次に多い深刻度「中」の脆弱性は26.9%です。

.NETのセキュリティ状況は厳しいように見えるかもしれません。深刻度の高い脆弱性が大きな割合を占めています。しかし、本稿執筆時点では、Snykが依存関係スキャンで検出したすべての脆弱性に、修正方法が用意されていました。その理由を確実に断定することはできませんが、.NETエコシステムがMicrosoftのサポートを受けていることも一因かもしれません。

本稿執筆時点では、Snykが依存関係スキャンで検出したすべての脆弱性に、修正方法が用意されていました。

セキュリティの注目ポイント:脆弱性の修正

では、脆弱性を修正するとは、具体的に何をすることなのでしょうか。このセクションでは、そのプロセスを簡単にご説明します。

アップグレード

脆弱性が見つかると、プロジェクトのメンテナーは通常、今後のバージョンに修正を含めます(可能な場合)。ただし、対応までの期間は大きく異なることがあります。セキュリティ脆弱性に適切に対処するには、リリースされた最新バージョンを常に利用するのが一般的に有効です。依存関係同士、また依存関係とコードが相互に作用するため、依存関係のアップグレードが難しい場合もあります。

直接依存と間接依存

直接依存関係の脆弱性は、通常、修正を含む最小バージョンにアップグレードすることで簡単に対処できます。間接依存関係の脆弱性を修正するには、間接依存関係の修正済みバージョンと、その修正済みバージョンを利用する直接依存関係のバージョンの両方が必要です。この2つの条件を満たしていれば、該当する直接依存関係を、間接依存関係の修正済みバージョンを利用するバージョンにアップグレードすることで問題を解決できます。直接依存関係のレベルで修正が提供されていない場合、開発者は間接依存関係をアップグレードして問題を解決できます。ただし、依存関係間の互換性に問題が生じる可能性があります。

まとめ

.NETエコシステムでは、パッケージあたりの脆弱性数は少ないものの、深刻度は高い傾向にあります。つまり、問題の解決にかかる時間は短くて済む可能性がある一方で(投資は小さく)、危険性の高いセキュリティ問題に対処できる(効果は大きい)ということです。言い換えれば、利用している.NETパッケージの既知の脆弱性に対処することは、投資対効果の高いセキュリティ対策です。Snykは、オープンソースを安全に活用できるよう支援することを目指しています。そのため、依存関係に含まれる既知の脆弱性を発見し、自動で修正するツールを開発しています。それと同時に、新たな脆弱性を特定し、適切に開示することも重要です。.NETエコシステムには、オープンソースライブラリの脆弱性を報告するための一元的な窓口が、現在ありません。SnykはCVE採番機関(CNA)であるため、新たな脆弱性にCVE番号(脆弱性を識別するID)を割り当て、関連データベースに登録できます。CNAとして、Snykは責任ある脆弱性報告を支援します。このプロセスについて詳しくは、こちらをご覧ください:https://snyk.io/vulnerability-disclosure。

ありがとうございました。

新しい.NETセキュリティレポートをお読みいただき、ありがとうございました。お楽しみいただけたでしょうか。皆さまがオープンソースを安全に活用できるよう、今後もこのような情報をお届けしていきます。レポート全文は無料でダウンロードできます。

.NETオープンソースのセキュリティに関する分析のレポートをダウンロードする。

続きを読む

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

feature insights context
Blog

予防は、本質的に解決済みの問題なのでしょうか?

エージェントが生成するコードの予防策はアーキテクチャ上解決されていますが、開発を遅らせることなくセキュリティを守る制御を選ぶことが、依然として課題です。

Live Stream

修正エージェントをわかりやすく解説:見つけるより直すことが重要な理由

SnykのRemediation Agentが、セキュリティインテリジェンス、破壊可能性分析、検証を活用して、脆弱性をマージ可能なプルリクエストに変える仕組みをご覧ください。