bueltge.de [by:ltge.de] - Kommentare zu: WordPress 2.6 erlaubt das Auslagern von wp-content

Von: Frank Bültge

Frank Bültge — Thu, 08 Dec 2011 22:03:11 +0000

@TOm: eventuell ist dein Webspace so, dass du auf diesen Ordern nicht öffentlich zugreifen kannst.

Von: Tom

Tom — Thu, 08 Dec 2011 19:51:24 +0000

Die Datei ist in dem Verzeichnis vorhanden ich habe den Ordner von Lokal 1 zu 1 auf den Webspace gezogen. Wie ist das mit Rechtsprobleme gemeint. Sollte ich da meinen Hoster eventuell kontaktieren?

Von: Frank Bültge

Frank Bültge — Thu, 08 Dec 2011 19:28:19 +0000

@tom: die Funktion file() kann nicht zugreifen - Unable to access; Rechteprobleme oder Verfügbarkeit?

Von: Tom

Tom — Wed, 07 Dec 2011 19:23:56 +0000

Ich hätte eine kleine Frage zu dem Umbenennen des Ordners. Wenn ich mein das wp-content Verzeichnis umbenenne und anschließend die Zeile Code mit meinen Einstellungen in die wp-config.php kopiere funktioniert Lokal in der Testumgebung alles prima nur wenn ich auf dem Server bzw. Webspace das selbe machen möchte geben mir entsprechende Plugins eine Fehlermeldung aus, die lokal eben nicht auftreten.

Hier ein Beispiel:
Warning: file() [function.file]: Unable to access /var/www/web/html/core/wp-content/plugins/mingle-forum/wpf-main.php in /var/www/web/html/core/static/plugins/mingle-forum/fs-admin/fs-admin.php on line 348
Das Verzeichnis shabe ich in diesem fall in "static" umbenannt. Wo könnte der Fehler liegen ich werde nämlich nicht schlau daraus :/

Von: Detlef

Detlef — Thu, 27 Oct 2011 10:30:14 +0000

Hallo Frank,
egal was ich im Zusammenhang mit WP bei Google suche, ich lande zu 95% auf deiner Seite. Danke für deine Mühe...
Detlef

Von: Venooze

Venooze — Wed, 30 Dec 2009 06:52:35 +0000

Ich hatte einen Schreibfehler in der wp-config.php.

if ( !defined('ABSPATH') ) define('ABSPATH', dirname(__FILE__) . '/'); require_once(ABSPATH . 'wp-settings.php');

Hiermit funktioniert es wieder. Habe so lange bei Google gesucht und hier die Lösung gefunden.

Von: Vanessa

Vanessa — Fri, 27 Nov 2009 21:34:32 +0000

$locale = get_locale();
$locale_file = WP_LANG_DIR . "/$locale.php";
if ( is_readable($locale_file) )
require_once($locale_file);

Danke für diesen Tip. Danach habe ich gesucht

Von: Xel

Xel — Sat, 25 Jul 2009 22:38:27 +0000

Ich mag es nicht verstecken als Sicherheitsfeature anzusehen.
Das ist wie mit Verschlüsselung... ein Verschlüsselungssystem ist nicht sicherer nur weil es nicht öffentlich ist.

Klar sehe ich den Sinn dahinter. Aber aufgrund der vielen WP Installationen auf Servern bei denen PHP keine Schreibrechte hat, außer wenn man die Rechte auf 777/666 setzt, reißt das eigentlich nur noch mehr Sicherheitslücken, weil dann tausende WP Installationen einen Ordner mit Schreibrechten haben, in dem Dateien mit Schreibrechten sind, welche tatsächlich von WP genutzt werden (der Plugin Ordner und die Plugins...) und das für jeden Nutzer auf dem System eben schreibbar ist.

Wenn einmal ein Angreifer über einen beliebigen auf dem gleichen Server gehosteten Account einsteigt, kann er dann potentiell alle Plugins aller (noch so sicheren) Installationen beliebig verändern. Eine Vorstellung die mir nicht gefällt... Sorry.

Von: Helge Staedtler

Helge Staedtler — Sat, 25 Jul 2009 20:48:58 +0000

@codestyling: Hmm, gute Idee das mit dem Ausstieg. Werde ich bei mir mal einbauen in Kombination mit Abfrage einer Konstanten die da sein muss von meinem Plugin. Danke schön!

Ich dachte was die Ordner der deaktivierten Plugins angeht einfach an einen Ordnernamen, der nicht guessable ist und dessen Name in den wp_options dann liegt. So weiß wordpress wie der Ordner heißt, aber ein Angreifer kann schonmal vergessen an irgendwelche Lücken abgeschalteter Plugins zu gelangen. =)

Von: codestyling

codestyling — Sat, 25 Jul 2009 19:30:53 +0000

Das mit dem Ausstieg aus dem Plugin sieht zumindest bei mir immer so aus:

if (!function_exists ('add_action')) {
	header('Status: 403 Forbidden');
	header('HTTP/1.1 403 Forbidden');
	exit();
}

Wenn man die Ordner komplett "virtualisieren" wollte, dann könnte man das nur so ähnlich angehen, wie bei einem Apache Reverse Proxy und müsste die Url's in jeder Seite zusätzlich mit umschreiben lassen. Machbar wäre das schon, aber der Aufwand und die Pflege steht in keinen Verhältnis zum erhofften Nutzen, wenn man per POST Parameter dann doch noch irgendwo "einsteigen" könnte, wo eine Sicherheitslücke klafft.

Von: Xel

Xel — Sat, 25 Jul 2009 15:58:08 +0000

Naja, du hast ja generell mal Recht.
Aber es ist halt auch immer das Problem, dass PHP nicht unbedingt ausreichend Rechnte hat um sowas zu realisieren. Bei mir ja, da läuft suExec, aber bei vielen eben nicht. Und wie soll das mit dem "geheimen" Verzeichnis funktionieren? Für jede Installation ein eigenes? Man könnte auch eine .htaccess im wp-content mitliefern, die den Aufruf von Dateien im Template und Pluginverzeichnis verbietet und nur Aufrufe auf Dateien in Unterordnern namens images, scripts, ajax sowie den Aufruf von css, js und den verschiedenen Bildformaten zulässt. Damit wären zumindest die üblichen Dateien, die man nie von Hand aufrufen muss effektiv geschützt.

Was für Plugin-Autoren sinnvoll wäre ist ganz oben in jeder Datei eine Konstante abzufragen und dann per exit auszusteigen, wenn die nicht definiert ist. Dann kann die php-Datei nicht mehr direkt aufgerufen werden. Ist aber leider ne Sache die der Plugin-Autor bedenken muss...

Von: Helge Staedtler

Helge Staedtler — Sat, 25 Jul 2009 14:59:05 +0000

@Xel: Gut das mit dem Massenangriff stimmt. Wobei ich jetzt als Massenangreifer dennoch oder gerade deshalb mein Attack-Script vorher möglichst intelligent gestalten würde, denn sonst falle ich auf einer "Blogfarm" die ich mir aussuche bestimmt als erste auf.

Aber es stimmt schon, dass es einige Angreifer gibt, denen das völlig egal ist, die versuchen einfach blind irgendwelche Dateien abzurufen in der Hoffnung schon irgendwas zu treffen. Wenn ich also ein Mass-Attacker wäre, dan würde ich prinzipiell nur auf Angriffspunkte gehen, die NICHT variabel sind sondern in jeder Zielinstallation eine Konstante darstellen. Vollkommen klar, dass ein wp-content da ein Einstiegspunkt ist. Genauso wie alles was im root-dir des Blogs liegt.

Was ich z.B. nicht kapiere ist, wieso ein DEAKTIVIERTES Plugin überhaupt noch im directory plugins weiter liegen bleibt und nicht verschoben wird. Da müsste es ein geheimes directory für geben, denn so wie es jetzt ist kann selbst über bereits abgeschaltete plugins deren .php-filenames man kennt ein angriff gefahren werden. hab ich bei der Entwicklung meines eigenen plugins gemerkt, das AUS nicht gleich wirklich AUS heißt!

Von: Frank Bültge

Frank Bültge — Sat, 25 Jul 2009 14:33:39 +0000

@Helge: definitiv richtig, wobei der Scan des Themes und Backend mit Hilfe von Plugins erfolgen kann, Scan des Themes kann WP-Scanner leisten.

Von: Xel

Xel — Sat, 25 Jul 2009 12:34:31 +0000

@Helge Staedtler:
Naja - es gibt zwei verschiedene Arten Angriffe.
Das eine ist der Gezielte und das andere der Massenangriff.
Gegen einen Gezielten kann man sich faktisch nicht schützen, weil irgendwo immer irgend eine Lücke sein wird. Man kann nur versuchen ihn so weit zu erschweren, dass er sich nicht lohnt, weil er zu teuer oder zu gefährlich wird.

Gegen einen Massenangriff kann man sich schützen in dem man vom Standardfall abweicht. Denn die wenigsten Massenangreifer gucken vorher in den Blog und passen Variablen an. Meist versucht der Angriff einfach nur allgemein möglichst viele Blog-Standardinstallationen zu Fall zu bringen und nutzt dazu einfach häufig verwendete Plugins. Dort wird dann einfach der Angriff gefahren ohne zu gucken ob das Plugin überhaupt existiert. Es wird ja teilweise nicht mal geguckt ob die Seite überhaupt mit dem CMS erstellt wurde, welches man angreift. Ich hab in den Server-Loggs ständig Joomla-Angriffe obwohl ich gar kein einziges Joomla habe.

Von: Helge Staedtler

Helge Staedtler — Sat, 25 Jul 2009 09:17:45 +0000

Hmm, ich hab mir jetzt die ganzen Kommentare zu dem Aspekt Sicherheit und wp-content durchgelesen, aber *Klick* hat es bei mir nicht gemacht. Ich meine wenn ich wp-content oder das plugins-directory jetzt umbenennen kann was soll das an Sicherheit bringen? Jeder der einen Systemangriff plant lässt sich doch erstmal eine normale Blogseite liefern. In dem Moment, wo auch nur ein Bild aus einem Theme (dessen Ordner ja in wp-content/themes liegt) geladen wird ist die Sache bzw. der Pfad klar, wie "wp-content" auf diesem Blogsystem heißt und wo es liegt.

Der Sicherheitsgewinn ist gleich Null! Wenn ich 'nen Angriff planen würde, würde ich als erstes eine Pfadanalyse machen, denn auffallend häufige Fehler bei der Ressourcen-Abfrage und Auslieferung des Webservers fallen dem Admin unter Umständen verdächtig auf (Errorlog schwillt an, Performanz lässt nach).... und als Angreifer will man das ja wirklich als letztes, auffallen.

Für mich ist die deutlich größte Sicherheitslücke derzeit das Theme. Themes werden von zig verschiedenen Seiten angeboten, haben teilweise wirklich krasse Fehler und eröffnen einem Angreifer - der es schafft sein Theme zu verbreiten durch das trojanische Pferd "Sexy Theme" - Vollzugriff auf das Blog. Erschwerend kommt hinzu, dass das Theme soviele .PHP-Files mitbringt. Da ist es schwer einen ersten Sicherheitscheck mal eben so zu machen. In ein plugin-File schau ich da schon eher vorher mal rein.

Durch die Theme-Hintertür ist auch in meinem Blog der REMV.php-Angriff gelaufen und das Ding fand ich wirklich intelligent programmiert, weil es sich durch ständiges Hin-und-her-Kopieren und das Umbenennen von Themedateien in unsichtbare Dateien erfolgreich getarnt hat und nur NICHT-Admin-Usern gegenüber auffällig agiert hat. Das Ding zu erkennen und loszuwerden war wirklich anstrengend!

Ich fände einen Theme-Test sinnvoll, der zumindest mal alle Files (auch vermeintliche Bild-Dateien, die möglicherweise php enthalten) auf verdächtigen Code hin untersucht (z.B. auf merkwürdige externe URLs hin von denen irgendwas nachgeladen wird). Auch die Konformität für Einbindungshooks wp_head, wp_footer, wp_meta usw. wäre mal ein Anfang die Qualität der Themekompatibilität deutlich zu erhöhen. Dafür muss man sonst mächtig Aufwand treiben für Workarounds.

Meine 2 Cent.

Von: Wordpress wp-content auslagern Sicherheitsrisiko? - Server Support Forum

Wordpress wp-content auslagern Sicherheitsrisiko? - Server Support Forum — Mon, 23 Feb 2009 00:05:02 +0000

[...] Zitat von Mordor Ich verstehe also auch nicht ganz, wie das generell funktionieren soll?! Darauf f

Von: Sicherheit / WordPress absichern

Sicherheit / WordPress absichern — Wed, 01 Oct 2008 16:14:06 +0000

[...] zurückgreifen können. Ein ausführliches Tutorial hierzu ist mit Frank Bueltges Artikel WordPress 2.6 erlaubt das AUslagern von wp-content zu [...]

Von: Schusterjunge» Blogarchiv » Update auf WP 2.6.1

Schusterjunge» Blogarchiv » Update auf WP 2.6.1 — Tue, 02 Sep 2008 22:55:29 +0000

[...] Die wp-config.php kann man jetzt auch eine Ebene höher einordnen. Sinnvoll, wenn diese Ebene im nicht-öffentlichen Bereich des Servers liegt. Auch der Ordner wp-content, in welchem die Plugins, Themes und Uploads liegen, kann nun ausgelagert und umbenannt werden. Eine Anleitung dazu findet sich hier. [...]

Von: Wordpress 2.6 RC1 erschienen - Update, Betrachtung, Standard, Version, Deaktivierung, Wordpress, jQuery, “Aktive”, Checkboxen, Mehrfachanwahl, Plugins”, Aufteilung, Galerie, Gravatare, Möglichkeiten, Drag, Drop, Umstrukturierung, Plugin-Bereiches;,

Mon, 18 Aug 2008 16:40:14 +0000

[...] wp-content kann verschoben werden … mehr [...]

Von: Wir fahren mit Wordpress 2.6 | Promoter Blog

Wir fahren mit Wordpress 2.6 | Promoter Blog — Tue, 05 Aug 2008 10:19:22 +0000

[...] wp-content kann verschoben werden … mehr [...]

Von: Xel

Xel — Tue, 29 Jul 2008 23:24:57 +0000

Hmm interessant:

In der i10n.php (in wp-includes) steht:
$mofile = ABSPATH . LANGDIR . "/$locale.mo";

LANGDIR wird, sofern es nicht bereits definiert wurde in wp-settings.php definiert:




	define('WP_LANG_DIR', WP_CONTENT_DIR . '/languages'); // no leading slash, no trailing slash, full path, not relative to ABSPATH

	if (!defined('LANGDIR')) {

		// Old static relative path maintained for limited backwards compatibility - won't work in some cases

		define('LANGDIR', 'wp-content/languages');

	}

Wenn ich das jetzt nicht falsch sehe, bedeutet das, dass WP_LANG_DIR - der eigentlich richtige Pfad - garnicht für die Auswahl des mo-Files verwendet wird.

Verwendet wird es allerdings ein einziges Mal in der wp-settings.php (und laut meiner Suche in keiner weiteren WordPress Datei!):



$locale = get_locale();

$locale_file = WP_LANG_DIR . "/$locale.php";

if ( is_readable($locale_file) )

	require_once($locale_file);

Wobei anzumerken ist, dass in der aktuellen deutschen 2.6 keine de_DE.php oder ähnliches im languages Verzeichnis liegt und dementsprechend dort auch keine Möglichkeit besteht um bereits im Vorraus LANGDIR passend zu definieren.

Insgesamt ein Kuriosum, aber es wundert mich jedenfalls nicht, dass bei verschobenem/umbenanntem wp-content Ordner die Sprache nicht mehr passt.
Möglich natürlich, dass die de_DE.php Datei fehlt und das der Fehler ist (daran glaube ich aber nicht, die war für Version 1.5 gedacht, als noch keine mo Files verwendet wurden.
Wahrscheinlicher ist, dass in der i10n.php vergessen wurde den neuen Pfad zu verwenden, sofern dort eine passende Datei vorhanden ist und nur ansonsten im wp-content/languages Pfad nachzuschauen.
Mathias:

Zu deiner Beruhigung:

Sofern im wp-content-Verzeichnis kein Ordner languages gefunden wird, wird er Ordner in wp-includes verwendet (allerdings ohne zu prüfen, ob er existiert).

Von: Frank Bültge

Frank Bültge — Tue, 29 Jul 2008 22:52:39 +0000

@Mathias: seit Version 2.5 gehört sie in den Ordner wp-content/languages/

Von: Mathias

Mathias — Tue, 29 Jul 2008 18:13:48 +0000

OK, mein Fehler. Ich habe deinen Kommentar falsch zugeordnet. Zum Thema Sprachdatei bliebe aber zu sagen, dass diese eigentlich in den Ordner "wp-includes/languages" gehört. Was hat sie in "wp-content" zu suchen?

Von: Xel

Xel — Tue, 29 Jul 2008 11:14:08 +0000

Mathias: Mein Kommentar bezog sich auf

Ich bin komplett neu in WordPress und ins Bloggen eingestiegen. Nachdem ich den Tipp angewendet hatte und ein Theme und zwei Plugins angepasst habe, musste ich feststellen, dass WP jetzt nur noch Englisch spricht in Admin und Public. Ich hab jetzt erstmal den Ordner mein-inhaltsordner/languages nach wp-content/languages kopiert, jetzt ist's wieder Deutsch.

Ist aber sicher nicht der richtige Weg.

und da ich mal stark davon ausgehe, dass das richtig definiert wurde (ansonsten würden sämtliche Plugins und Themes ja garnicht funktionieren bzw nicht mal gefunden werden, was sicherlich eher aufgefallen währe, als das der Blog auf english ist), bleibt eigentlich nur noch die Möglichkeit, dass WP die Sprachdatei noch direkt sucht und nicht auf die Änderung des wp-content verzeichnisses reagiert.

Kann natürlich sein, dass ich mich täusche.

Hat inzwischen eigentlich mal jemand ausprobiert, was passiert, wenn der wp-content außerhalb des Webroot ist? Glaub kaum, dass das funktioniert.

Von: Mathias

Mathias — Mon, 28 Jul 2008 19:10:12 +0000

Wird möglicherweise n bislang unbekannter Bug sein

Das glaube ich nicht. Wenn ich mir die "wp-settings.php" anschaue, wird ziemlich am Schluss WordPress initialisiert. Das heißt, wenn bis dahin die notwendigen Konstanten nicht deklariert wurden, spielt es danach auch keine Rolle mehr.

denn die Betas kommen ja eigentlich nur auf Englisch raus bzw. müssen sogar per SVN gezogen werden

Ich habe mir einmal die Mühe gemacht, die SVN 2.5 komplett neu zu übersetzen. Damals gab es offiziell nur die Sprachdatei für WP 2.3.x. Die konnte man aber nicht nehmen, denn die Unterschiede zur SVN-Version waren einfach zu groß. Und (mit Verlaub!) sonderlich begeistert war ich vom Sprachstil in der deutschen Datei ohnehin nicht.
Seitdem kann ich nicht klagen. Bei mir läuft die SVN 2.7 im Livebetrieb in deutscher Sprache.