私のプラグインはWordPress用のMailer.appです、私は85%完成しています、そして私はリリース前にセキュリティに焦点を合わせています。質問の前に、プラグインアーキテクチャの概要を説明します。
username
とpassword
そして相対的なimap
/smtp
サーバの詳細を取り込むことができます。EKEY
としてclass.client.php
に格納されているCONST
を使用して暗号化されます。password
は暗号化され(imap/smtp
のプレーンテキストとして必要に応じてハッシュすることはできません)、class.client.php.
に格納されているCKEY
を使用してクッキーに格納されます。
データはCookieとユーザーデータの両方を使用して復号化されます。
今WordPressのセキュリティ上の質問に。私は約3年間wpで働いていて、それらについての情報を見つけることについて理解できません。
require("../plugins/mail/class.client.php')
とnew Client()
を呼び出す?もしそうなら、どうすればそれを防ぐことができますか、そしてなぜこれは許されますか?Client
クラスに格納しているときに、他のプラグインがファイルの内容を読み取ることができますか?もしそうなら、このプラグインのClient()
クラスだけがこれにアクセスできるようにそれを保存する場所をお勧めできますか?current_user_can()
とnonces
を使っていますが、これはAJAXに十分なセキュリティを追加するのに十分ですか?ナンスは期限切れになることができますか?また、セキュリティ、Ajax、Webアプリケーションに関するこれらの情報はどこで入手できますか。multisite
は私のシナリオから追加の問題を生み出すことができますか?.私のコードの例を見てみましょう。
class.client.php
final class Client {
const SALT = "bsas8D889b8989sHBsd"; // hash salt
const EKEY = "23123asdas9dsbbad96"; // db encryption key
const CKEY = "b797a78skj15hjhHJDa"; // cookie encryption key
private static function GetUserData(){
return $this->decrypt_data()
}
public static function StoreUserData($data){
return $this->validate_and_store();
}
public static function GetEmails(){
return $this->show_emails($this->GetUserData());
}
}
class.admin.php
final class Admin {
public function __construct(){
add_menu_page('mlr', 'mlr', 'manage_options', 'mlr', array($this,'admin_page'));
}
public function admin_page(){
$user = new Client();
echo $user->GetEmails();
}
}
私の究極の目標は、それが他のプラグインに感染しているか(バックドアなど)、私のEメールのusername
/password
/mail
にアクセスできないということです。暗号化してデータベースに保存したユーザーデータは、Cookieと$key
を使用してのみ復号化できます。 $key
は最も脆弱なアイテムです。
非常に長い投稿ですみませんが、私は私の胸に関するこれらの質問とうまくいけばいくつかの洞察力と助けを得る必要があります。
ありがとう
私の究極の目標は、それが他のプラグインに感染しているか(バックドアなど)、私のEメールの
username
/password
/
これを確実にする唯一の方法は、データベース/ファイルシステムで自動的に復号化できる方法でそれらを格納しないことです。つまり、プレーンテキストまたは自動復号化可能な方法で格納しないでください。
あなた自身のセキュリティソルトとキーをWordPress自身のために設定されたものと連結/ハッシュすることをお勧めします - プラグインを持つ誰かが基本的にあらゆるインストールのためにハッシュされるものにキーを渡されるのであなたは絶対にハードコーディングされたソルトを使うWordPressのインストールに独自のsaltを追加することで、プラグインが脆弱であることがわかった場合は、プラグインの更新がプッシュされたときにsaltを更新し、すべてのインストールの認証情報ストアを無効にできます。個々のインストールが危険にさらされた場合、ユーザーは自分のWordPressソルトを変更し、同様にプラグインを変更せずに彼らの資格情報を無効にすることができます。
他のプラグインは私のプラグインコードにアクセスできますか?例えば
require("../plugins/mail/class.client.php')
とnew Client()
を呼び出す?
はい。
もしそうなら、[...]これはなぜ許されるのでしょうか。
それは解釈されたスクリプト環境の結果であるのでそれほど「許される」わけではありません。テーマとプラグインを使った「WordPressの拡張」はまさにそれです - それは、目的の結果を達成するために生のソースを使用してWordPressの実行を変更することです。私は、ソースコードの一部を同じコードベース内の他の部分から「ロック」するための信頼できるメカニズムを実際に提供するインタプリタ言語を知らない。確かにオペレーティングシステム。
もっと正確に言えば、この責任は実行環境とそれを制御する人にかかっています。
どうすればそれを防ぐことができますか?
非常に複雑なサンドボックスを使用してWordPressのさまざまな部分をさまざまなスレッドで実行することは可能かもしれません - しかし、これはWordPressの設計方法ではまったくなく、起動するのに環境の再設定が必要になります。それでも、Google Chromeのサンドボックス化されたJavaScriptにもかかわらず、依然としてさまざまな攻撃の影響を受けやすいでしょう。
すべての情報セキュリティと同様に、環境が危険にさらされている場合は、セキュリティ対策が実施されているかどうかにかかわらず、環境内およびその上にあるすべてのものも影響を受けることになります。このようなシナリオを念頭に置いて設計されていると、サンドボックス環境のバイナリウイルスや仮想オペレーティングシステムで実行されたバイナリウイルスでさえ、ホストシステムに害を及ぼすためにその境界から抜け出すことができます。
プラグインの利用者がWordPressのインストールを適切に保護したり、危険にさらされたコードをインストールしたりすることに失敗した場合、重要な情報が存在するために「安全」と見なすことができるファイルシステムまたはデータベースの部分はありません。ウイルスが自分のコンピュータに侵入した場合と同じように、プログラムや文書が混乱していない、または未公開であると信頼することはできません。プレーンテキストファイルにパスワードを保存する場合、関連するすべてのアカウントは危険にさらされるか脆弱です。ここでは、ITセキュリティの世界の他の場所と同じように、ユーザーが信頼できない、または理解できない実行可能ファイルをインストールしないでください。信頼できるプログラムまたは適切に実装されたプログラムを区別する適切な基盤がない場合そのようなものを取り付けてください。
手短に言えば、あなた自身があなたのプラグインがインストールされているWordPressのインストールを直接制御していないのであれば、あなたの実装で良いセキュリティプラクティスに従う以上にあなたのプラグインが危殆化されるのを防ぐことはできません。
クライアントクラスに暗号化キーを格納しているときに、他のプラグインがファイルの内容を読み取ることができますか?
はい。実際、どのプラグインでもWordPressインストールのwp-config.php
ファイルを解析し、データベース情報と塩を作者が望むなら入手することができます。問題は、PHPやWordPress環境では、データベースとファイルシステムを自由に管理して目的を達成するためのプラグインをすでに提供しているので、プラグインがインストールを危険にさらす必要さえないということです。データベースとファイルシステム自体が許可します。これらの機能がなければ、プラグインの範囲は極端に制限されます。
もしそうなら、このプラグインのClient()クラスだけがこれにアクセスできるようにそれを保存する場所をお勧めできますか?
プレーンテキストとして保存および/または送信されたクレデンシャルは、完全に「安全」な期間ではありません。
あなたのアプリケーションがそのような保存/転送を必要とするなら、資格情報はそれらが保存されている環境と同じくらい安全になり得ます。信任状を難読化するために追加のフープを追加できますが、コードに信任状を復号化するのに必要なものがすべて揃っている場合は、環境内の他のコードも同様です。それは実行されるとすぐにファイルを復号化するシェルスクリプトと一緒にあなたのコンピュータにパスワードを含む暗号化されたファイルを保存することと本質的に同じです。それらを安全に保つための最善の方法は環境を保護することです。
current_user_can()
とnonceを使っていますが、これはAJAXに十分なセキュリティを追加するのに十分ですか?
それはあなたのアプリケーションの詳細とAJAXを介して送信されているものに依存します。一般的に、これらのメカニズムは正しく実装されていればは validate にAJAX要求が一貫したソースから行われているということで十分です。しかし、それら自体はAJAXセキュリティの構成要素にすぎません。一般的な経験則として:
current-user_can()
、 check_ajax_referer()
の使用を含む、リクエストが「十分に」検証されるまでは、何もしないでください。$_GET
、$_POST
、および$_COOKIE
のデータ、およびデータベースから取得されてPHPとして評価されるか、ブラウザに送信されるものがすべて含まれます。どのWordPress関数があなたに代わってタスクを処理するかを学びましょう - しかし、疑わしい場合は、確実になるまで自分で実行してください。ナンスは期限切れになりますか?
はい - WordPressはこの目的のために nonce_lifetime
フィルタ を提供します。デフォルトでは、WordPressのノンスは12〜24時間有効です。
私のシナリオから、マルチサイトで追加の問題が生じることはありますか?
それはあなたのプラグインがどのようにインストールされているか、そしてあなたがそれをマルチサイト環境で使うことを意図しているかに依存します。
だれがどのメールにアクセスできるかに応じて、メール資格情報をユーザーまたはサイト固有のデータとして保存することができます - メールボックスへのきめ細かいアクセスを提供するためにカスタム role and capabilities を実装したいかもしれません。