Mein Plugin ist Mailer.app für WordPress, ich bin zu 85% fertig und ich konzentriere mich auf die Sicherheit vor der Veröffentlichung. Vor den Fragen sollte ich die Plugins-Architektur skizzieren:
username und password und relative imap / imap . EKEY + E-Mail werden mit dem in der class.client.php als CONST gespeicherten class.client.php verschlüsselt Das password ist verschlüsselt (kann bei Bedarf nicht als imap/smtp Text für imap/smtp gehasht werden) und wird in einem Cookie mit einem in der class.client.php. gespeicherten CKEY gespeichert class.client.php.
Die Daten werden sowohl mit dem Cookie als auch mit den Benutzerdaten entschlüsselt.
Jetzt zu den Sicherheitsfragen von WordPress. Ich arbeite seit 3 Jahren mit WP und kann diese nicht verstehen, um irgendwelche Informationen über sie zu finden:
require("../plugins/mail/class.client.php') und call new Client() ? Wenn ja, wie verhindere ich das und warum ist das erlaubt? Client speichere? Wenn ja, können Sie einen Platz zum Speichern empfehlen, so dass nur die Client() -class dieses Plugins darauf zugreifen kann? current_user_can() und nonces aber reicht das, um AJAX genügend Sicherheit zu geben? Können Nonces abgelaufen sein? und wo lese ich mehr über sie in Bezug auf Sicherheit, Ajax und Web-Apps. multisite irgendwelche Zusatzprobleme von meinem Szenario verursachen? Schauen wir uns ein Beispiel für meinen Code an:
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(); } }
Was mein ultimatives Ziel ist, andere Plugins, die infiziert sind (Backdoor usw.) oder nicht, können nicht auf den username / das password / die mail meiner Email zugreifen, das ist der Hauptteil der Frage. Die Benutzerdaten, die verschlüsselt und in der database gespeichert wurden, können nur mithilfe von Cookie und $key entschlüsselt werden. $key ist der anfällige Gegenstand.
Sorry für den extra langen Post, aber ich muss diese Fragen meiner Brust und hoffentlich einige Einblicke und Hilfe bekommen.
Vielen Dank
Was mein ultimatives Ziel ist, andere Plugins, die infiziert sind (Backdoor usw.) oder nicht, können nicht auf den
username/ daspassword/ die
Die einzige Möglichkeit, dies sicherzustellen, besteht darin, sie nicht in einer Weise zu speichern, die automatisch in der database / dem Dateisystem entschlüsselt werden kann – das heißt, sie nicht im Klartext oder überhaupt automatisch entschlüsselbar zu speichern.
Ich würde empfehlen, Ihre eigenen Sicherheitssalze und -schlüssel mit denen zu kombinieren, die für WordPress selbst konfiguriert sind – Sie sollten niemals ein Plugin verteilen, das hartcodierte Salze verwendet, da jeder mit dem Plugin im Grunde die Schlüssel zu dem bekommt, was für jede Installation hasiert wurde. Wenn Sie bei der Installation der WordPress-Installation feststellen, dass Ihr Plug-in verwundbar ist, können Sie die Salze aktualisieren und die Anmeldeinformationsspeicher aller Installationen ungültig machen, wenn das Plugin-Update durchgeführt wird. Wenn eine einzelne Installation kompromittiert wird, kann ein Benutzer seine WordPress-Salze ändern und ebenfalls ihre Anmeldeinformationen ungültig machen, ohne das Plugin zu ändern.
Können andere Plugins auf meinen Plugin-Code zugreifen? zB
require("../plugins/mail/class.client.php')undnew Client()aufrufen?
Ja.
Wenn ja, […] warum ist das erlaubt?
Es ist nicht “erlaubt”, sondern ist eine Folge von interpretierten Skriptumgebungen. “Erweitern von WordPress” mit Themes und Plugins ist genau das. Es ändert die Ausführung von WordPress mit roher Quelle, um das gewünschte Ergebnis zu erzielen. Ich kenne keine interpretierte Sprache, die tatsächlich zuverlässige Mechanismen bietet, um Teile des Quellskripts von anderen Teilen derselben Codebasis zu “sperren”. Betriebssysteme, sicher.
Vielmehr fällt diese Verantwortung auf die Ausführungsumgebung und auf den, der sie kontrolliert.
Wie verhindere ich das?
Es kann möglich sein, einige sehr komplexe Sandboxing zu verwenden und verschiedene Teile von WordPress in verschiedenen Threads auszuführen – aber das ist nicht so, wie WordPress entworfen wurde, und würde eine Neukonfiguration der schweren Umgebung erfordern. Selbst dann wäre es immer noch anfällig für eine Vielzahl von Angriffen – trotz des Google Chrome-Sandkasten-JavaScript ist der bösartige Code immer noch in der Lage, die Maßnahmen zu vereiteln.
Wie bei jeder Informationssicherheit sollte davon ausgegangen werden, dass bei kompromittierter Umgebung auch alles in und aus sich herausgeht, unabhängig von Sicherheitsmaßnahmen. Sogar binäre Viren in Sandbox-Umgebungen und solche, die in virtuellen Betriebssystemen ausgeführt werden, können aus ihren Grenzen ausbrechen, um das Host-System zu beschädigen, wenn sie mit solchen Szenarien entworfen werden.
Wenn die Konsumenten Ihres Plugins ihre WordPress-Installationen nicht ordnungsgemäß sichern oder kompromittierten Code installieren, gibt es keinen Teil des Dateisystems oder der database, der als “sicher” für kritische Informationen betrachtet werden kann. Genauso, als würde ein Virus auf Ihren Computer gelangen, kann kein Programm oder Dokument vertrauenswürdig bleiben, wenn es unverfälscht oder unbelichtet bleibt. Wenn Sie Kennwörter in einer Nur-Text-Datei speichern, müssen Sie davon ausgehen, dass alle relevanten Konten kompromittiert oder gefährdet sind. Hier wie überall in der IT-Sicherheitswelt sollten Benutzer keine ausführbaren Dateien installieren, denen sie nicht vertrauen oder die sie nicht verstehen – diejenigen, die keine gute Grundlage haben, um zwischen vertrauenswürdigen oder gut implementierten Programmen zu unterscheiden, sollten eine begrenzte Fähigkeit haben, zu erwerben und / oder Installieren Sie solche Gegenstände.
Kurz gesagt, wenn Sie selbst die WordPress-Installationen, auf denen Ihr Plugin installiert ist, nicht direkt kontrollieren, können Sie nicht verhindern, dass Ihr Plugin kompromittiert wird, wenn Sie nicht den guten Sicherheitsvorkehrungen in Ihrer Implementierung folgen.
Kann ein anderes Plugin den Inhalt der Datei lesen, während ich den Verschlüsselungsschlüssel in der class Client speichere?
Ja. Tatsächlich könnte jedes Plugin die wp-config.php Datei der WordPress-Installation parsen und die databaseinformationen und Salze erhalten, wenn es der Autor wünscht. Die Sache ist, ein Plugin muss nicht einmal das tun, um eine Installation zu kompromittieren, da die PHP- und WordPress-Umgebung bereits Plugins zur freien Verfügung über die database und das Dateisystem gibt, um ihre Ziele zu erreichen, soweit die database und das Dateisystem es erlauben. Ohne diese Fähigkeiten wären Plugins extrem begrenzt.
Wenn ja, können Sie einen Platz zum Speichern empfehlen, so dass nur die Client () -class dieses Plugins darauf zugreifen kann?
Nein. Anmeldeinformationen, die als Klartext gespeichert und / oder übertragen werden, sind niemals vollständig “sicher”, Punkt.
Wenn Ihre Anwendung eine solche Speicherung / Übertragung erfordert, können die Anmeldeinformationen nur so sicher sein wie die Umgebung, in der sie gespeichert sind. Sie können zusätzliche Ringe hinzufügen, um die Anmeldeinformationen zu verschleiern, aber die Tatsache bleibt, dass, wenn Ihr Code alles hat, was er benötigt, um die Anmeldeinformationen zu entschlüsseln, dann auch jeder andere Code in der Umgebung. Es ist im Wesentlichen das Gleiche wie das Speichern einer verschlüsselten Datei mit Kennwörtern auf Ihrem Computer neben einem Shell-Skript, das die Datei sofort nach der Ausführung entschlüsselt. Der beste Weg, sie zu schützen, ist die Umwelt zu schützen.
Ich benutze
current_user_can()und nonces, aber reicht das, um AJAX genügend Sicherheit zu geben?
Es hängt von den Besonderheiten Ihrer Anwendung ab und was über AJAX übertragen wird. Im Allgemeinen reichen diese Mechanismen bei korrekter Implementierung aus, um zu bestätigen, dass AJAX-Anforderungen aus einer konsistenten Quelle stammen. Sie sind jedoch nur ein Bestandteil der AJAX-Sicherheit. Als allgemeine Faustregeln:
current-user_can() , check_ajax_referer() $_GET , $_POST und $_COOKIE Daten sowie alle aus der database abgerufenen Daten, die als PHP ausgewertet oder an den Browser gesendet werden. Erfahren Sie, welche WordPress-functionen die Aufgaben für Sie erledigen. Führen Sie diese im Zweifelsfall selbst aus, bis Sie sicher sind. Können Nonces abgelaufen sein?
Ja – WordPress stellt zu diesem Zweck den nonce_lifetime Filter zur Verfügung. Standardmäßig ist eine WordPress Nonce für 12-24 Stunden gültig.
Kann Multisite irgendwelche Zusatzprobleme von meinem Szenario verursachen?
Es hängt davon ab, wie Ihr Plugin installiert ist und Sie beabsichtigen, es in einer Umgebung mit mehreren Standorten zu verwenden – die möglichen “Probleme”, die auftreten könnten, könnten tatsächlich wünschenswerte Ergebnisse sein, je nachdem, wonach Sie suchen.
Möglicherweise möchten Sie E-Mail-Anmeldeinformationen als benutzer- oder standortspezifische Daten speichern, je nachdem, wer auf welche E-Mails zugreifen darf. Möglicherweise möchten Sie sogar benutzerdefinierte Rollen und functionen implementieren, um feineren Zugriff auf Postfächer zu ermöglichen.