Einführung in die WordPress Front-End-Sicherheit: Das Entkommen der Dinge

Wenn Sie ein WordPress-Entwickler sind, der HTML/CSS/JS schreibt (was 100 % der Theme-Entwickler und 99 % der Plugin-Entwickler sind), müssen Sie die Grundlagen der Front-End-Sicherheit für WordPress kennen. WordPress bietet Ihnen alle Werkzeuge, die Sie benötigen, um Ihr Theme oder Plugin sicher zu machen. Sie müssen nur wissen, wie und wann Sie jedes Werkzeug einsetzen.

Zum Beispiel ist eine große Verantwortung, die Sie als Front-End-Entwickler haben, darin, zu verhindern, dass unescaped Inhalte auf der Seite ausgegeben werden.

Sicherheit ist Ihre Verantwortung

Bevor wir ins Detail gehen, möchte ich eine Idee ausräumen, die ich (früher) verwendet habe, um eine „weniger strenge“ Sicht auf die Front-End-Sicherheit zu rechtfertigen

„Wenn ein Hacker bereits in der Lage ist, den Code/die Datenbank/den Inhalt zu ändern, was macht es für einen Unterschied, ob mein Front-End-Code sicher ist? Könnte er nicht schon größeren Schaden anrichten?“

Ja, wenn ein Hacker bereits die Kontrolle über den Code oder die Datenbank hat, ist es wahrscheinlich, dass ihm die Sicherheit der Ausgabe egal ist (er kann sie wahrscheinlich sowieso ändern).

Selbst dann **haben Sie immer noch die Verantwortung, den Front-End-Code sicher zu machen**. Einige Gründe dafür:

• Eine ordnungsgemäße Front-End-Sicherheit **verhindert auch, dass Benutzerfehler zu großen Problemen führen**. Wenn der Benutzer versehentlich ein Sonderzeichen in ein Feld eingibt, das er nicht sollte, stürzt die Seite nicht ab.
• Einige Angriffe sind begrenzt. Vielleicht hatte der Hacker nur minimale Kontrolle und konnte nur ein einzelnes Inhaltselement in der Datenbank ändern. Sie können diesen begrenzten Angriff daran hindern, viel größer zu werden.
• Sicherheit ist eine Zwiebel. Die äußerste (oft ungenießbare) Schicht ist die Front-End-Anzeige. Gute Sicherheitspraktiken machen es für einen Hacker ein kleines bisschen schwieriger, eine Website auszunutzen.

Genug mit der Motivationsrede. Lassen Sie uns darüber sprechen, wie wir unsere WordPress-Themes und -Plugins sichern können.

Wovor haben wir Angst?

Eine große Sorge für einen Front-End-Entwickler ist die Vermeidung von **Cross-Site Scripting** (kurz XSS, da „CSS“ alle möglichen Probleme verursachen würde. Wortspiele und Einzeiler sind willkommen.).

XSS-Schwachstellen ermöglichen es böswilligen Personen („Hackern“), Informationen zu stehlen. Typischerweise bedeutet dies den Diebstahl von Cookies und Sitzungsinformationen. Wenn eine böswillige Person Ihre aktive Sitzung an sich selbst senden kann (daher der Teil „Cross-Site“), könnte sie diese nutzen, um sich in Ihr Konto einzuloggen und alles zu tun, was Sie tun könnten (schlechte Nachrichten).

Was ist Escaping?

In der Informatik hat das Wort „escape“ eine besondere Bedeutung.

Ein Zeichen oder eine Zeichenkette so umwandeln, dass es buchstäblich innerhalb eines bestimmten Kontexts interpretiert wird, typischerweise um zu verhindern, dass diese Zeichen als Code interpretiert werden.

Anders ausgedrückt, im Kontext der WordPress Front-End-Entwicklung: Escaping wandelt **möglicherweise bösartigen** Inhalt in **sicheren** Inhalt um.

Die größte Gefahr hier sind im Allgemeinen <script>-Tags und andere Methoden zur Ausführung von JavaScript (z. B. onclick="javascript:"). Wenn ein <script> auf der Seite ausgegeben und ausgeführt werden kann, ist das extrem gefährlich. Escaping bedeutet, dies in <script> umzuwandeln, was sicher ist.

Warum Sie escapen müssen: Ein Beispiel

Falls Sie mit XSS nicht vertraut sind, wird ein kurzes Beispiel das Risiko verdeutlichen.

Angenommen, Ihr Theme hätte ein Feld, um einen Link für weitere Lektüre hinzuzufügen. Einen „Weiterlesen“-Link, wenn Sie so wollen. Im WordPress-Dashboard könnte es so aussehen:

In Ihrem Theme möchten Sie diesen Link am Ende des Beitrags anzeigen, so:

Also öffnen Sie single.php (die Datei, die für die Anzeige von Blogbeiträgen zuständig ist) und fügen Sie Folgendes unten hinzu:

<?php 
  $read_more_link = get_post_meta( 
    get_the_ID(), 
    'read_more_link', 
    true 
  ); 
?>

<!-- Don't do this -->
<a href="<?php echo $read_more_link; ?>">Read More</a>

Angenommen, jemand gibt bösartig diesen Text in Ihr benutzerdefiniertes Feld ein:

Wenn Sie die Seite besuchen, sehen Sie Folgendes:

Autsch! Wenn diese böse Eingabe es einem bösen Menschen erlauben würde, JavaScript auszuführen, könnten sie:

• Den Benutzer umleiten
• Die Cookies des Benutzers kapern
• Andere böse Dinge tun

Ein Escape für alles

Nachdem wir nun wissen, wie wichtig Escaping ist, schauen wir uns die von WordPress bereitgestellten Escaping-Methoden an und geben für jede Kontextinformationen.

Funktion: esc_html

Verwendet für: Ausgabe, die absolut kein HTML enthalten soll.

Was sie tut: Wandelt spezielle HTML-Zeichen (wie <, >, &) in ihre „escapte“ Entsprechung um (<, >, &).

Ein übliches Beispiel wäre die Anzeige von reinen Text-Custom-Fields in einem Theme

<?php $dog_name = get_post_meta( $post_id, 'dog_name', true ); ?>
<span class="dog-name"><?php echo esc_html( $dog_name ); ?></span>

Codex-Eintrag für esc_html

Funktion: esc_attr

Verwendet für: Ausgabe, die im Kontext eines HTML-Attributs verwendet wird (denken Sie an „title“, „data-“ Felder, „alt“-Text).

Was sie tut: Genau das Gleiche wie esc_html. Der einzige Unterschied besteht darin, dass für jede Funktion unterschiedliche WordPress-Filter angewendet werden.

Hier wird esc_attr für ein Bild verwendet:

<img src="/images/duck.png" 
alt="<?php echo esc_attr( $alt_text ); ?>" 
title="<?php echo esc_attr( $title ); ?>" >

Codex-Eintrag für esc_attr

Funktion: esc_url

Verwendet für: Ausgabe, die zwangsläufig eine URL sein muss. Beispiele wären src-Attribute von Bildern und href-Werte.

Was sie tut: Ein gründlicheres, spezifischeres Escaping als die Funktionen esc_attr & esc_html, das alle Zeichen entfernt oder in ihr URL-sicheres Format umwandelt, die in URLs nicht zulässig sind.

Verwenden Sie esc_url, wenn Sie einen Link oder einen dynamischen Bildpfad ausgeben müssen:

<a href="<?php echo esc_url( $url ); ?>">Link Text</a>
<img src="<?php echo esc_url( $image_url ); ?>" >

Codex-Eintrag für esc_url

Funktion: esc_js

Verwendet für: Ausgabe von JavaScript-Strings, hauptsächlich in Inline-Attributen wie onclick.

Was sie tut: Wandelt Sonderzeichen wie <, >, Anführungszeichen – alles, was JavaScript-Code brechen könnte.

esc_js ist wahrscheinlich die am wenigsten verwendete der esc_-Funktionen, und das aus mehreren Gründen:

1. Die meiste JS wird in einer separaten Datei geladen.
2. Die meisten JS werden nicht inline als Attribute geschrieben.
3. Für Nicht-Inline-JS ist json_encode eine bessere Option.

Aber, wenn Sie jemals Inline-JS escapen müssen, hier ist, wie Sie es tun würden:

<?php $message = get_post_meta( get_the_ID(), 'onclick_message', true ); ?>
<a href="/blog/" onclick="alert('<?php echo esc_js( $message ); ?>')">...</a>

Codex-Eintrag für esc_js

Funktion: json_encode

Verwendet für: Ausgabe einer PHP-Variable für die Verwendung in JavaScript.

Was sie tut: Wandelt eine PHP-Variable (Objekt, String, Array, was auch immer) in eine sinnvolle, escapte JavaScript-Darstellung dieser PHP-Variable um.

Besonders nützlich für <script>-Blöcke, die WP-Variablen verwenden. Ein einfaches Beispiel:

<

pre rel=”PHP”><?php $categories = get_categories(); ?>

<script type="text/javascript">
var allCategories = <?php echo json_encode( $categories ); ?>;
// Hier etwas Interessantes mit den Kategorien tun
</script>


PHP-Referenz für json_encode

Funktion: wp_kses

Verwendet für: Ausgabe, die etwas HTML zulassen muss, aber nicht alle Tags oder Attribute.

Was sie tut: Entfernt aus dem Inhalt alle Tags oder Attribute, die nicht mit der Liste der übergebenen Regeln übereinstimmen.

Verwenden Sie wp_kses, wenn es einen Kontext gibt, der bestimmte Tags zulässt (z. B. Inline-Formatierungstags wie <strong> und <em>), die als HTML ausgegeben werden sollen.

Ein grundlegendes Beispiel wäre die Anzeige von Kommentaren:

Codex-Eintrag für wp_kses

Was sind die _e und _x Versionen der Escaping-Funktionen (esc_attr_e, esc_attr_x)?

Dies sind **Komfortfunktionen** (um Ihnen das Leben zu erleichtern) und sie sind nützlich, wenn Sie übersetzbare Strings ausgeben: Text, der mit einer WordPress-Übersetzungsdatei geändert werden kann.

Wenn Sie ein Theme oder Plugin für eine breite Verteilung entwickeln (im Gegensatz zu einem einmaligen Kundenprojekt), möchten Sie jeden String internationalisierungsfreundlich gestalten. Das bedeutet, dass PHP-Strings, die einst unter Ihrer Kontrolle standen, von Übersetzern bearbeitet werden können – daher die Notwendigkeit des Escapings (Sie können niemandem vertrauen).

Blog

Der zweite Parameter der _e-Funktionen ist die Übersetzungdomäne. Sie wird von Übersetzern verwendet, wenn sie ihre Übersetzungen schreiben und generieren.

Die _x-Funktionen (wie esc_html_x) sind im Wesentlichen die gleichen wie ihre _e-Gegenstücke, mit einem zusätzlichen „Kontext“-Argument, um den Kontext zu erklären, in dem ein Wort oder eine Phrase verwendet wird. Nützlich für Wörter mit mehreren Bedeutungen.

Codex-Eintrag für esc_attr_e
Codex-Eintrag für esc_attr_x

Was ist mit the_title und the_content?

Wenn Sie das Standard-WordPress-Theme (zu diesem Zeitpunkt „Twenty Fifteen“ genannt) öffnen, sehen Sie Code wie diesen, der den Titel eines Beitrags ausgibt:

Sie sehen auch unescaped Aufrufe an the_content wie diese:

Sie geraten vielleicht in Panik. Warum werden diese Funktionen nicht escaped?! 2 Gründe:

1. WordPress escaped sie automatisch

Funktionen wie the_title sind Komfortfunktionen – Werkzeuge, die die Front-End-Entwicklung erleichtern. Um es Entwicklern noch einfacher zu machen, escaped WordPress bereits automatisch die Ausgabe für the_title Update: WordPress escaped the_title nicht, sei vorsichtig!.

2. Kontext: Einige Inhalte sind HTML

Im Fall von the_content wird erwartet, dass die Ausgabe unescaped HTML ist. Wenn der Benutzer einen

...