{"id":40,"date":"2019-12-07T04:59:04","date_gmt":"2019-12-07T03:59:04","guid":{"rendered":"https:\/\/sumedia.myddns.me\/sumedia\/sumedia-webdesign\/www.sumedia-webdesign.de\/blog\/?p=40"},"modified":"2024-12-02T07:53:13","modified_gmt":"2024-12-02T06:53:13","slug":"wordpress-url-rewrite-zum-schutz-sensibler-dateien-und-pfade","status":"publish","type":"post","link":"https:\/\/www.sumedia-webdesign.de\/blog\/wordpress\/wordpress-url-rewrite-zum-schutz-sensibler-dateien-und-pfade\/","title":{"rendered":"WordPress URL\u2019s rewrite zum Schutz sensibler Dateien und Pfade."},"content":{"rendered":"\n
Zielsetzung<\/h2>\n\n\n\n
Die Dateien aus dem wp-admin<\/strong> Verzeichnis sind aus dem Web erreichbar. Viele Dateien m\u00fcssen dies auch bleiben, damit die Anwendung funktionst\u00fcchtig bleibt. Weiterhin ist zu vermeiden, dass Bot\u2019s Zugriff auf die Loginroutinen wp-login.php<\/strong> erhalten, bzw. nicht mit der bekannten Adresse angesteuert werden k\u00f6nnen, um Angriffe zu vermeiden<\/strong>.<\/p>\n\n\n\n
Problemstellung<\/h2>\n\n\n\n
Die Admin URL<\/strong> l\u00e4sst sich nicht ohne weiteres mittels einfachem Rewrite <\/strong>\u00fcberschreiben ohne das danach die Anwendung nicht mehr funktionst\u00fcchtig ist. Auch der wp-login.php<\/strong> erfordert einige Ma\u00dfnahmen<\/strong> um die Funktion<\/strong> nach dem URL Rewrite wiederherzustellen.<\/p>\n\n\n\n
L\u00f6sungsweg<\/h2>\n\n\n\n
Mittels eines Rewrites<\/strong> werden die beiden Ziel-URI<\/strong> so umstellen, dass 1. niemand mehr die Zugangsinformationen zum Admin<\/strong> hat und Bot\u2019s nicht mehr auf das Login<\/strong> crawlen k\u00f6nnen. Dazu m\u00fcssen wir beachten, dass das Sitzungscookie<\/strong> f\u00fcr die Administration den korrekten Pfad hat und das Scripte, Styles<\/strong> und andere Assets weierhin geladen werden k\u00f6nnen.<\/p>\n\n\n\n
Weiterhin m\u00fcssen wir dem System bekannt machen<\/strong>, dass sich die URL\u2019s generell ge\u00e4ndert haben. Was bei der Verwendung der daf\u00fcr vorgesehenen Standard-URL-Ermittlung<\/strong>, wie sie von WordPress vorgegeben werden, die Funktionalit\u00e4t erhalten soll.<\/p>\n\n\n\n
Umsetzung<\/h2>\n\n\n\n
Mod Rewrite Module von Apache<\/h3>\n\n\n\n
Zun\u00e4chst definiere ich hier, dass \/wp-admin\/ zuk\u00fcnfigt unter \/backend\/ erreichbar sein soll und das \/wp-login.php schlicht \u00fcber \/login aufrufbar sein soll.<\/p>\n\n\n\n
Um diese \u00c4nderung dem System bekannt zu machen verwende ich einige Rewrite direktiven (wie dies von den wohl meisten System unterst\u00fctzt wird).<\/p>\n\n\n\n
Datei: \/wordpress\/.htaccess<\/small><\/p>\n\n\n
\n# BEGIN of our changes\n<IfModule mod_rewrite.c>\n RewriteCond %{REQUEST_URI} ^.*?\/?backend\/?.*$\n RewriteRule ^(.*?\/?)backend(\/?.*)$ $1wp-admin$2 [L,E=IS_BACKEND:1,END]\n \n RewriteCond %{REQUEST_URI} ^\/wordpress\/wp-admin\/load-styles.php$ [OR]\n RewriteCond %{REQUEST_URI} ^\/wordpress\/wp-admin\/load-scripts.php$ [OR]\n RewriteCond %{REQUEST_URI} ^\/wordpress\/wp-admin\/admin-ajax.php$\n RewriteRule ^.* - [L,E=IS_BACKEND:1,END]\n \n RewriteCond %{ENV:REDIRECT_IS_BACKEND} !^1$ \n RewriteCond %{REQUEST_URI} ^.*?\/?wp-admin\/?.*$\n RewriteRule ^.* - [F,L]\n \n RewriteCond %{REQUEST_URI} ^.*?\/login\\??.*$\n RewriteRule ^(.*?\/?)login(\\??.*)$ $1wp-login.php$2 [L,E=IS_LOGIN:1]\n \n RewriteCond %{ENV:REDIRECT_IS_LOGIN} !^1$\n RewriteCond %{SCRIPT_FILENAME} ^.*?\/wp-login.php$\n RewriteRule ^.* - [F,L]\n<\/IfModule>\n# END of our changes\n\n# BEGIN WordPress\n# Die Anweisungen (Zeilen) zwischen `BEGIN WordPress` und `END WordPress` sind\n# dynamisch generiert und sollten nur \u00fcber WordPress-Filter ge\u00e4ndert werden.\n# Alle \u00c4nderungen an den Anweisungen zwischen diesen Markierungen werden \u00fcberschrieben.\n\n<IfModule mod_rewrite.c>\n RewriteEngine On\n RewriteBase \/wordpress\/\n RewriteRule ^index\\.php$ - [L]\n RewriteCond %{REQUEST_FILENAME} !-f\n RewriteCond %{REQUEST_FILENAME} !-d\n RewriteRule . \/wordpress\/index.php [L]\n<\/IfModule>\n\n# END WordPress\n<\/pre><\/div>\n\n\n
Erl\u00e4uterungen zu dieser Codesequenz<\/p>\n\n\n\n
RewriteCond, leitet eine Bedingung ein die erf\u00fcllt sein muss. In diesem Fall m\u00f6chten wir die Servervariable %{REQUEST_URI} ansprechen welche den Pfad und die Datei des Aufrufs beinhaltet \u2013 z.B. \/meinUntervereichnis\/backend\/index.php<\/p>\n\n\n\n
Der nachfolgende Regul\u00e4re Ausdruck sagt ungef\u00e4hr aus pr\u00fcfe alles was davor kommt \/meinUnterverschnis\/ wenn es denn vorhanden ist gefolgt von unserer neuen URL backend und allem weiteren was darauf folgt \/index.php.<\/p>\n\n\n\n
Regul\u00e4rer Ausdruck: ^: Anfang des Strings .*?: beliebige Zeichen oder gar keins \/?: ein \/ \u2013 muss aber nicht vorkommen (daf\u00fcr sorgt das ? dahinter) backend: eine Zeichenfolge die erwartet wird $: Ende des Strings<\/p>\n\n\n\n
RewriteRule, leitet die Weiterleitung ein, wenn unsere Bedingung zutreffend war. Wir also den administrativen Bereich \u00fcber die neue URL aufrufen.<\/p>\n\n\n\n
Regul\u00e4rer Ausdruck: (): Eingeschlossene Elemente werden im Speicher zur sp\u00e4teren Verwendung abgelegt. Die Nummering 1,2,\u2026 wird mit $1,$2,\u2026 in den n\u00e4chsten Regul\u00e4ren Ausdruck integriert.<\/p>\n\n\n\n
In diesem Fall soll der URL Aufruf \/backend\/ zu dem Verzeichnis \/wp-admin\/ weiterleiten.<\/p>\n\n\n\n
Die in [] eingeschlossenen Direktiven an das Rewrite Modul des Apache steuern den Ablauf wie folgt: L: Letzte Regel in diese Bedingung. E: Setzt eine Environmentvariable, welche wir dann sp\u00e4ter brauchen. END: Beendet weiteres Rewriting.<\/p>\n\n\n
Die URL des Browsers wurde aus dem WordPress Standard aufgerufen. Da wird dies blockieren wollen, matchen wir diesen Aufruf.<\/p>\n\n\n
\nRewriteRule ^.* - [F,L]\n<\/pre><\/div>\n\n\n
Unsere Bedingungen f\u00fcr diese Regel sind definiert und alles was bis hierhin durch kommt, muss blockiert werden. -: Es erfolgt kein Rewrite F: Beende mit Forbidden (Zugriff nicht erlaubt)<\/p>\n\n\n\n
In etwa equivalent verh\u00e4lt sich dies mit der Login URL.<\/p>\n\n\n\n
Das setzen der Cookies (ADMIN_COOKIE_PATH)<\/h3>\n\n\n\n
Da sich durch das \u00e4ndern der URL auch der Cookie Pfad \u00e4ndert und nun auf eine nicht mehr erreichbare Seite verweist. M\u00fcssen wir diesen mit der neuen URL bekannt machen, damit der Administrationsbereich geladen werden kann.<\/p>\n\n\n\n
Suchen oder erg\u00e4nzen Sie in der Konfigurationsdatei folgende Konstante.<\/p>\n\n\n\n
Wobei es auch nur \u201a\/backend\u2018 sein kann, wenn Sie kein Unterverzeichnis verwenden. Es h\u00e4ngt ein bisschen von Ihrer Wahl ab, wie der Pfad definiert wird.<\/p>\n\n\n\n
Damit kann das Cookie jetzt f\u00fcr die neue Domain gesetzt werden und wir k\u00f6nnen den Administrationsbereich wie gewohnt erreichen.<\/p>\n\n\n\n
Es fehlt jetzt nur noch eine Codesequenz, um WordPress selbst mitzuteilen, dass sich die URL\u2019s ge\u00e4ndert haben. Dazu ben\u00f6tigen Sie im Idealfall ein eigenes Plugin, dass folgend programmiert ist. Die Grundlagen f\u00fcr das anlegen von Plugins werde ich hier jetzt nicht erl\u00e4utern und m\u00f6chte darum bitten via Google auf die Suche zu gehen, es gibt dort einige interessante Artikel dazu.<\/p>\n\n\n\n
Ich bitte um Entschuldigung, wenn ich nicht den Coding Standard aus WordPress verwende \u2013 man hat in PHP sowieso schon das Problem, dass der Code waagerecht aus den Fugen ger\u00e4t, dass muss man nicht noch mit zus\u00e4ztlichen Leerzeichen befeuern.<\/small><\/p>\n\n\n\n
In der Regel sollten diese Einstellungen f\u00fcr den Standard in WordPress kein Problem darstellen, Schwieriger w\u00e4re es z.B. das Plugin Verzeichnis abzusichern, da hier nie bekannt sein kann, in welcher Form der Programmierer sein Plugin umgesetzt hat. Was es gerade zu unm\u00f6glich macht, das Plugin Verzeichnis sinnvoll abzusichern. Verwendet der Programmierer keine URL\u2019s in Standardform, funktionieren auch die URL Rewrites nicht. Daher bleibt dieser, eigentlich sehr wichtige Punkt an Sicherheit, vorerst wohl offen.<\/p>\n\n\n\n
WordPress aktualisiert auch in regelm\u00e4\u00dfigen Abst\u00e4nden die .htacess Datei. Unter verschiedenen Umst\u00e4nden wird diese neu generiert. Eintragungen innerhalb des # WordPress Blocks werden dann \u00fcberschrieben.<\/p>\n\n\n\n
F\u00fcr die L\u00f6sung an diesem Problem habe ich ein WordPress Modul geschrieben, dass einem die Aufgabe des \u00fcberpr\u00fcfens auf aktualisierung abnimmt.<\/p>\n\n\n\n
![\"\"](\"https:\/\/sumedia.myddns.me\/sumedia\/sumedia-webdesign\/www.sumedia-webdesign.de\/blog\/wp-content\/uploads\/2024\/12\/wp-n-suma.png\")
<\/figure>\n<\/div>\n\n\n\n