WordPress 2.6 erlaubt das Auslagern von wp-content

bueltge.de [by:ltge.de] wird von Frank Bültge geführt, administriert und gestaltet. Alle Inhalte sind persönlich von mir ausgewählt und erstellt, nach bestem Gewissen und Können, was die Möglichkeit von Fehlern nicht ausschließt.

Kommentare

  
  1. Micha sagt:

    Geht das Umbennen des wp-content Ordners auch?

  2. Mathias sagt:

    Und gleich einen Bug gefunden:
    define( 'WP_CONTENT_URL', get_option('home') . '/wp-content');
    Ich musste "home" durch "siteurl" ersetzen, weil ich die WordPress-Software in einem Unterverzeichnis und nicht im Domain-Hauptverzeichnis habe. Mit "home" stimmt der Pfad zur Stylesheetdatei des Themas nicht mehr. Mit dem Patch geht es dann wieder.

  3. @Micha: ja, erweitere es mal im Text.

  4. Lothar Baier sagt:

    Mir ist noch nicht ganz klar, warum sich durch ein Verlagern oder Umbenennen des Verzeichnisses die Sicherheit von WP erhöhen sollte. Im Source der ausgelieferten Seite ist doch nach wie vor der Name des Verzeichnisses im Klartext enthalten, z. Bsp. im Link zum Stylesheet.

    Dafür werden aber jede Menge Themes und Plugins nicht mehr laufen, die das wp-content-Verzeichnis fest verdrahtet haben. Nah, das wird ein schönes Geschrei geben, wenn die ersten Noobs nach dem Erscheinen von WP 2.6 mit dem Verzeichnisnamen herumexperimentieren.

  5. @Lothar Baier: Daher ja der Hinweis, auch in älteren Versionen von WP war die Richtlinie: Nutze Konstanten und Funktionen und verweise nicht auf Verzeichnisse.

    Damit kann man aber das Verzeichnis eine Ebene tiefer legen und so vor dem Zugriff von Außen schützen. Das Umbenennen erschwert nur den Zugriff, weil Scripte erst mit dem Namen gefüttert werden müssen. Allerdings kann man nun einfacher den Zugriff auf Theme, Plugin etc. verstecken.

  6. schreiben sagt:

    Das ist doch mal ein sinnvolles Feature.
    Damit dürfte sich WordPress weiter in Richtung besserer Modularität entwickeln.

  7. Reicht Tip 10 in Deiner Empfehlungsliste auf http://wordpress-buch.bueltge.de/wordpress-sicherer-machen/30/ nicht eigentlich aus?

  8. @André Wegner: Nein, weil dann der Zugriff auf Plugins und Themes trotzdem noch bleibt und so ist, wie es 99% aller WP-User haben. Plugins und Themes sind meist die Sicherheitslücke und wenn man den Ordner wp-content eine Ebene tiefer ablegt, dann ist dieser von Außen nicht erreichbar und so viel sicherer.
    Das Umbenennen ist nicht so sicher, trägt aber zu mehr Sicherheit bei.

  9. Argh, ich hatte mich verlesen und dachte es sei nur die wp-config.php gemeint. Ist klar jetzt.

  10. gr4y sagt:

    Also ich fände es hochgradigst sinnvoll wenn dies mit dem wp-admin passieren könnte. Den Sinn wieso man wp-content verschieben und umbenennen kann versteh ich nicht. Was liegt im wp-content das WordPress angreifbar macht?

  11. Heiko sagt:

    Hmm, mit dem Verlagern raus aus der öffentlich erreichbaren Domain wird es aber nicht ohne Patches in den rewrite Rules gehen, CSS oder JS Files aus Plugins oder Themes ausliefern zu lassen. Was mir bei deiner Ausführung fehlt ist die Aussage, ob WP 2.6 das "automatisch" macht oder ob ich die .htaccess selbst dazu bringen muß.
    Beispiel:

    \www-domain-root\wp-admin
    \ausgelagert-wp-content\plugins

    ausliefern von z.B.: http://www.xyz.de/../ausgelagert-wp-content/plugins/meins/style.css

    Das verhindert ja normal der Server (sinn der Sache). Also wie bringt man dann ein Plugin dazu, ein Stylesheet so auszuliefern ?

  12. @gr4y: Plugin und Theme, die unsicherste Stelle im System.

  13. @Heiko: alles was in wp-content ist, wird gezogen, automatisch. Themes und Plugins müssen noch immer in diesem Ordner bleiben, wo immer er auch liegt. Im aktuellen Release habe ich noch Fehler gefunden, allerdings ist es ja auch nicht frei gegeben und diese Aktion zeiht viel nach sich in den klassischen Funktionen.
    Mit Plugins konnte man schon immer auf das Verzeichnis Plugins zugreifen mir Konstante PLUGINDIR, alternativ bietet sich __FILE__ an, weil damit das File an sich den Pfad vorgibt. Wenn also die PHP-Datei auf eine style.css dieses Plugins verweist, dann kann man entweder mit PLUGINDIR . '/meins/style.css' zugreifen oder mit str_replace( ABSPATH, '', dirname(__FILE__) . '/style.css' ), siehe auch Text im Beitrag.

  14. gr4y sagt:

    @Frank: Okay. Dennoch würde ich meinen das man sehr gut beraten wären wenn
    wp-admin genauso wie wp-content verschoben würde.

  15. @gr4y: mit Sicherheit; es wäre wünschenswert, wenn man alle drei Ordner frei definieren könnte. Das gibt ungemein Freiheit und macht die Administration einfacher und unzugänglicher bei Auftragsarbeiten.

  16. Heiko sagt:

    @Frank:

    
    

    Wie soll das gehen, wenn wp-content außerhalb des Domain Root liegt ?
    Dann kommt ja der Browser nicht ran !

  17. @Heiko: Der Zugriff wird über die index.php und load.php im root erlaubt und gelöst. Man kann doch auch die config unterhalb des root halten und die Zugriffe sind möglich. IM Admin-Bereich kümmert sich die Klasse WP_Filesystem_Base um die Zugriffe.

  18. Heiko sagt:

    Hi, ich hab im trunk/wp-settings.php das als neu gefunden:

    276 if ( !defined('WP_CONTENT_URL') )
    277 define( 'WP_CONTENT_URL', get_option('home') . '/wp-content'); // full url - WP_CONTENT_DIR is defined further up

    Alles was ich das sehen kann erlaubt nicht, aus dem Domainroot raus zu gehen. Nur innerhalb der Domain kann man das umbenennen und in den 30ten Subpfad des Domainroots packen. Aber keine Chance nach diesen Code Änderungen, das ausserhalb der Domain zu haben!

  19. Mathias sagt:

    Frank, zum Thema Sprachdatei schreibst du, dass jetzt der Code str_replace( ABSPATH, "", dirname( __FILE__ ) ) nötig ist. So ähnlich sah mein Code bisher immer aus, um das Verzeichnis des Plugins zu ermitteln. Aber jetzt bei WP 2.6 funktioniert es nicht mehr. Wenn ich nur, wie früher, bei "wp-content/plugins/mein-plugin-ordner" anfange, wird mein Plugin nicht mehr übersetzt. Die Funktion get_template_directory liefert mir übrigens auch den kompletten Pfad "/home/mathias/..." usw. zurück.

  20. Putzlowitsch sagt:

    Mal von den Sicherheitsaspekten abgesehen wäre es generell eine gute Idee, alle WP-Basisverzeichnisse über Konstanten definierbar zu gestelten, auch wp-include. Somit könnte man sehr einfach mehrere WP-Installationen nur durch ein Update der gemeinsam benutzten Basisverzeichnisse auf dem aktuellen Stand halten.

  21. sehr feine funktion.
    habe so einen ähnlichen wunsch schon im entwicklungsforum von wordpress geäußert. finde gut dass jetzt mal mehr in richtung sicherheit hingearbeitet wird.

  22. @Mathias: kann ich so nicht bestätigen, meine Lösung mit Zugriff auf __FILE__ klappt auch unter 2.6 tadellos, nicht mehr klappt /wp-content/...

  23. Mathias sagt:

    Sehr komisch, wenn ich deinen Weg nutze, bekomme ich als Ergebnis nur die Ordner ab "wp-content". Ich habe die Revision 8030 im Test, und ich muss tatsächlich ganz oben anfangen, bei "/home/.../blog/wp-content/...". Ich musste die Funktion in meinen Plugins umgestalten:
    private static function getplugindirectory( $absolute = false ) {
    $me = str_replace( "\\", "/", dirname( __FILE__ ) );
    if ( $absolute === true ) {
    $me = get_settings( "siteurl" ) . "/" .
    str_replace( str_replace( "\\", "/", ABSPATH ), "", $me );
    }
    return $me;
    }
    sonst wird die Sprachdatei ignoriert. Ich nehme die Funktion auch zum Laden der Stylesheets (darum der Parameter), und ich habe noch einen Testblog auf einem Windowsserver (darum das Hantieren mit \ und /).

  24. @Mathias: Das Problem ist der Windows-Server. gettext hat damit Probleme, nicht WordPress.

    Bei der Pfadangabe in bindtextdomain() ist zwingend ein abschließender "/" erforderlich (im Bsp. unten also bindtextdomain("test", "./locale/"), getestet mit Apache/2.2.6 (Win32) PHP/5.2.5 unter WinXPSP2). 
    

    siehe phpbar.de

    Habe es nie getestet, aber mal irgendwo aufgeschnappt, eventuell hilft es.

  25. Mathias sagt:

    Frank, mein eigener Blog läuft auf einem Linuxserver. Und da funktioniert es nicht, wenn ich den Pfad bei "wp-content" beginne.

  26. @Mathias: Ich kann nur sagen, dass es unter WP 2.6bleeding bie mir wunderbar klappt, wie oben angegeben. Mehr habe ich nicht drin. Eventuell kannst du mal eines meiner Plugins nutze und testen, eventuell ©Feed, das hatte ich extra eben noch mal in 2.6 aktiv.

  27. Mathias sagt:

    Ich glaube dir das, Frank, aber bei mir gehts nicht. Ich habe gerade dein Plugin getestet. Und bei mir läuft auch WP 2.6. Wer weiß, was die Ursache dafür ist. Denk nur mal an meinen zweiten Kommentar bzgl des Bugs in WP. Da scheine ich auch einer der Wenigen zu sein, die das Problem hatten. Der Entwickler hat sich im TRAC dazu gemeldet und gesagt, bei ihm funktioniert der Originalcode (noch mit "home", nicht mit "siteurl"), obwohl auch seine WP-Dateien in einem Unterverzeichnis liegen.

  28. @Mathias: wenn mein Plugin bei dir auch nicht geht, dann muss es so sein. Konnte im Trac jemand helfen.
    Eventuell sollte man es mal vormerken, wenn das Problem besteht.
    Hast du mal mit dem / gespielt, wie beim Problem mit Win.

  29. Mathias sagt:

    Im Trac hatte ich das Problem bisher noch nicht gemeldet. Sollte ich vielleicht mal tun.

    Thema Backslash, Ja. Ich bin in Sachen Programmierung nicht ganz unbedarft (wie du dir vermutlich denken kannst ;)), und auch wenn man es nicht machen sollte, ich habe die Pfade mal fest vorgegeben. Lokal spielt es ohnehin keine Rolle. Mit oder ohne Backslash, es funktioniert nicht, wenn der Pfad bei "wp-content" beginnt.

    Ich habe eben auch noch mal eine unveränderte Version von WP 2.6 getestet. Bei mir läuft die Aktualisierung über ein Skript, das nebenbei auch ein paar Dateien ändert. Manchmal sind es nur Kleinigkeiten (das Umbenennen der Standardnamen für die Cookies etwa), manchmal sind es bisher noch nicht behobene Fehler (dass das "aktuelle Beiträge"-Widget etwa den $post-Zähler verändert und dadurch andere Widgets, die evtl. die ID des aktuellen Beitrags benötigen nicht mehr richtig funktionieren). Es hätte ja sein können, dass eine von meinen Änderungen für das veränderte Verhalten meines Blogs verantwortlich ist. Aber auch mit den Originaldateien funktioniert es bei mir nicht.

    Ich hatte sogar K2 in Verdacht. Vielleicht kennst du das Thema, und vielleicht weißt du, dass da doch ziemlich viel im Hintergrund passiert. Mit einem der Originalthemen änderte sich jedoch auch nichts.

  30. @Mathias:

    Ja. Ich bin in Sachen Programmierung nicht ganz unbedarft (wie du dir vermutlich denken kannst ;)),

    ... darauf kannst du Gift nehmen. Da ich nur im Hobbybereich code, gehe ich immer davon aus, dass Der/Die gegenüber besser ist. Aber ich gebe auch in der Regel nur wieder, was ich getestet habe. Aber mir sind auch schon die unterschiedlichsten Probleme unter gekommen und es war nicht klar warum. Oft schiebe ich es auf den Server, weil ich den nicht beeinflussen kann.
    Eventuell könnte man ja deine lokale Install mal als zip bekommen und dann teste ich sie bei mir im XAMPP, mal sehen, was dann ist.

  31. Mathias sagt:

    Ich bin nicht sicher, ob sich das Schicken wirklich lohnt, Frank. Ich habe zwar kein Problem damit, aber wenn ich mir so anschaue, was ich gemacht habe: nichts davon erklärt das merkwürdige Verhalten in Bezug auf die Verzeichnisse.

    Ich habe das Dashboard auf die Kommentare und eingehenden Links reduziert. Oben der Menüheader "Dashboard" verlinkt bei mir fix und nicht mehr mit "admin.php?page=XY". Ich habe das Mailkonto umbenannt, weil ich kein wordpress@-Konto habe und anlegen wollte. Wie gesagt, ich habe die Standardcookies in der "wp-settings.php" umbenannt. Ein paar Smilies sind neu, und mein WP erkennt diese jetzt auch wieder ohne Leer- oder Textendezeichen. Der more-Anker ist weg, so dass man von oben anfängt. Ich habe Autosave und Word-Count deaktiviert. Beim Prüfen auf Pluginupdates wird nicht mehr meine Blogadresse übertragen (du erinnerst dich an die Diskussion?), die Prüfung auf eine neue WP-Version ist abgeschaltet. Ich habe deine Funktion eingefügt, um Login-Fehler zu verschleiern, dafür sind rsd_link, wlwmanifest_link, wp_generator und wp_save_post_revision deaktiviert. Und ich habe den Referer beim Speichern von Beiträgen und Seiten entfernt (post.php, page.php = _wp_original_http_referer). Ich habe nämlich eine ".htaccess"-Regel, die auf "http" in Parametern recht allergisch reagiert und die Anfragen umleitet. Ein Schutz vor den Bots, die ständig versuchen, mit irgendwelchen externen Dateien meinen Server anzugreifen.

    Puh! Langer Text, sorry. Sieht man von den Änderungen ab, ist es eine ganz normale WP-Installation.

  32. @Mathias: sehe ich auch, so die Eingriffe sollten das Problem nicht tangieren.
    Die meisten Punkte habe ich auch so, allerdings alles per Funktion in Plugins oder Theme-Function.

  33. Mathias sagt:

    Kleiner Nachtrag, Frank. In der aktuellen Revision wurde die Konstante WP_PLUGIN_DIR in die Funktion "load_plugin_textdomain" aufgenommen. Der von dir beschriebene Weg dürfte damit auch nicht mehr funktionieren.

    Meine Funktion sieht jetzt so aus

    private static function getplugindirectory( $absolute = false ) {
    	$me = str_replace( "\\", "/", dirname( __FILE__ ) );
    	if ( defined( "WP_PLUGIN_DIR") and defined( "WP_PLUGIN_URL" ) ) {
    		$me = ltrim( str_replace( str_replace( "\\", "/", WP_PLUGIN_DIR ), "", $me ) );
    		if ( $absolute === true ) {
    			$me = sprintf( "%s/%s", rtrim( WP_PLUGIN_URL, "/" ), $me );
    		}
    	}
    	else {
    		if ( $absolute === true ) {
    			$me = sprintf( "%s/%s", get_option( "siteurl" ), str_replace( str_replace( "\\", "/", ABSPATH ), "", $me ) );
    		}
    	}
    	return $me;
    }
    

    Damit dürfte ich wohl auf der sicheren Seite sein, egal wo die Pfade nun liegen. Stell dir hier trotzdem mein Augenrollen vor.

  34. @Mathias: Habe ich schon bedacht, auch oben erwähnt. Die Lösung klappt aber in meinen Tests überall bestens. Mit der Konstante ist es aber noch schöner wie ich finde.
    Eventuell könnte man ja die Konstante definieren, wenn sie nicht da ist, direkt im Plugin und so sicher sein, dass man auch Versionen kleiner 2.6 unterstützt.

    if ( !defined('WP_PLUGIN_DIR') )
    	define( 'WP_PLUGIN_DIR', '/wp-content/plugins' );
    
  35. Mathias sagt:

    Ich widerspreche ungern, Frank, aber das kann nicht funktionieren. Oder ich habe gerade einen Blackout der üblen Sorte. 🙂 Beispiel: Sagen wir ABSPATH ist "/home/mathias/wordpress/". Standardmäßig setzt sich WP_PLUGIN_DIR zusammen aus ABSPATH "wp-content" (= WP_CONTENT_DIR) "/plugins". Mit

    str_replace( ABSPATH, "", dirname( __FILE__ ) )

    entfernst du aber nur ABSPATH. Es bleiben also "wp-content/plugins" und ggf. der Ordner deines Plugins übrig. Und jetzt gucke in die Datei "l10n.php"; dort steht nämlich:

    $mofile = WP_PLUGIN_DIR . $path . '/'. $domain . '-' . $locale . '.mo';

    WP_PLUGIN_DIR enthält aber den kompletten Pfad bis einschließlich "wp-content/plugins". Daran wird jetzt dein Pfad gehangen, der ja auch noch mal "wp-content/plugins" enthält. Rein logisch stimmt da der Pfad schon nicht mehr, und die Sprachdatei wird nicht gefunden werden.

    Die Idee mit der Konstante klingt aber ganz gut.

  36. @Mathias: habe mich der Sache nochmal angenommen und den obigen Syntax ergänzt, diese Lösung läuft bei mir in allen getesteten Versionen. Zusätzlich sieh Link zum Trac. Allerdings sollte der load mittels

    load_plugin_textdomain('copyrightfeed', dirname(plugin_basename(__FILE__)) . '/languages');
    

    in allen Version von WP laufen, wenn ich den Trac richtig verstehe, macht er bei mir nicht. Daher frage ich die Konstante ab und lade dementsprechend.

  37. Mathias sagt:

    Das Ticket #7075, oder besser gesagt: die letzte Antwort darin, bezieht sich auf den 2.6er-Trunk und funktioniert auch nur dort. Aus den von mir erwähnten Gründen beim "Zusammenbau" des Pfades. An sich relevanter dürfte das Changeset 8041, da siehst du nämlich auch die von mir erwähnte Änderung in der "l10n.php".

    Man muss also wirklich künftig prüfen, ob die Konstanten existieren, sonst laufen die Plugins nicht mehr richtig.

  38. @Mathias: ja, so habe ich es verstanden; finde ich aber traurig. Dann werde ich mit meiner Abfrage wohl am besten fahren.

  39. @Micha: seit dem ich nun noch den Parameter 'false' hinzufüge, klappt es bestens.

    load_plugin_textdomain('gettext_name', false, dirname(plugin_basename(__FILE__)) . '/languages');
    
  40. Xel sagt:

    Finde das absolut unsinnig...

    Damit kann man aber das Verzeichnis eine Ebene tiefer legen und so vor dem Zugriff von Außen schützen.

    Ja, es ist richtig, dass Themes und Plugins potentiell gefährlich/unsicher sind.

    Es ist aber auch richtig, dass ein Theme, welches außerhalb des Webroot ist niemals funktionieren wird, da man nicht mal an das Stylesheet rankommt, geschweige denn an Bilder oder anders... Ja ich weiß, das kann man per htaccess wieder in den Griff bekommen, aber was bringts mir dann? Ich konnte den Ordner vorher auch bereits sperren...

    Wenn mich jemand fragt, was das bringt: Verwirrung, Noobs, die nicht mehr in der Lage sind irgendwas zu installieren (seien wir mal ehrlich: Wer hat sich schon bisher an Konstanten gehalten? 90% der Entwickler doch wohl nicht. Dass sich kaum jemand an sowas hält ist ja schon allein der Grund, warum es als notwendig betrachtet wird, es außerhalb des WebRoot aufzubewahren (mangelnde Sicherheit der Plugins) - wer würde da erwarten, dass Kostanten richtig eingesetzt werden?

  41. HolgerAusB sagt:

    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.

  42. Stefan sagt:

    Hallo, ich habe mit der neuen WP Version 2.6 einmal rumgespielt und versucht die drei neuen Parameter in der WP-config.php zu definieren. Dabei hatte ich einige Probleme - zuerst ging garnicht's. Dann habe ich diese Lösung gefunden.

    if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');
    // wp-content Directory
    define('WP_CONTENT_DIR', ABSPATH . 'xnew-wp-content');
    /** Allows for the plugins directory to be moved from the default location. */
    define('WP_PLUGIN_DIR', WP_CONTENT_DIR . '/xnew-plugins'); // Plugin Directory
    //define('WP_CONTENT_URL', get_option('siteurl') . '/xnew-wp-content');
    define('WP_CONTENT_URL', 'http://localhost/xnew-wp-content');
    require_once(ABSPATH . 'wp-settings.php');

    Mein Problem bestand immer darin, das die methode "require_once()" immer vor der Definition von "WP_CONTENT_DIR" aufgerufen wurde und somit immer auf das Standardverzeichnis "wp-content" zeigte, die fest in der Datei wp-settings.php definiert wurde und somit meine Einstellungen keine Wirkung zeigten.

    Ist das korrekt oder habe ich etwas übersehen?
    Muss require_once() somit immer erst zum Schluss in der Datei WP-config.php aufgerufen werden?

  43. Xel sagt:

    Naja - eigentlich ist das schon der richtige Weg... zumindest solange du kein Entwickler bist, der den Bug fixen und nen Patch rausbringen kann...

    Wird möglicherweise n bislang unbekannter Bug sein, da die meisten auf der WP-Hackers und WP-Testers Mailingliste entweder direkt aus Amiland kommen, oder aber aus anderen Gründen nativ englischsprachig sind (und ein großer Teil der anderen zumindest so gut englisch kann, dass er sich die Sprachfiles nicht noch in ein Betarelease reinzieht (denn die Betas kommen ja eigentlich nur auf Englisch raus bzw. müssen sogar per SVN gezogen werden).

  44. @Stefan: in der wp-config.php sollte stehen:

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

    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. 😉

  46. Xel sagt:

    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.

  47. Mathias sagt:

    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?

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

  49. Xel sagt:

    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).

  50. 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.

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

  51. Xel sagt:

    @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.

  52. @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! 😉

  53. Xel sagt:

    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...

  54. codestyling sagt:

    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.

  55. @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. =)

  56. Xel sagt:

    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.

  57. Vanessa sagt:

    $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

  58. Venooze sagt:

    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.

  59. Detlef sagt:

    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

  60. Tom sagt:

    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 :/

  61. Tom sagt:

    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?

Trackbacks

  1. [...] Auslagern von /wp-content/: es soll m

  2. [...] geben, welche es ermöglicht bestimmte Config/Content-Dateien bzw. -Ordner an anderer Stelle zu verlagern. Außerdem gibt es dann in der wp-config.php nicht mehr nur ein Secret-Key, sondern 3 [...]

  3. [...] beglücken händische Fummeleien für sicherheitsrelevante Verbesserungen wie das Auslagern von wp-content/wp-config oder die deaktivierte XML-RPC Schnittstelle nicht mein Blogger-Herz. Aber vielleicht schafft es ja [...]

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

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

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

© 2016, since 2005 bueltge.de [by:ltge.de] · Theme is built by ThemeShift