web-dev-qa-db-de.com

Nach welchen allgemeinen Sicherheitslücken muss ich suchen?

Nach welchen Sicherheitslücken sollte ich als Entwickler eines Möchtegern-Plugins WP Ausschau halten?

Ich erstelle gerade ein neues Plugin mit einem Konfigurationsfenster (dh Eingabefelder und so). Worüber sollte ich mir Sorgen machen?

Ist beispielsweise die Datenbereinigung eine große Sache, da sie sich im Bereich/wp-admin/befindet? Könnte jemand meine Plugin-Seite direkt angreifen und POST -Anfragen oder ähnliches senden?

Vielen Dank!

15
MrBatman

Hier ist eine geänderte Checkliste, die auf meinen aktuellen (in Arbeit befindlichen) Einstellungen/meiner Datensicherheits-Checkliste basiert, die zum Überprüfen von Themen verwendet wird (die Prinzipien sollten für Plugins nicht anders sein als für Themen):

  1. Plugins sollten allen Optionen, benutzerdefinierten Funktionen, benutzerdefinierten Variablen und benutzerdefinierten Konstanten plugin-slug voranstellen.

  2. Plug-ins sollten die Seiten Plug-in-Optionen und Plug-in-Einstellungen bewusst implementieren, anstatt sich auf Skripts zum Kopieren und Einfügen aus Website-Tutorials wie den folgenden zu verlassen, die veraltet sind und keine ordnungsgemäße Datensicherheit bieten:

  3. Plugins sollten die Funktion add_options_page() verwenden, um die Plugin-Einstellungsseite zum Menü Settings hinzuzufügen, anstatt add_menu_page() zum Hinzufügen eines Menüs der obersten Ebene zu verwenden.

  4. Plugins sollten ein geeignetes Capability (z. B. manage_options) verwenden, damit die Einstellungsseite hinzugefügt werden kann.

  5. Plugins sollten Optionen in einem einzigen Array speichern, anstatt mehrere Optionen für die Einstellungsseite zu erstellen. Die Verwendung der Einstellungs-API (siehe unten) würde dies handhaben.

  6. Plugins sollten die Einstellungs-API (siehe unten) verwenden, um Formulareingabedaten abzurufen und zu speichern, anstatt sich direkt auf $_POST- und $_REQUEST-Daten zu verlassen.

  7. Für Kontrollkästchen und ausgewählte Optionen sollten Plugins die Funktionen checked() und selected() zur Ausgabe von checked="checked" bzw. selected="selected" verwenden.

  8. Plugins sollten alle nicht vertrauenswürdigen Daten validieren und bereinigen, bevor sie Daten in die Datenbank eingeben, und sollten alle nicht vertrauenswürdigen Daten entziehen, bevor sie in den Formularfeldern "Einstellungen" und in den Vorlagendateien für Designs ausgegeben werden:

  9. Plugins sollten esc_attr() für Texteingaben und esc_html() (oder esc_textarea() in WP 3.1) für Textbereiche verwenden.

  10. Plugins sollten explizit die Nonce-Prüfung auf der Einstellungsseite bereitstellen, wenn die Einstellungs-API nicht verwendet wird:

  11. Es wird außerdem dringend empfohlen, dass Plugins die Einstellungs-API verwenden. Diese ist einfacher zu verwenden, sicherer und erledigt einen Großteil der harten Arbeit der Einstellungsseiten:

Ein gutes Tutorial zur Verwendung der Einstellungs-API finden Sie unter:

Wenn Sie ein Thema mit einer sicheren und solide codierten Seite für Themaeinstellungen auschecken möchten, sehen Sie sich dieses Thema an:
http://wordpress.org/extend/themes/coraline

16
Chip Bennett

Das hat zwei Aspekte:

  1. Grundprinzipien.

    • Was auch immer in die Datenbank geschrieben wird, sollte auf SQL-Injects überprüft werden.
    • Was auch immer auf dem Bildschirm gedruckt wird, sollte überprüft werden, dass es kein schädliches JavaScript druckt.
    • Wann immer jemand etwas tut, sollte überprüft werden, ob es seine Absicht war und er über die entsprechenden Fähigkeiten verfügt.
    • Es gibt viele, viele weitere Dinge, auf die Sie oder ich niemals nachdenken werden.
  2. Besonderheiten.

    • Modernes WordPress nimmt die Sicherheit ernst und möchte es Entwicklern leicht machen.
    • Für die meisten Dinge, die Sie tun möchten, gibt es wahrscheinlich eine Möglichkeit, dies mit WP APIs zu erledigen.
    • Was auch immer Sie tun, Ihr erster Schritt wäre es, die passende API zu finden und zu studieren.
    • Je weiter Sie von der gewöhnlichen und einfachen Funktionalität entfernt sind, desto komplexer werden die Dinge, die Sie studieren und implementieren müssen.
11
Rarst
  1. Füge defined('ABSPATH') or die('Access denied'); bei jedem Plugin-Skript hinzu, das von WordPress direkt verwendet wird
  2. Fügen Sie in jedem Verzeichnis eine leere Datei index.php hinzu
  3. Fügen Sie .htaccess im Plugin-Verzeichnis mit den erforderlichen Anweisungen hinzu, um den direkten Zugriff auf bestimmte Plugin-Dateien zu verhindern.
1
egor