webentwicklung-frage-antwort-db.com.de

Sicherheit bei der Entwicklung von WordPress-Plugins

Mein Plugin ist Mailer.app für WordPress, ich bin zu 85% fertig und konzentriere mich auf die Sicherheit vor der Veröffentlichung. Vor den Fragen sollte ich die Plugins-Architektur skizzieren:

  • Das Plugin kann username & password und relative imap/smtp Serverdetails aufnehmen.
  • Die Angaben werden validiert und es wird sichergestellt, dass das richtige IMAP/SMTP eingegeben wird (gültige Verbindung (en) hergestellt)
  • Die Serverdetails + E-Mails werden mit der EKEY verschlüsselt, die im class.client.php als CONST gespeichert ist.
  • Die password wird verschlüsselt (kann nicht als Klartext für imap/smtp gehasht werden) und in einem Cookie unter Verwendung einer CKEY gespeichert, die im class.client.php. gespeichert ist.

  • Die Daten werden sowohl mit dem Cookie als auch mit den Benutzerdaten entschlüsselt.

Nun zu den Sicherheitsfragen von WordPress. Ich arbeite seit ungefähr 3 Jahren mit wp und kann diese nicht verstehen und finde keine Informationen darüber:

  • Können andere Plugins auf meinen Plugin-Code zugreifen? z.B. require("../plugins/mail/class.client.php') und new Client() aufrufen? Wenn ja, wie verhindere ich das und warum ist das zulässig?
  • Kann ein anderes Plugin den Inhalt der Datei lesen, wenn ich den Verschlüsselungsschlüssel in der Klasse Client speichere? Wenn ja, können Sie einen Speicherort empfehlen, an dem nur die Client()-Klasse dieses Plugins darauf zugreifen kann?
  • Ich verwende current_user_can() und nonces, aber reicht dies aus, um AJAX ausreichend zu schützen? Können Nonces abgelaufen sein? und wo lese ich mehr über sie in Bezug auf Sicherheit, Ajax und Web-Apps.
  • Kann multisite in meinem Szenario Probleme mit Hinzufügungen 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 oberstes Ziel ist, andere Plugins, ob infiziert (Backdoor usw.) oder nicht, können nicht auf die Variable username/password/mail meiner E-Mail zugreifen, das ist der Hauptteil der Frage. Die in der Datenbank verschlüsselten und gespeicherten Benutzerdaten können nur mit Cookie und $key entschlüsselt werden. $key ist das meiste anfällige Element.

Entschuldigung für den extra langen Beitrag, aber ich brauche diese Fragen von meiner Brust und hoffentlich etwas Einsicht und Hilfe.

Vielen Dank

5
Kivylius

Was mein oberstes Ziel ist, andere Plugins, ob infiziert (Backdoor usw.) oder nicht, können nicht auf die Variable username/password/mail meiner E-Mail zugreifen, das ist der Hauptteil der Frage.

Die einzige Möglichkeit, dies zu gewährleisten, besteht darin, sie nicht auf eine Weise zu speichern, die automatisch in der Datenbank/im Dateisystem entschlüsselt werden kann, dh sie dürfen nicht im Klartext oder überhaupt nicht automatisch entschlüsselt werden.

Ich würde empfehlen, Ihre eigenen Sicherheitssalze und Schlüssel mit den für WordPress selbst konfigurierten zu verketten/zu haschen - Sie sollten niemals ein Plugin verteilen, das fest codierte Salze verwendet, da jeder mit dem Plugin im Grunde die Schlüssel für jede Installation erhält, die gehasht wurden. Wenn Sie feststellen, dass Ihr Plugin anfällig ist, können Sie durch Hinzufügen eines eigenen Salt in der WordPress-Installation die Salt aktualisieren und die Anmeldeinformationsspeicher aller Installationen ungültig machen, wenn das Plugin-Update gepusht wird. Wenn eine einzelne Installation beeinträchtigt wird, kann ein Benutzer seine WordPress-Version ändern und seine Anmeldeinformationen ebenfalls ungültig machen, ohne das Plugin zu ändern.

Können andere Plugins auf meinen Plugin-Code zugreifen? z.B. require("../plugins/mail/class.client.php') und new Client() aufrufen?

Ja.

Wenn ja, warum ist das erlaubt?

Dies ist weniger "erlaubt" als vielmehr eine Folge interpretierter Skriptumgebungen. Das "Erweitern von WordPress" mit Themes und Plugins ist genau das - es modifiziert die Ausführung von WordPress unter Verwendung von Raw Source, um das gewünschte Ergebnis zu erzielen. Ich kenne keine interpretierte Sprache, die tatsächlich zuverlässige Mechanismen bietet, um Teile des Quellenskripts von anderen Teilen innerhalb derselben Codebasis zu "sperren". Betriebssysteme, klar.

Diese Verantwortung liegt vielmehr bei der Ausführungsumgebung und bei demjenigen, der sie kontrolliert.

Wie verhindere ich das?

Es ist möglicherweise möglich, einige sehr komplexe Sandboxing-Vorgänge durchzuführen und verschiedene Teile von WordPress in verschiedenen Threads auszuführen. Dies ist jedoch keineswegs das Design von WordPress und würde eine umfangreiche Neukonfiguration der Umgebung erfordern, um das System zu starten. Selbst dann wäre es immer noch anfällig für verschiedene Angriffe - trotz des in Google Chrome in einer Sandbox enthaltenen JavaScript taucht immer noch bösartiger Code auf, der in der Lage ist, die Maßnahmen zu umgehen.

Wie bei der gesamten Informationssicherheit sollte davon ausgegangen werden, dass bei einer Beeinträchtigung der Umgebung auch alles vorhanden ist, unabhängig von den vorhandenen Sicherheitsmaßnahmen. Sogar binäre Viren in Sandbox-Umgebungen und solche, die in virtuellen Betriebssystemen ausgeführt werden, können aus ihren Grenzen ausbrechen und das Host-System schädigen, wenn sie unter Berücksichtigung solcher Szenarien entwickelt werden.

Wenn die Konsumenten Ihres Plugins ihre WordPress-Installationen nicht ordnungsgemäß sichern oder kompromittierten Code nicht installieren können, gibt es keinen Teil des Dateisystems oder der Datenbank, der als "sicher" eingestuft werden kann, damit wichtige Informationen gespeichert werden können. So wie ein Virus auf Ihren Computer gelangt, kann kein Programm oder Dokument als unverfälscht oder unveröffentlicht eingestuft werden. Wenn Sie Kennwörter in einer Nur-Text-Datei speichern, müssen Sie davon ausgehen, dass alle relevanten Konten gefährdet oder anfällig 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 für die Unterscheidung zwischen vertrauenswürdigen oder gut implementierten Programmen haben, sollten eine eingeschränkte Fähigkeit zum Erwerb und/oder Installieren Sie solche Elemente.

Kurz gesagt, wenn Sie die WordPress-Installationen, auf denen Ihr Plugin installiert ist, nicht direkt selbst steuern, können Sie nicht verhindern, dass Ihr Plugin kompromittiert wird, wenn Sie nicht den guten Sicherheitsmethoden in Ihrer Implementierung folgen.

Kann ein anderes Plugin den Inhalt der Datei lesen, während ich den Verschlüsselungsschlüssel in der Client-Klasse speichere?

Ja. Tatsächlich könnte jedes Plugin die wp-config.php-Datei der WordPress-Installation analysieren und die Datenbankinformationen und -salze abrufen, falls der Autor dies wünscht. Die Sache ist, dass ein Plugin nicht einmal das tun muss, um eine Installation zu gefährden, da die PHP - und WordPress-Umgebung Plugins bereits die Möglichkeit bietet, frei über die Datenbank und das Dateisystem zu verfügen, um ihre Ziele zu erreichen, sofern es sich um die Datenbank und handelt Dateisystem selbst zulassen. Ohne diese Fähigkeiten wäre der Umfang der Plugins extrem begrenzt.

Wenn ja, können Sie einen Speicherort empfehlen, an dem nur die Client () - Klasse dieses Plugins darauf zugreifen kann?

Nein. Berechtigungsnachweise, die im Klartext gespeichert und/oder übertragen werden, sind niemals vollständig "sicher".

Wenn für Ihre Anwendung eine solche Speicherung/Übertragung erforderlich ist, können die Anmeldeinformationen nur so sicher sein wie die Umgebung, in der sie gespeichert sind. Sie können zusätzliche Rahmen hinzufügen, um die Anmeldeinformationen zu verschleiern. Es bleibt jedoch die Tatsache, dass, wenn Ihr Code über alles verfügt, was zum Entschlüsseln der Anmeldeinformationen erforderlich ist, dies auch für alle anderen Codes in der Umgebung gilt. Dies entspricht im Wesentlichen dem Speichern einer verschlüsselten Datei mit Kennwörtern auf Ihrem Computer zusammen mit einem Shell-Skript, das die Datei entschlüsselt, sobald sie ausgeführt wird. Der beste Weg, sie zu schützen, besteht darin, die Umwelt zu schützen.

Ich verwende current_user_can() und nonces, aber reicht dies aus, um AJAX ausreichend zu schützen?

Dies hängt von den Besonderheiten Ihrer Anwendung und den über AJAX übertragenen Daten ab. Im Allgemeinen sind diese Mechanismen bei ordnungsgemäßer Implementierung ausreichend, um validieren zu bestätigen, dass AJAX Anforderungen von einer konsistenten Quelle stammen. Sie an und für sich sind jedoch nur eine Komponente der AJAX - Sicherheit. Als allgemeine Faustregeln:

  • Ergreifen Sie keine Maßnahmen, bis die Anforderung "ausreichend" überprüft wurde, einschließlich der Verwendung von current-user_can() , check_ajax_referer()
  • Escape, validieren und bereinigenall die Dinge, die dynamische Daten umfassen. Diese Vorgehensweisen sind unabdingbar, um SQL-Injections, die willkürliche Ausführung von PHP und die Bereitstellung von schädlichem JavaScript für Besucher zu verhindern. Dies umfasst $_GET-, $_POST- und $_COOKIE-Daten sowie alle aus der Datenbank abgerufenen Daten, die als PHP ausgewertet oder an den Browser gesendet werden. Erfahren Sie, welche WordPress-Funktionen die Aufgaben für Sie erledigen - aber führen Sie sie im Zweifelsfall selbst aus, bis Sie sicher sind.
  • Wenn Sie die Serverumgebung steuern, sichern Sie Ihre Site mit einem SSL-Zertifikat und verwenden Sie das HTTPS-Protokoll, um die Wahrscheinlichkeit von Man-in-the-Middle-Angriffen zu verringern ( das Let's Encrypt-Projekt ist auf dem besten Weg, es anzubieten vertrauenswürdige Zertifikate kostenlos).
  • Stellen Sie sicher, dass Ihre Fehlerbehandlung so implementiert ist, dass keine vertraulichen Daten an den Browser zurückgespeist werden, wenn Ihr Server-Skript drosselt oder direkt von einem Client aus darauf zugegriffen wird.

Können Nonces abgelaufen sein?

Ja - WordPress bietet zu diesem Zweck den nonce_lifetime-Filter an. Standardmäßig ist ein WordPress-Nonce 12-24 Stunden gültig.

Kann Multisite Probleme mit Hinzufügungen in 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 potenziellen "Probleme", die auftreten können, sind möglicherweise erwünschte Ergebnisse, je nachdem, worauf Sie schießen.

Abhängig davon, wer Zugriff auf welche E-Mails haben soll, möchten Sie möglicherweise E-Mail-Anmeldeinformationen als benutzerspezifische oder standortspezifische Daten speichern. Möglicherweise möchten Sie sogar benutzerdefinierte Rollen und Funktionen implementieren, um einen differenzierteren Zugriff auf Postfächer zu ermöglichen.

1
bosco