WordPress プラグインは安全に使用できますか?

公開: 2020-04-16

長年にわたる調査によると、最も人気のある 50 の WordPress プラグインの 20% 以上が、一般的な Web 攻撃に対して脆弱であることがわかっています。さらに、e コマースプラグインを対象とした調査では、最も人気のある 10 の e コマースプラグインのうち 7 つに脆弱性が含まれていることがわかりました。残念ながら、ハッカーは通常、これらの脆弱なアプリケーションを悪用して、健康記録や財務情報などの機密情報にアクセスします。他のケースでは、脆弱性により、ハッカーがサイトを改ざんしたり、攻撃者が制御する他のサイトにリダイレクトしたりできます。

最近の例では、悪意のある WordPress プラグインが、侵害されたサーバーへのアクセスを維持するためだけでなく、暗号通貨のマイニングにも利用されていることが確認されています。したがって、これは WordPress プラグインがどれほど安全であるかという問題を提起します.

このブログでは、潜在的なセキュリティ侵害の原因として WordPress プラグインに焦点を当てます。

プラグインベースの Web 開発。

一般的に言えば、WordPress は Web の 30% 以上を支えているため、世界で最も人気のあるコンテンツ管理システム (CMS) です。

そうは言っても、WordPress の核となる強みは、何万ものプラグインとテーマを幅広く提供することで、サイトをカスタマイズできることです。これらのプラグインは、サイトに連絡フォームを追加することから、SEO 用にブログを最適化すること、さらには Facebook に新しい投稿を自動的に公開することまで、種類と機能が異なります。

サードパーティの開発。

プラグインベースの開発の背後にある主なアイデアは、システムのコア機能を拡張する追加機能を提供することです。基本的に、アプリケーションのコアは通常、長年の開発者のセットによって維持されますが、サードパーティはアプリケーションのコアの周りに多数のプラグインを構築します

このプロセスは、アプリケーションプロバイダーとプラグインプロバイダーの両方にとって有益です。アプリケーションプロバイダーはコア機能により集中でき、プラグインプロバイダーは、アプリケーションのコア機能によって提供されるプラグインのインフラストラクチャを気にする必要がないからです。一般に、WordPress は、何千もの商用およびオープンソースソフトウェアの開発者と愛好家からなるグローバルコミュニティによってもサポートされています。

セキュリティガイドラインなし

全体として、いくつかのコーディング標準と推奨事項のセットは存在しますが、技術的には、プラグイン開発者が厳密に遵守する必要があるセキュリティガイドラインや標準要件はありません。これは、1 つのプラグインの脆弱性が何百万もの Web サイトに伝播する可能性があることを意味します。

また、WordPress は広く使用されているため、攻撃のターゲットとしてよく使われています。したがって、本質的に、プラグインの脆弱性を悪用するハッカーは、何千ものサイトに感染する可能性があります. 多くのブロガーがすでに目撃しているシナリオ。

残念ながら、プラグイン関連の脆弱性も再発する傾向があり、悪用可能で、検出が困難です。したがって、関連するセキュリティの脅威を軽減するために、そのような脆弱性をさらに理解する必要があります。もっと深く掘り下げましょう。

WordPress は本当に安全ですか?

まず最初に、この質問に答えましょう。ほとんどの場合、WordPress のセキュリティのベストプラクティスが守られている限り、生のエコシステムとしての WordPress は非常に安全です。平均して、毎日約 30,000 の新しい Web サイトが Web 上でハッキングされています。これらのハッカーは、プラグインの脆弱性、脆弱なパスワード、および古いソフトウェアのために、WordPress Web サイトを標的にする傾向があります。したがって、最高のセキュリティを実現するには、ある程度の意図が必要です。つまり、いくつかの基本的な WordPress セキュリティのベストプラクティスに従って、攻撃に対する脆弱性を減らします。

続きを読む: 高トラフィック向けに WordPress Web サイトをスケールアップする 11 の効果的な方法

これらの脆弱性はどこから来るのですか?

wpscan.org による最近のレポートによると、WordPress には約 4,000 の既知のセキュリティ脆弱性があることが明らかになりました。これらの脆弱性の大半は、プラグインが原因でした。これらのプラグイン関連の脆弱性の一部は重大な結果をもたらす可能性がありますが、多くは修正されるまで何年も気付かれないままです. ほとんどの場合、それらは通常、ソースコードに小さなローカライズされた変更を加えることで修正できます。

ただし、先に進む前に、一歩下がってみましょう。

プラグインとは?

基本的に、プラグインは、新しいカスタム調整された機能と動作でアプリケーションを補完するソフトウェア拡張です。特に、WordPress は何千ものプラグイン (52,000 以上) を提供しており、これらは何千ものカスタマイズされた Web アプリケーションの構築に使用されてきました。

プラグインベースの Web アプリケーションがより主流になったため、多くの開発者が、最先端の機能を備えたさまざまなプラグインを作成、構成、および拡張することにより、Web アプリケーションを再考する可能性を探ることに注意を向けました。

プラグイン開発の意味

そうは言っても、プラグインを利用して追加機能やカスタム機能を使用して Web システムを拡張できることは、開発者にとってプラスとマイナスの両方の影響を及ぼします。まず、良い点として、通常は複数のカスタマイズオプションから選択できるため、開発者はユーザーのニーズに合わせてカスタマイズされた Web アプリケーションをすばやく簡単に構築できます。したがって、迅速なプロトタイピングと開発が容易になります。

ただし、マイナス面として、Web アプリケーションは、さまざまなソースからの複数のプラグインの複雑な構成になる可能性があります。最終的には、プラグインのセキュリティに関連する懸念が生じます。たとえば、何百万もの WordPress ベースのアプリケーションで採用されているプラグインである TimThumb は、攻撃者が意図的にリモートコードを実行できるエクスプロイトに対して無防備であると報告されています。

実際のところ、米国の National Vulnerability Database (NVD) によると、Web システムの脆弱性の約 15% が重大であると見なすことができ、そのうちの約 35% は簡単に悪用できる脆弱性です。

侵害されたプラグインの結果は何ですか?

ユーザーが財務情報を失ったり、健康記録が危険にさらされたりすることは別として、脆弱性が深刻であるほど、ソフトウェア企業への経済的影響は大きくなります。さらに、開発者が開示時に実行可能なパスをリリースできなかった場合、これはさらに悪化します。したがって、プラグインベンダーは通常、より安全なアプリケーションの作成に努めています。

プラグインに通常見られるセキュリティの脆弱性をいくつか調べて、その結果と意味をより広く理解しましょう。

セキュリティの脆弱性

私たちが収集したように、脆弱性はソフトウェアシステムの潜在的な悪用の機会を開きます。最終的に、WordPress では世界中の何百万人もの開発者が独自のプラグインを作成できるため、プラグインで一定レベルの侵害が発生することを期待しないのは非現実的です.

その結果、コアシステムとの予期しないプラグインの相互作用によってセキュリティが侵害される可能性があり、攻撃者によって潜在的に悪用される可能性のある脆弱性につながります。これは、Web システムのセキュリティは、コアシステムとプラグインの両方の脆弱性をチェックすることにかかっていることを意味します。

WordPress の複雑さ

WordPress は複雑なため、脆弱性に悩まされる傾向があります。たとえば、WordPress は、共有されたグローバル状態を変更したり、システムコアの実行の特定の時点で関数を実行したりすることで、プラグインが新しい機能を提供できる直感的なインフラストラクチャを提供します。その結果、プラグインが悪意のある入力データを適切なサニタイズまたは入力検証なしでコアコンポーネントに送信すると、プラグインの脆弱性が発生する可能性があります。

プラグインの脆弱性の例

最終的に、最も一般的なプラグインの脆弱性は、クロスサイトスクリプティング、SQL インジェクション、およびクロスサイトリクエストフォージェリです。全体として、攻撃者が簡単に悪用できる最も危険な脆弱性のタイプは、SQL インジェクションです。ただし、その他の脆弱性、違反および侵害の原因は存在します。

データ処理エラー
不適切な入力検証
情報漏えい
パストラバーサル
セキュリティ機能
アクセス制御
不適切なアクセス制御
不適切な承認
不適切な認証
クロスサイトリクエストフォージェリ
ファイルの無制限アップロード
外部からアクセス可能なファイル
リンクフォロー
リダイレクトを開く
コマンドインジェクション
OS コマンドインジェクション
クロスサイトスクリプティング
SQL インジェクション
コードインジェクション

詳細なコンテキストについては、最も一般的な攻撃と脆弱性を調べてみましょう。

· SQL インジェクション: SQL インジェクションは通常、攻撃者がユーザーの WordPress データベースとその Web サイトのすべてのデータにアクセスしたときに発生します。 SQL インジェクションは、悪意のある Web サイトやスパム Web サイトへのリンクなど、新しいデータをデータベースに挿入するためにも使用できます。

SQL インジェクションにより、機密情報の抽出など、バックエンドサーバーでのコマンドの実行が可能になります。ホスト環境では、脆弱性のないサイトに対する攻撃の足がかりとして、SQL インジェクション攻撃がさらに使用される可能性があります。

·クロスサイトスクリプティング:この攻撃により、クライアントでスクリプトを実行して、アクセス制御を回避することができます。通常、サイトへのすべての訪問者を対象としています。ホスト環境では、このような攻撃を使用してサイト管理者のセッション Cookie を盗み、攻撃者が管理者になりすますことができます。

·クロスサイトリクエストフォージェリ:この脆弱性により、ハッカーは被害者に代わってアプリケーションレベルのトランザクションを実行できます。ホスト環境では、攻撃者が管理者に代わってサイトにログオンし、ユーザーのリダイレクトや管理トランザクションの実行などの悪意のあるアクティビティを実行できます。

WordPress プラグインでよく見られるクロスサイトスクリプティングの脆弱性は、次のような方法で機能します。攻撃者は、被害者に安全でない JavaScript スクリプトを含む Web ページを読み込ませる方法を見つけます。

ほとんどの脆弱性はどこに現れますか?

技術調査では、ほとんどの脆弱性 (約 92%) がプラグインコードに現れることが発見されました。さらに、結果によると、クロスサイトスクリプティングやクロスサイトリクエストフォージェリなどの脆弱性はプラグインコードでより一般的であり、他の脆弱性はコアコードでより一般的でした。関連して、この調査では、プラグインの品質がさまざまであり、プラグインの評価とプラグインで見つかった脆弱性の数との間に相関関係がないことが明らかになりました。

PHP コード作成プロセス

コード作成プロセスは、脆弱性や侵害の原因となる可能性があります。一般的に言えば、PHP は、ホストオペレーティングシステムを直接起動することなく、サーバー側で任意のコードの実行をサポートすることでよく知られています。とはいえ、開発者がコード作成プロセスを怠ると、クロスサイトスクリプティングの脆弱性がプラグインコードに導入される可能性が高まります。

一方、SQL インジェクションに関しては、簡単に検出して悪用できるため、一般的な脆弱性です。皮肉なことに、ユーザーベースが小さい Web サイトでも、SQL インジェクションの攻撃を受ける可能性があります。

脆弱性への暴露の一部は、開発者が安全でないリソースを使用することに起因します。同様に、最近開発されたプラグインの多くはそれほど熟練していない開発者によって作成されているため、適切な入力検証は依然としてプラグイン開発者にとって大きな課題です。

WordPress プラグインによる脆弱性は重大ですか?

全てを考慮に入れると; 脆弱性は、いくつかの方法で Web システムに悪影響を与える可能性があります。たとえば、脆弱性の悪用に成功すると、機密性が完全に失われる可能性がありますが、可用性は失われません。

前述のとおり、SQL インジェクションは最も危険な脆弱性タイプのようですが、システムの完全性、可用性、機密性に部分的にしか影響しません。ただし、このような脆弱性により、攻撃者がファイルや情報に無制限にアクセスできるようになる可能性があります。

そのため、うっかりして、脆弱性の大半はデータ侵害につながる可能性がありますが、いくつかの脆弱性は必ずしも Web アプリケーションを深刻なセキュリティリスクにさらすわけではありません。いずれにせよ、そのようなオッズでチャンスをつかむことを避けることが重要です。

WordPress プラグインのコードの脆弱性は、どのくらい存続できますか?

通常、コード内の脆弱性は、セキュリティの脅威を修正するパッチがリリースされるまで、導入から開示まで、さまざまな状態を通過する傾向があります。

通常、脆弱性は、発見者がセキュリティ脅威の詳細をより多くの聴衆に明らかにしたときに開示されます。最終的に、開発者が根本的なセキュリティの脅威を修正するパッチをリリースすると、脆弱性は修正されます。ただし、特定されて修正されるまで、Web アプリケーションの脆弱性が何年も気付かれないことがあります。

考えられる軽減策と検出方法

ほとんどの人が言うように、予防は治療に勝ります。したがって、プラグイン開発者がクロスサイトスクリプティング、SQL インジェクション、およびクロスサイトリクエストフォージェリを完全に理解し、検出し、排除できれば、プラグインの脆弱性が 75% 減少する可能性があります。

ただし、攻撃者が悪用できる脆弱性はこれら 3 つの脆弱性だけではないことに注意してください。むしろ、最も一般的な脆弱性です。

したがって、これらの提案された緩和戦略は、特定のプラグインが完全に安全であることを保証するものではありませんが、脆弱性を防止するための優れた原則を設定しています. 例えば：

データがどのように使用され、WordPress のコア部分で期待されるエンコーディングを理解します。この場合、開発者は常にすべての入力を悪意のあるものと見なし、必要なエンコーディングパターンに厳密に準拠していない入力を拒否するか、有効な入力に変換する必要があります。
データベースを SQL インジェクションから保護するために、開発者は、コードをデータ操作から分離して、パラメーター化された SQL ステートメントを使用する必要があります。また、常にヘッダーをチェックして、リクエストが同じオリジンからのものかどうかを確認してください。さらに、認証されていない攻撃者にデータを公開しないようにすることも役立つ場合があります。
状態の変更をトリガーするすべてのリクエストに対して GET メソッドを使用しないことをお勧めします。

脆弱性の検出

残念ながら、最も一般的なコードの弱点を 100% の精度とカバレッジで検出する一貫した方法はありません。残念ながら、データフロー分析を使用してクロスサイトスクリプティングを検出する最新の手法でさえ、誤検出を引き起こすことがあります。

対照的に、コードレビューなどの手動分析方法は、特に設計に関連する脆弱性に対して、完全に自動化された方法よりも効果的である傾向があります。たとえば、クロスサイトリクエストフォージェリは、自動化された方法を使用して確実に検出することは特に困難です。これは、アプリケーションごとに独自のセキュリティポリシーと、ユーザーがリクエストを行うつもりであるという強い信頼を必要とするリクエストを示す方法があるためです。

ただし一方で、手動分析は SQL インジェクションの発見に役立ちますが、限られた時間の制約内で目的のコードカバレッジを達成できない可能性があります。攻撃対象領域が非常に大きくなる可能性があるため、すべての入力に対して考慮しなければならない弱点については、これが困難になる可能性があります。

その結果、一部の組織は、Web システム開発プロセスのすべてのフェーズを網羅する手動レビューと自動分析の両方を含むバランスのとれたアプローチの重要性を強調しています。

WordPress アプリケーションを保護するためのベストプラクティス

WordPress.org などの信頼できるソースからのみプラグインをダウンロードしてください:誰でも WordPress プラグインを開発できるため、ハッカーはこの脆弱性を悪用して悪意のあるプラグインを隠していることで有名です。評判の良いマーケットプレイスは、無害なプラグインへのアクセスを完全に保証するわけではありませんが、緩和策として推奨されます。
すべてのプラグインが最新であることを常に確認してください:通常、WordPress ユーザーは通知メールを受け取りますが、無視することがよくあります。プラグインが自動的に更新されるように設定するか、少なくとも自分で手動でアップグレードしてください。
セキュリティの問題をスキャンして、プラグインのセキュリティ体制を確認します。ほとんどのプラグインはオープンソースです。つまり、ソースコードが利用可能です。そのため、プラグインの「健康保険証」を提供する静的ソースコード分析ツールを必ず使用してください。一部の高度なスキャナーは、最適かつ迅速な修正の推奨事項を示すことさえできます.
未使用のプラグインをすべて削除する:残念ながら、古い未使用のプラグインのコードは通常、プラグインが非アクティブであってもサーバーに残ります。そのため、WordPress サイトのメンテナンスの一環として、使用していないプラグインを常に削除してください。

プラグイン開発者への推奨事項

プラグインの開発中に常にセキュリティを組み込む:脆弱性は、後で修正するためのコストが高くなるため、安全なソフトウェア開発ライフサイクル (SDLC) プロセスの一部として、常にプラグイン開発内にセキュリティを統合します。
プラグインをコードスキャナーで実行して、最新のセキュリティ基準に対応していることを確認します。 開発中およびリリース前に、包括的なソースコード分析テストを実施するようにしてください。

安全なプラグインの開発

すでに述べたように、プラグイン開発者は安全なコードを書くよう努力する必要があります。残念なことに、多くの開発者はまだ熟練していないため、その方法を知りません。特に、上で引用した最も一般的な脆弱性の性質を考えると、多くの開発者が、一般的な攻撃、使用する言語とプラットフォームによって提供されるセキュリティ機能、および適用可能なプラクティスを使用してセキュリティの問題を軽減する方法を理解していないことは明らかです.

したがって、Creole Studios では、プラグイン開発者に合わせて新しい方法論を開発することをお勧めします。開発者はソフトウェアセキュリティの最も重要なエンティティであるため、このような方法論は、要件および設計段階でセキュリティを促進する必要があります。

最終的な考え

トピックを要約すると、WordPress プラグインは侵害される可能性があり、最も一般的な脆弱性はクロスサイトスクリプティング、SQL インジェクション、およびクロスサイトリクエストフォージェリです。

残念ながら、調査によると、これらの脆弱性が発生する頻度は時間の経過とともに低下しているようには見えません。これの主な理由は、ほとんどの WordPress プラグイン開発者が安全なプログラミングに関していくらか未熟であることにあると考えて間違いありません.

そうは言っても、防衛の最前線は開発チームであるべきです！また、最善のセキュリティプラクティスが実施されると、ユーザーはサイバー犯罪者から保護されていることを認識して、夜はぐっすり眠ることができると信じています。

WordPress のセキュリティ対策の詳細については、お気軽にご相談ください。