Webkit Browser sind mit einem XSS Schutz ausgestattet, welcher lösbare Probleme bei der WordPress Artikelvorschau verursachen kann.
Cross-Site-Scripting (XSS), also das Einfügen von schädlichen Skripter einer Seite A in Seite B, ist ein Sicherheitsfaktor, den es gilt zu unterbinden. Primär sind dafür die Entwickler der jeweiligen Webseite zuständig.
Doch auch heutige Browser klinken sich in die Thematik ein.
Seit geraumer Zeit besitzen WebKit Browser, siehe Chrome und Safari, einen XSS Filter, der überprüft, ob ein Skript, welches auf einer Webseite ausgeführt werden soll, sich auch schon in der POST Anfrage befand. Ist dem so, kann dies ein Indiz für eine XSS-Attacke sein und wird geblockt.
Mit folgenden Beispiel kann der XSS Filter selbst getestet werden:
<?php
if( ! $_POST ) :
?>
<form method="post">
<input name="xss" value="<iframe src='http://example.com'></iframe>" />
<input type="submit" />
</form>
<?php
else :
echo $_POST['xss'];
endif;
Was hat das nun mit der Artikelvorschau in WordPress zu tun?
Ganz einfach: Starte Chrome oder Safari, erstelle einen Artikel mit einem YouTube Video und klicke auf den Button Vorschau.
Das Ergebnis:
Man sucht vergeblich das YouTube Video, die Konsole wirft ein „Refused to execute a JavaScript script. Source code of script found within request.“ aus und nach einem Reload des Fensters ist das YouTube Video wieder da.
Warum? Der XSS-Filter hat zugeschlagen.
Beim Klick auf den Vorschau Button wird eine POST Abfrage an /wp-admin/post.php gestartet und intern als post.php?action=preview aufgenommen.
Dadurch wird erreicht, dass eventuelle Änderungen in einem Entwurf oder einer Revision (Autosave) gespeichert werden. Genaueres kann man der Funktion post_preview() entnehmen.
Das Wichtige an der Funktion ist die Rückgabe. Er enthält die Weiterleitung zur eigentlichen Vorschau.
Wie bekannt ist, zeigt die Vorschau eine 1:1 Kopie des Artikels samt Änderungen. Dazu zählt auch in unserem Fall der vorher per POST gesendete Artikelinhalt mit dem YouTube Video.
Wir erinnern uns zurück: Der XSS-Filter schlägt zu, wenn ein Skript in einer POST Abfrage gefunden wird und gleichzeitig vom Browser gerendert werden soll.
Trotz dem Umweges ist dies nun bei WordPress genau der Fall.
Und jetzt?
Den WebKit XSS Filter umgehen
Mit Hilfe eines nicht-standardisierten HTTP-Headerfeldes X-XSS-Protection kann dem Browser mitteilt werden, dass schon auf der Client-Seite für die nötige Sicherheit gesorgt wurde. Der Wert des Feldes sollte dann mit 0 belegt werden.
Folgende Zeilen setzen das Vorhaben für unsere Artikelvorschau um und sollte in einem Plugin Platz finden.
/**
* Add a X-XSS-Protection = 0 header for post previews to allow
* Webkit browsers to render iframe and flash objects.
* @see: http://core.trac.wordpress.org/ticket/20148
*
* @param $headers array Already added header items.
* @param $object WP The query variables.
*
* @return array
*/
function send_no_xss_protection_header( $headers, $object ) {
if (
! empty( $object->query_vars['preview'] ) &&
! empty( $object->query_vars['p'] ) &&
wp_get_referer() &&
wp_get_referer() == sprintf( admin_url( 'post.php?post=%d&action=edit' ), $object->query_vars['p'] )
)
$headers['X-XSS-Protection'] = 0;
return $headers;
}
add_filter( 'wp_headers', 'send_no_xss_protection_header', 10, 2 );
Führt man das obige Szenarion nun erneut aus, so sollte das YouTube Video direkt angezeigt werden.
Zum Thema
- Preview post in Webkit browser doesn’t render Flash objects — core.trac.wordpress.org
- Security in Depth: New Security Features — blog.chromium.org
- Controlling the XSS Filter — blogs.msdn.com
- HTTP access control (CORS) — developer.mozilla.org