Die Social Media Marketing Agentur Regensburg hat am Beispiel der oft genutzten Geburtstagskalender-App sehr anschaulich aufgezeigt, was mit den eigentlich persönlichen Daten der Facebook-User passiert und wie sie weiterverarbeitet werden.

zum Artikel →

add_filter('tiny_mce_before_init', create_function( '$a',
'$a["extended_valid_elements"] =
"iframe[id|class|title|style|align|frameborder|height|longdesc|marginheight|marginwidth|name|scrolling|src|width]";
return $a;') );

zum Download →

Weil Daten-Validierung und -Kontrolle bereits einen Großteil sowohl der internen Sicherheitsmaßnahmen als auch der normalen Input-Verarbeitung ausmachen, sollte durch die Sicherung des Quellcodes nicht nur der Schutz unserer Backends verbessert werden, sondern auch eine bessere, solidere User Experience bieten.

Obwohl ein großer Teil dieses Artikels ist speziell für WordPress gilt, sind dies doch zu einem erheblichen Teil allgemeine Praktiken, die jeder nutzen kann und sollte. Selbst die WordPress-spezifischen Abschnitte enthalten nützliche & lesenswerte Logiken, auch wenn ein anderes Framework verwendet wird.

Exploits

Mit URL-basierten Exploits suchen Hacker Schwachstellen auf Ihrer Website, indem sie URLs aufrufen, die in aller Regel einen Fehler zurückgeben – aber manchmal eben doch funktionieren.

http://mysite.com/trying/to/exploit/%2F/config

Die oben aufgeführte hypothetische  URL ist im Wesentlichen nichts anderes als ein “Schuß ins Blaue”. Aber wenn der Server dem Aufruf stattgibt, obwohl die URL eindeutig nicht dazu geeignet ist, eine Seite aufzurufen, kann ihm diese URL von Nutzen sein.

Die .htaccess als Firewall nutzen

Eine der besten Methoden gegen Angriffe dieser Art ist eine .htaccess-Firewall. Sie beruht im Wesentlichen auf Regeln, die automatisch string-basierte Aufrufe aus URLs blockiert.

Beispiel: Es gibt keinen vernünftigen Grund, öffnende eckige Klammern in einer URL zu nutzen. Wenn ein URL-Aufruf eckige Klammern enthält, dann hat sich der User entweder vertippt, oder ein Angreifer sucht nach einer Sicherheitslücke: In jedem Fall ist die Ausgabe einer “403 – Forbidden” – Seite erste Wahl:

RedirectMatch 403 \[

Kopieren Sie diese Code-Zeile einfach in Ihre .htaccess, damit werden alle Aufrufe mit eckigen Klammern geblockt.

Um mehr als nur eckige Klammern zu überwachen, wird ein komplexeres Regelwerk benötigt. Zum Glück gibt es Programmierer wie Jeff Starr →, der sich eingehend mit diesem Thema beschäftigt und ein großartiges Regelwerk für .htaccess-gesteuerte Zugriffskontrollen erarbeitet hat. Die neueste Variante nennt sich 5G Firewall und ist komplett kostenlos.

5G Firewall Copy & Paste HIER →

Die Firewall ist modular, Sie können Zeilen löschen, ohne die Funktionalität einzuschränken. Falls etwas schiefgeht, können Sie sich problemlos Zeile für Zeile durcharbeiten, bis der Eintrag gefunden ist, der den Fehler verursacht. Die betreffende Zeile löschen oder auskommentieren - den Rest weiterverwenden, einfacher geht es kaum.

Verzeichnisschutz

Auf vielen Servern ist es möglich, den Inhalt eines Verzeichnisses anzuzeigen, indem man einfach dessen URL angibt.

http://myblog.com/wp-content/uploads/2011/08/

Der Aufruf dieser typischen WordPress URL listet den gesamten Inhalt des Ordners auf, alle Uploads vom August 2011 sind sichtbar. Möglicherweise ist das gewollt, kann (und sollte) aber abgeschaltet oder eingeschränkt werden - mit der guten alten .htaccess.

Options -Indexes

Dieser Eintrag in der .htaccess verhindert das Auflisten des Verzeichnisinhaltes, der User erhält eine "403 - Forbidden" Fehlermeldung, sobald er das Verzeichnis direkt aufruft. Die allermeisten Webseitenbetreiber kennen diese Regel, wissen aber nicht, daß diese Regel mittels der "IndexIgnore"-Direktiven verfeinert werden können:

IndexIgnore *
IndexIgnore *.php
indexIgnore *.jpg *.gif *.png

Wenn das Verzeichnislisting nicht deaktiviert ist, dann wird:

• mit der ersten Zeile zwar das Verzeichnis angezeigt, aber keine Datei
• mit der zweiten Zeile der Inhalt des Verzeichnisses mit Ausnahme der .php-Files angezeigt
• mit der dritten Zeile werden alle Dateien außer .jpg, .gif und .png-Files aufgelistet

Die meisten Hoster haben das Verzeichnislisting standardmäßig deaktiviert, so daß keine Änderungen an der .htaccess nötig sind, falls Sie sich nicht sicher sein sollten, tippen Sie einfach einen Verzeichnispfad ein und sehen, was passiert.

Zusätzlicher Server-Level Schutz

Bisher haben die Maßnahmen, die wir ergriffen haben nichts mit dem eigentlichen Code unserer Webseite zu tun. Egal wie sicher Ihr Code ist, Sie MÜSSEN den bisher angegebenen Tipps Ihr Augenmerk schenken. Wir haben leider keine Zeit, alle Tipps und Tricks für die .htaccess auszuarbeiten, aber Sie können durchaus noch mehr tun:

• Verzeichnisse mit Passwörtern absichern
• Intelligente Redirects
• IP- oder IP-Bereichsabhängige Zugriffssteuerung
• Hotlink-Schutz
• Download-Management
• ...

Wir empfehlen an dieser Stelle die Weiterführende Literatur → - Sektion am Ende dieses Artikels. Dort finden Sie mit Sicherheit genügend weiterführende Informationen, so daß Sie sich am Ende doch noch mit Ihrer .htaccess anfreunden können.
Sicherlich wird das Eine oder Andere anfangs eher verwirrend wirken, und ein solides Wissen ist sicher nicht leicht zu erarbeiten - doch wer dieses Wissen einmal hat, kann es sehr wirksam einsetzen.

Schutz vor böswilligen Benutzern

Die zweite Art von Problemen kann immer dann auftauchen, wenn jemand etwas tut, was er nicht hätte tun sollen. Damit sind sowohl User gemeint, die wissentlich Aktionen ausführen, als auch die berühmt-berüchtigten DAU's (Dau: Dümmster anzunehmender User) und/oder PEBKAC's (PEPCAC:Problem exists between keyboard and chair - Problem existiert zwischen Tastatur und Stuhl).

Falls sich beispielsweise User irgendwo im Administrationsbereich befinden können, könnte z.B. die Möglichkeit bestehen, daß ein Link zum löschen von Usern angezeigt wird. Dieser Link zeigt beispielsweise auf dieses Script:

http://mysite.com/admin/scripts/delete_user.php?user_id=5

Dieses Szenario scheint zugegebenermaßen etwas weit hergeholt, die Chance, daß jemand über solch einen Link stolpert ist relativ gering. Aber:
Wenn Verzeichnislisting aktiviert und kein Verzeichnisschutz eingerichtet ist, könnte auch ein Unbefugter über den Verzeichnisaufruf (http://mysite.com/admin/scripts/) das Script delete_user.php finden und damit versuchen einen oder mehrere User zu löschen.
Falls nun das Script nicht prüft, ob der User die Aktion ausführen DARF (Authority) und WILL (Intent), ja dann können die User von jedem, der dieses Script ausführen KANN (Knowledge), gelöscht werden.

Authority, Intent & Knowledge

Wann immer ein User eine Aktion ausführen will, haben wir zwei Dinge zu berücksichtigen:
Hat der User die nötige Berechtigung, um die Aktion durchzuführen? Wenn der User über die nötigen Rechte verfügt, weiß er dann auch, was er tut?

Beispiel: Sie haben festgelegt, daß nur Administratoren Inhalte Ihrer Webseite bearbeiten und/ oder löschen können. Immer wenn ein User versucht, Inhalte zu verändern/ zu löschen, ist damit sichergestellt, daß er als Administrator angemeldet sein MUSS. Soweit zum Part Authority.

Intent läßt sich ebenfalls mit einem Beispiel beschreiben. Denken wir uns, man kann den folgenden Link zum Löschen von Kommentaren verwenden:

http://mysite.com/admin/scripts/delete_comment.php?comment_id=5

Das Script selbst prüft, ob der betreffende User momentan als Administrator angemeldet ist - die Frage der Berechtigung wäre ja soweit geklärt, kann er jetzt noch Schaden anrichten? Sicher kann er!
Ein Hacker könnte auf einer Webseite einen Link zu diesem Script setzen:

<a href="http://mysite.com/admin/scripts/delete_comment.php?comment_id=5">
Super-Happy Times Here!
</a>

Weil so ziemlich jedermann "Super-Happy Times" mag, werden viele User den Link auch anklicken. In 99% der fälle passiert - nichts. Wenn aber ein User als Admin auf mysite.com angemeldet ist und gleichzeitig den Link auf der Webseite des Hackers klickt, wird die Aktion ausgeführt - ohne weitere Rückfrage, obwohl der betreffende User diese Aktion ja nicht ausführen will.

Sie denken jetzt sicher, die Chancen, daß so etwas passiert, sind astronomisch gering. Einerseits stimmt das, andererseits aber auch nicht, denn ein Hacker kann so etwas extrem einfach und vor allem automatisiert ausführen. Millionen Menschen erhalten täglich Spam-Emails mit falschen Links. Die meisten von Ihnen löschen diese, oder markieren Sie als Spam, aber einer wird die Mail sicher öffnen und den Link klicken. Ein Hacker wird den Link sicher auch nicht auf seiner eigenen Webseite haben - es genügt eine fremde Webseite zu knacken und den Link dort einzubetten. Bis das jemand bemerkt kann (und wird) es zu spät sein.

Berechtigungen in WordPress

WordPress hat ein integriertes Berechtigungs-System. Sogenannte "integrierte Berechtigungen (Capabilities)" sind die Grundlage des ganzen Systems "Rollen und Berechtigungen." Rollen (Roles) sind nur eine Möglichkeit, einen Satz von Berechtigungen zusammenzustellen.

Wenn ein User die "delete_posts" Berechtigung hat, dann darf er auch nur Posts löschen. Darf er Posts bearbeiten, darf er auch nur das. Es sind einige Berechtigungen vorgegeben, die zu einer Rolle zusammengefasst werden können, es können aber auch eigene Berechtigungen vergeben werden.

Rollen sind vom Grundsatz her erstmal nur ein "Bündel" Berechtigungen. Ein User mit der Rolle "Mitarbeiter" hat standardmäßig drei Berechtigungen: read, delete_posts, edit_posts. Damit kann der User (alle) Posts lesen, aber nur EIGENE Posts bearbeiten oder löschen. Berechtigungen können jedem User einzeln zugewiesen werden, sie sinnvoll als Rolle zusammenzufassen und an User-Gruppen zu vergeben, ist aber einfacher und praktikabler.

Das behalten wir im Hinterkopf und sehen, wie WordPress-Funktionen genutzt werden können, um sicherzustellen, daß User die benötigte Berechtigung besitzen, um Aktionen auszuführen.

if(current_user_can("delete_users")) {
wp_delete_user(5);
}
else {
die("Sie haben nicht die nötige Berechtigung");
}

Hier ist sichergestellt, daß der User andere Benutzer löschen darf. Die Funktion current_user_can() benötigt ein Argument. Dies kann sowohl eine Rolle als auch eine Berechtigung sein. Wir könnten z.B. Editoren, (die das normalerweise nicht dürfen) diese Aktion trotzdem ausführen lassen:

if(current_user_can("editor")) {
wp_delete_user(5);
}
else {
die("Sie müssen Editor sein, um User löschen zu können");
}

Mit dieser Variante sollten Sie aber vorsichtig sein, denn Rollen sind hierfür (eigentlich) nicht vorgesehen. Diese Funktion benötigt nicht mindestens die Rolle "Editor", sondern EXAKT die Rolle "Editor". Das bedeutet im Umkehrschluß natürlich, daß ein Administrator diese Funktion nicht ausführen kann, obwohl er in der Rollen-Hierarchie oberhalb des Editors steht. Aus diesem Grund sollten in diesen Funktionen Berechtigungen an Stelle von Rollen angegeben werden.

Zwei ähnliche Aufrufe

Zwei weitere ähnliche Funktionen ermöglichen es Ihnen, die Berechtigungen von anderen Benutzern als dem aktuell Angemeldeten untersuchen.

// Funktion 01:
if(user_can(5, "manage_links")) {
echo "User 5 darf Links managen";
}
else {
echo "User 5 ist nicht berechtigt, Links zu managen";
}

// Funktion 02
if(author_can(1879, "update_themes")) {
echo "Der Autor des Artikels #1879 darf Themes updaten";
}
else {
echo "Der Autor des Artikels #1879 darf Themes nicht updaten";
}

Die Funktion 01 user_can(Argument 01, Argument 02) prüft, ob der angegebene User die angegebene Rolle (oder Berechtigung) besitzt, also User und Berechtigung zusammenpassen. Das erste Argument ist die User-ID oder ein User-Objekt (Post, Seite...), das zweite Argument ist die Rolle oder Berechtigung, die geprüft wird.

Gleiches gilt für die Funktion 02 author_can(Argument 01, Argument 02) mit dem Unterschied, daß hier der Zusammenhang zwischen Autor und Artikel geprüft wird.

"Wollen Sie das wirklich?" in WordPress

Zu prüfen, ob die gewählte Aktion wirklich gewollt ausgeführt werden soll (Intent), ist etwas schwieriger zu prüfen. In den "guten, alten Zeiten" war die Referrer-Überprüfung ($_SERVER['HTTP_REFERRER']) der geeignete Weg. Hier wird (wurde) die Seite abgefragt, von der der User kam. War der Domainname derselbe wie der Eigene, war der User erst einmal OK...bis etwas schiefging.

Eine sicherere Methode wurde mit WordPress 2.03 (lang ist's her...) eingeführt - die sogenannten "Nonces". Nonce bedeutet "Number used once" und wird in der Kryptographie für sichere Kommunikation benutzt. Die Nonce ist eine Nummer die generiert wird, bevor die Aktion initialisiert ist, an den Aktionsaufruf (Link, Formular-Buttons) angehängt und überprüft wird, bevor die Aktion ausgeführt wird.

In WordPress werden Nonces generell in Formularen und Links genutzt. Sehen wir uns an, wie eine Nonce in einem Formular generiert wird:

Nonces in Formularen

<form id="myform" action="mein-script.php" method="post">
<strong>Geben Sie ein Wort ein:</strong> <input type="text" name="word" />
<?php wp_nonce_field('meine_nonce') ?></form>

Das generiert ein hidden-field in Ihrem Formular, das die generierte Nonce enthält. Die WordPress-interne Funktion wp_nonce_field(1,2,3,4) verwendet vier Parameter:

1. Der erste Parameter ist optional, aber empfohlen. Er gibt der Nonce eine eindeutige Kennung.
2. Der zweite Parameter ist der Name des Feldes. Auch dieser Parameter ist optional, standardmäßig lautet er _wpnonce
3. Der dritte Parameter ist Boolean (true/false). ist er auf "True" gesetzt, sendet er den Referrer mit zur Überprüfung)
4. Der vierte Parameter ist ebenfalls Boolean, er prüft, ob das Feld korrekt gefüllt ist und stoppt bei Bedarf.

Das generierte hidden-field sollte so aussehen:

<input id="_wpnonce" type="hidden" name="_wpnonce" value="d6d71w4664" />

Jetzt haben wir zu prüfen, ob alle Werte vorhanden sind und stimmen, bevor das Formular verarbeitet wird:

if (!wp_verify_nonce($_POST['_wpnonce'],'meine_nonce') ) {
die('Oops, Ihre Nonce stimmt nicht');
}
else {
mein_inserter($_POST["word"]);
}

Zur Überprüfung verwenden wir die Funktion wp_verify_nonce(). Diese Funktion verwendet ebenfalls zwei Parameter: der erste ist der Wert des Nonce-Feldes, der zweite der Name der Aktion, den wir festgelegt haben. (Erster Wert in der Funktion wp_nonce_field()). Passt der Wert, wird das Formular verarbeitet (true), wenn nicht, wird die Verarbeitung abgebrochen (false).

Nonces in Links

Hin und wieder verwenden Sie eventuell einen Link anstelle eines Formulars, um eine Aktion auszulösen. Das sollte typischerweise so aussehen:
http://mysite.com/admin/scripts/mach-das.php?mach-das_id=231

Um eine Nonce dafür zu generieren, können wir diese Funktion verwenden:

$base_url = "http://mysite.com/admin/scripts/mach-das.php?mach-das_id=231";
$nonce_url = wp_nonce_url( $base_url, "mach-das_nonce");
echo "<a href="".$nonce_url."">Mach das</a>";

Der Link sollte dann in Etwas so aussehen:
http://mysite.com/admin/scripts/mach-das.php?mach-das_id=231&_wpnonce=d6f77f1364

Die Überprüfung erfolgt, wie bereits oben beschrieben:

if (!wp_verify_nonce($_GET['_wpnonce'],'mach-das_nonce') ) {
die('Oops, Ihre Nonce stimmt nicht.');
}
else {
mach-das($_GET["mach-das_id"]);
}

Alles gleichzeitig?

Wir müssen aber auf beide Aspekte gleichzeitig achten, es ist aber lange nicht so kompliziert, wie man meinen könnte. Nehmen wir als Beispiel einen Link, mit dem Kommentare gelöscht werden können:

$nonce_url = wp_nonce_url("http://mysite.com/scripts/delete_comment.php?comment_id=1451", "delete_comment_nonce");
echo "<a href='".$nonce_url."'>dispose of this comment</a>";

Hier überprüfen wir die Berechtigungen und die Nonce:

if (wp_verify_nonce($_GET['_wpnonce'],'delete_comment_nonce') AND current_user_can("edit_comment")) {
wp_delete_comment($_GET["comment_id"]);
}
else {
die('Oops, Ihre Nonce stimmt nicht, oder Sie haben nicht genügend Rechte.');
}

Datensicherheit und -Validierung

Unsere Arbeit ist soweit erstmal getan, aber wenn Sie schon eine Weile als Entwickler gearbeitet haben, dann wissen Sie - fertig ist man nie. Eine weitere Sicherheitsebene sollte verwendet werden, um unsaubere bzw.unsichere Daten von unserer Datenbank fernzuhalten. Diese Ebene nennt man dan Daten-Desinfektion (Sanitization).

Eine kurze Erklärung: Daten-Desinfektion bedeutet nichts anderes, als den Datensatz zu prüfen und bei Bedarf zu "reinigen", um verdächtige Inhalte gar nicht erst den Weg in die Datenbank finden zu lassen. Daten-Validierung bezieht sich auf ALLE Arten der Datenprüfung und wird daher landläufig auch bei Formularprüfungen (Feld ausgefüllt, richtiger Inhalt im Formularfeld...) verwendet. Dieser Aspekt der Datenprüfung ist zwar auch wichtig, wir wollen uns aber an dieser Stelle mehr mit den sicherheitsrelevanten Überprüfungen befassen.

Das wichtigste, wogegen wir unsere Datenbank absichern müssen,ist die SQL-Injection. Das ist eine Technik, die von Hackern angewendet wird, um Schwächen innerhalb der Datenbank(struktur) aufzuspüren und natürlich auszunutzen. Auch hier natürlich ein Beispiel:
Jemand besucht Ihre Webseite und und tippt in die Suchmaske das Wort Elefant'. Zu beachten ist hier das Apostroph am Ende des Wortes. Ein Suchscript arbeitet jetzt wie folgt:

SELECT ID, post_title FROM wp_posts WHERE post_title LIKE '%elephant'%'

In diesem Beispiel wird die Suche mit einer Fehlermeldung abgebrochen, da das Apostroph zuviel ist, und as nachfolgende damit nicht geschlossen ist. Passieren kann hier erstmal nichts, da das Script ja mit einer Fehlermeldung abgebrochen wurde, aber derjenige der diese Suche ausgeführt hat, weiß jetzt natürlich, daß hier keine Datenvalidierung ausgeführt wird. Da können die Probleme beginnen.
In manchen Fällen kann auch SQL selbst gefährlich agieren, oder dem potentiellen Hacker mehr Informationen liefern, als Ihnen lieb sein kann. Auch hier ein Beispiel:

Als Seitenadministrator versuchen Sie über eine Suchfunktion die passende Email-Adresse zu einem Benutzernamen zu finden:
"Normale" Abfrage:

SELECT user_email FROM wp_users WHERE user_login = 'danielp'

Wenn unser Hacker nun eine SQL Injection ausführen will, könnte er ein OR 1=1 in das Suchfeld eingeben, was in folgender Abfrage enden würde:

SELECT user_email FROM wp_users WHERE user_login = '' OR 1=1 ''

Als Suchergebnis erhält er nun ALLE Email-Adressen aus der Datenbank, denn er erhält die Adressen, bei denen der Benutzername leer ist (user_login=''), und er erhält alle Adressen, bei denen 1=1 ist (OR 1=1). Da 1=1 immer TRUE zurückgibt, werden alle Adressen ausgeliefert.

Es gibt zwei Wege, dieses Problem zu beseitigen, beide zu verwenden ist der sicherere Weg.
In Runde 1 überprüfen wir die Daten in den Formularfeldern auf korrekte Eingabe. Wenn eine Email-Adresse angegeben werden soll, können wir dafür sorgen, daß auch nur eine Email-Adresse eingetragen ist. Das ist zu prüfen, bevor das Formular abgesendet werden kann.
In Runde 2 werden alle Zeichen entfernt, die die datenbankabfrage stören könnten. Dazu gehört typischerweise das Entwerten von Apostrophen und Anführungszeichen per Backslash (\"Diese Zeichen sind entwertet...\"), um die Datenbankabfrage sauber zu halten. Für den Fall, daß ohne ein Framework (gleich welcher Art) gearbeitet wird, würde man hier addslashes() oder ähnliches verwenden, WordPress verwendet hier einen eigenen Weg.

Datenvalidierung in WordPress

Um mit der datenbank zu kommunizieren, verwendet WordPress die Klasse $wpdb. Alles darüber können Sie in dem Artikel WordPress Essentials: Interacting With the WordPress Database. (engl.) → lesen. Die Klasse bietet eine ganze Reihe an Möglichkeiten, Ihre Sorge um mögliche SQL_Injections zu vermindern.

Bevor wir uns tiefer in die Materie stürzen sehen wir uns natürlich wieder ein Beispiel an, um zu sehen, wie die Klasse arbeitet:

// einfache Datenbankabfrage
$wpdb->query("DELETE FROM wp_users WHERE user_id = 5");
// Abfrage für eine Zeile Daten
$posts = $wpdb->get_col("SELECT post_title FROM wp_posts WHERE post_status = 'publish' ORDER BY comment_count DESC LIMIT 0,10");
// Abfrage für eine Spalte daten
$post = $wpdb->get_row("SELECT * FROM wp_posts WHERE ID = 1453");
// Mehrere Zeilen und Spalten
$posts = $wpdb->get_results("SELECT ID, post_title, post_date FROM wp_posts WHERE post_type = 'publish' ORDER BY post_date DESC LIMIT 0, 12 ");
// Einzelner Wert
$author_id = $wpdb->get_var("SELECT post_author FROM wp_posts WHERE ID = 2563");
// Eintrag in Datenbank einfügen
$wpdb->insert("wp_postmeta", array("post_id" => 2323, "meta_key" => "favorite_count", "meta_value" => 224 ), array("%d", "%s", "%d"));
// Eintrag in Datenbank updaten
$wpdb->update("wp_postmeta", array("meta_value" => 225), array("meta_key" => "favorite_count", "post_id" => 2323), array("%d"), array("%s", "%d"));

Die insert() und update()-Methoden sind gute Hilfsmethoden, weil sie, abgesehen von einer gewissen Modularisierung Ihrer Datenbank-Interaktionen auch die Datenüberprüfung übernehemen. Falls Sie die allgemeinen query()-Methoden verwenden wollen, müssen Sie die Datenvalidierung selbst übernehmen.
Der einfachere Weg ist die Nutzung der escape()-Methode:

$data = $wpdb->escape($_POST[about_me]);
$wpdb->query("UPDATE wp_usermeta SET meta_value = '$data' WHERE meta_key = 'description' AND user_id = 154 ");

Ein etwas schwierigerer, aber besserer Weg ist dieprepare()-Methode: Ein Beispiel aus dem WordPress-Codex → demonstriert das perfekt:

$metakey = "Harriet's Adages";
$metavalue = "WordPress' database interface is like Sunday Morning: Easy.";
$wpdb->query( $wpdb->prepare(
"
INSERT INTO $wpdb->postmeta
(post_id, meta_key, meta_value)
VALUES ( %d, %s, %s)
",
10,
$metakey,
$metavalue
) );

Mehr Schutz durch weitere Daten-Desinfektion

Sanitization ist ein ziemlich großes Thema und erfordert einige Zeit, um es zu meistern. Denn jetzt werden Sie vor allem damit beschäftigt sein, zu bestimmen welche Zeichen erlaubt, welche verboten sind und müssen Wege finden, letztere zu analysieren. Einige allgemeine Anforderungen an Sie sind das Herausfiltern von HTML aus Adressen, Zahlen aus Strings filtern, Email-Adressen validieren und so weiter. Allerdings werden Sie sicherlich Ihre eigenen Lösungen verwenden müssen, um komplexere Anforderungen zu meistern.
Im Abschnitt Weiterführende Literatur → finden Sie mehr zu diesem Thema.

Abschließende Gedanken

Das Ausmaß an Aufwand, eine Webseite abzusichern, kann nicht in nur einem Buch behandelt werde, gaz zu schweigen von einem Artikel. Es gibt noch Unmengen Wege und Methoden, die hier nicht aufgeführt sind, wie z.B. Passwort-Verschlüsselung, Salts und so weiter. Aber wenn Sie die hier angeführten Methoden auf Ihren Webseiten einsetzen, haben Sie schon ein gutes Stück auf dem Weg zu einer sichereren Webseite getan.

Weiterführende Literatur

Dieser Artikel ist eine Übersetzung des des Posts "Securing your wordpress site" vom Smashing Magazine →

Erfolgreiche Webmaster wissen aber, dass Banner öfter angeklickt werden, wenn sie direkt im Text selbst eingebettet sind. Dafür gibt es in WordPress verschiedene Möglichkeiten, von denen hier zwei näher beleuchtet werden sollen.

Eine Möglichkeit ist, das <!-- more--> Tag durch ein Banner zu ersetzen. Für den Blogger, der dieses Tag häufig benutzt, ist dies ein relativ unkomplizierter Weg, seine Banner innerhalb seines Contents zu schalten. Dazu sind lediglich die folgenden Zeilen in der functions.php zu ergänzen:

function more_ad($content) {
if ( !is_single() )
return $content;
$banner = '<center>
<script type="text/javascript"><!--
google_ad_client = "pub-XXXXXXXXXXXXXX";
google_ad_slot = "XXXXXXXXXX";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</center>';
$content = preg_replace('/<span id\=\"(more\-\d+)"></span>/', $banner, $content);
return $content;
}
add_filter( 'the_content', 'more_ad' );

Wichtig: Natürlich die beiden XXX-Blöcke durch die eigenen ID’s ersetzen…

Auf diese Weise wird in der single.php an der Stelle, an der das <!--more--> Tag gesetzt ist, das Banner eingeblendet.

pro: Das Banner wird immer eingeblendet, wenn das <!--more--> Tag gesetzt ist, weitere Anpassungen sind nicht nötig.

contra: Das Banner wird nur eingeblendet, wenn das <!--more--> Tag gesetzt ist, die Position im Content ist abhängig von der Position des Tags.

Variante zwei ist die Einbindung in den Content mittels [shortcode], eine Variante, die eine größere Flexibilität in der Positionierung des Banners gewährleistet. Auch hier ist ein Eintrag in der functions.php des Themes notwendig:

function my_ad() {
return '<div id="my_adsense">
<script type="text/javascript"><!--
google_ad_client = "pub-XXXXXXXXXXXXXX";
google_ad_slot = "XXXXXXXXXX";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div>';
}
add_shortcode( 'my_adsense', 'my_ad' );

Wichtig: Natürlich auch hier die beiden XXX-Blöcke durch die eigenen ID’s ersetzen…

Der Aufruf erfolgt dann mittels dem Shortcode [my_adsense]. In diesem Beispiel ist der AdSense-Code von einer <div id> umgeben, diese kann in der style.css nach belieben formatiert werden.