OWASPトップ10を使用してWordPressのセキュリティを向上させる
公開: 2018-08-23WordPressのセキュリティは、WordPressを初めて使用する人や、Webサイトを持っている人にとっては恐ろしいものになる可能性があります。 ただし、OWASPトップ10リストビジネスなどのコンプライアンスと標準を使用すると、WordPressのセキュリティを簡単に開始できます。
この記事では、OWASPトップ10リストとは何かについて説明します。 また、WordPressサイト管理者がOwaspトップ10準拠のWordPressWebサイトを作成する方法についても説明します。
OWASPトップ10リストとは何ですか？
OWASPトップ10は、Webアプリケーションのセキュリティに関する最も重大な10のリスクのリストです。 そのため、それ自体はコンプライアンス標準ではありませんが、多くの組織がガイドラインとして使用しています。 Open Web Application Security Project（OWASP）組織は、2003年に最初のリストを公開しました。現在、3年ごとに更新されたリストをリリースしています。
OWASPのトップ10の脆弱性とセキュリティリスクはどれですか？
OWASPは、2017年に最新のOWASPトップ10リストを公開しました。以下は、その中のセキュリティリスクのリストです。
A1：注射
A2：認証の失敗
A3：機密データの公開
A4：XML外部エンティティ
A5：壊れたアクセス制御
A6：セキュリティの設定ミス
A7：クロスサイトスクリプティング（XSS）
A8：安全でないデシリアライズ
A9：既知の脆弱性を持つコンポーネントの使用
A10：不十分なロギングとモニタリング
WordPressにOWASPトップ10セキュリティを適用する
このセクションでは、WordPressWebサイトがOWASPトップ10の脆弱性やセキュリティ上の欠陥のいずれに対しても脆弱でないようにするために必要なことを説明します。
A1への対処：WordPressでのインジェクション
SQLインジェクションは、ユーザー入力のサニタイズの欠如によって通常引き起こされる技術的なアプリケーションの脆弱性です。 これを悪用することで、悪意のあるハッカーはWordPressデータベースのデータにアクセスできます。
WordPressコアチームは通常、数日以内にインジェクションの脆弱性を修正します。 同じことがほとんどのWordPressプラグイン開発者にも当てはまります。 したがって、レスポンシブ開発者によって開発された、適切に保守されたプラグインを常に使用することが重要である理由。
WordPressコア、プラグイン、テーマがこのタイプの脆弱性に対して脆弱でないことを確認する唯一の方法は、すべてのソフトウェアを最新の状態に保つことです。 開発者がリリースするすべてのセキュリティパッチを常にインストールしてください。
A2への対処：WordPressでの認証の失敗
これらのタイプのセキュリティ上の欠陥は、技術的な脆弱性でもあります。 これらの脆弱性は、Webアプリケーションの設計が壊れていて、計画が不足していることが原因です。 攻撃者は、壊れた認証の問題を悪用して機密データにアクセスできます。
これらの問題に対処できるのは開発者だけです。 最新バージョンのWordPressコアとプラグインを使用している限り、Webサイトにこのような脆弱性が発生することはありません。 もちろん、常に手入れの行き届いたプラグインを使用していると仮定します。
認証について話しているので、WordPressWebサイトに2要素認証を実装することを忘れないでください。 使用するプラグインがわからない場合は、ここにいくつかの最高の2要素認証WordPressプラグインのリストがあります。
A3への対応：WordPressでの機密データの公開
GDPRによると、機密データと個人データは、識別可能なユーザーに関連するすべてのデータです。 これは、eコマースWebサイトの場合、顧客の名前、請求の詳細、およびカード会員データである可能性があります。 金融サービスの場合は銀行口座の詳細である可能性があり、ヘルスケアの場合は病歴である可能性があります。 IPアドレスを機密データとして分類できる場合でも、WordPressアクティビティログを保持できることに注意してください。これにより、Webサイトで発生しているすべてのことを追跡できます。
WordPress Webサイトに準拠するために、WordPress Webサイトに機密データを保存する場合は、データを使用する必要があるユーザーのみがアクセスできるようにしてください。もちろん、データは暗号化する必要があります。 常にWordPressのユーザーと役割を使用して、ユーザーの特権と機密データへのアクセスをより適切に管理します。
WordPress Webサイトに機密データを保存する必要がありますか？
決定的な答えはありません。 それはすべてセットアップとリソースに依存します。 ただし、中小企業は通常、サードパーティプロバイダーにデータを保存する方がよいでしょう。
たとえば、eコマースストアの場合、StripeやPayPalなどの支払いシステムを使用してカード会員データを処理および保存する方がはるかに簡単です。 彼らはすでにインフラを整備しています。 安全なeコマースサイトを維持および実行する方法の詳細については、WordPress管理者向けのeコマースセキュリティに関するガイドを参照してください。
同じことが顧客の電子メールアドレスとニュースレターリストにも当てはまります。 理想的には、そのようなデータをWebサイトに保存しないでください。 Mailchimpなどのサードパーティサービスを使用して、WordPress Webサイトではなく、より安全で信頼性の高いインフラストラクチャにデータを保存します。
A4への対応：WordPressのXML外部エンティティ（XXE）
これは技術的なソフトウェアの脆弱性です。 これは、アプリケーションがXMLファイルとデータを誤って処理する場合に発生します。 すぐに使用できるWordPressのインストールでは、リモートXMLファイルをあまり処理しませんが、処理するプラグインを使用する場合があります。
WordPress Webサイトがこのようなタイプの脆弱性に対して脆弱でないことを確認するには、最新バージョンのWordPressコア、プラグイン、およびその他のソフトウェアを使用してください。 常に維持されているプラグインを使用してください。 使用しているプラグインのうち、1年以上更新されていないものを変更することを検討してください。
A5への対処：WordPressの壊れたアクセス制御
これは技術的なアプリケーションの脆弱性です。 この問題は、アプリケーションが認証されたユーザーに必要な制限を適用しない場合に発生します。 したがって、攻撃者がそのような脆弱性を悪用すると、機密データにアクセスできます。
このタイプの問題を修正できるのは開発者だけです。 Webサイトが脆弱でないことを確認するには、Webサイトで使用するWordPressコア、プラグイン、およびその他のソフトウェアを最新の状態に保ちます。
A6への対処：WordPressWebサイトのセキュリティ設定ミス
セキュリティの設定ミスは、WordPressWebサイトで非常に一般的です。 パッチが適用されていないソフトウェアとデフォルトの悪用は、WordPressWebサイトで最も一般的に成功する攻撃の2つです。 過去数年間、WordPressコアチームはユーザーがそのような問題に対処するのを助けるために多くのことをしました。 たとえば、WordPressには、多くのWordPressハッキングの原因であったデフォルトの管理者ユーザー名がなくなりました。
WordPress Webサイトにセキュリティの設定ミスがないことを確認するには、すべてのデフォルトを変更します。 これは、WordPress、プラグイン、および使用するその他のソフトウェアとデバイスに適用されます。 たとえば、プラグインにデフォルトの資格情報のセットがある場合、機密データをパスワードで保護しない場合、またはデフォルトの場所に保存する場合は、強力な認証を構成し、デフォルトのパスを変更します。 これは、インターネットホームルーターを含む、使用する他のすべてのソフトウェアとデバイスに適用されます。これには通常、デフォルトの資格情報があります。
A7への対応：WordPressのクロスサイトスクリプティング（XSS）
XSSとも呼ばれるクロスサイトスクリプティングは、技術的なアプリケーションの脆弱性です。 これはおそらく最も一般的な技術的脆弱性の1つです。 XSSの脆弱性は、信頼できないデータが検証およびエスケープされていない場合に発生します。 悪意のある攻撃者がクロスサイトスクリプティングの脆弱性を悪用すると、ログインしているユーザーのCookieを盗み、偽装する可能性があります。 また、セッションを乗っ取ることができます。
WordPressコアチームは通常、わずか数日でコアで報告されたXSSの問題に対処します。 したがって、WordPress Webサイトのコア、プラグイン、およびテーマがこのタイプの脆弱性に対して脆弱でないことを確認するには、常に最新バージョンのソフトウェアを使用してください。 また、常に保守されているプラグインを使用してください。
A8への対処：WordPressでの安全でないデシリアライズ
安全でないデシリアライズは、技術的なアプリケーションの脆弱性です。 この脆弱性は、アプリケーションが整合性チェックを行わずに信頼できないソースからのシリアル化されたオブジェクトを使用する場合に発生する可能性があります。
WordPressコアチームは通常、このタイプの問題に数日以内に対処します。 したがって、WordPress Webサイトのコア、プラグイン、およびテーマがこのタイプの脆弱性に対して脆弱でないことを確認するには、常に最新バージョンのソフトウェアを使用してください。
A9への対処：WordPressWebサイトで既知の脆弱性を持つコンポーネントを使用する
既知の脆弱性があるソフトウェアやWebアプリケーションを使用しないことは、明らかなことのように聞こえるかもしれません。 残念ながらそうではありませんが。 WordPress財団は、この点で多くのことを行ってきました。 WordPressコアの自動更新があります。 WordPressプラグインレビューチームは、しばらくの間更新されていないリポジトリ上のプラグインに安全でないタグを付けます。
ただし、企業がソフトウェアの最新かつ最も安全なバージョンを使用することは必ずしも容易ではありません。 多くの場合、最新バージョンのWordPressやその他のプラグインと互換性のないレガシーソフトウェアやWebアプリケーションを使用しています。 そのため、古くて脆弱なバージョンのWordPressとプラグインを使用する必要があります。 このような場合、可能であれば開発者に連絡してコードを更新してください。
ウェブサイトが準拠していることを確認するために、これは言うまでもありません。常に最新バージョンのWordPressコアとプラグインを使用してください。 また、未使用のプラグイン、スクリプト、テーマをWebサイトから非アクティブ化してアンインストールすることも重要です。 たとえば、多くのサイト管理者はデフォルトのWordPressテーマとプラグインを削除しません。 使用しない場合は削除してください。
これは新しいソフトウェアにも当てはまります。新しいプラグインを探すときは、常にそれを調べてください。 新しいWordPressプラグインを探すときに何をすべきかについての詳細は、WordPressプラグインの選択方法に関するガイドをお読みください。
A10への対処：WordPressでの不十分なロギングとモニタリング
ロギングとモニタリングは、WordPressWebサイトとマルチサイトネットワークのセキュリティにとって不可欠です。 WordPressのアクティビティログは、Webサイトの管理の改善、問題が発生する前の疑わしい動作の特定、ユーザーの生産性の確保などにも役立ちます。 WordPressアクティビティログ（監査ログ）を保持する利点の詳細をご覧ください。
WordPress Webサイトが準拠していることを確認するには、最も包括的なWordPressアクティビティログプラグインであるWPセキュリティ監査ログをインストールします。 WordPressWebサイトとマルチサイトネットワークで発生したすべての記録をアクティビティログに保持します。 OWASPトップ10リストのこの部分に対処する方法の詳細については、WordPressアクティビティログプラグインを使用して不十分なログに対処するを参照してください。
OWASPトップ10を使用してOWASP準拠のWordPressWebサイトを構築する
WordPressのセキュリティは、特に大規模なセットアップを扱う場合、複雑になる可能性があります。 この記事で強調しているように、始めて基本をカバーすることはそれほど難しくありません。 次の基本事項に注意することで、OWASPトップ10に準拠したWordPressWebサイトを作成できます。
- WordPressコア、プラグイン、テーマの最新バージョンを使用し、
- WordPressコアとプラグインのデフォルトをすべて変更してください。
- 強力なパスワードポリシーを適用し、
- 2要素認証のWordPressプラグインで2FAを有効にします。
- WordPressのユーザーと役割を適切に使用し、
- あなたのウェブサイトで起こったすべてのことをWordPressアクティビティログに記録してください。
このOWASPトップ10リストをガイドとして使用して、WordPressWebサイトのセキュリティを強化してください。 詳細については、OWASPトップ10の公式ページを参照してください。