Vilka säkerhetsproblem bör jag ha när jag ställer in FS_METHOD till “ direkt ” i wp-config?

Det här är bara hur jag förstod idén med WordPress File API . Om det är fel, vänligen nedröst 🙂

Okej. Om du laddar upp en fil har den här filen en ägare. Om du laddar upp din fil med FTP loggar du in och filen ägs av FTP-användaren. Eftersom du har referenser kan du ändra dessa filer via FTP. Ägaren kan vanligtvis köra, radera, ändra etc. filen. Naturligtvis kan du ändra detta genom att ändra filbehörigheter .

Om du laddar upp en fil med PHP är Linux-användaren, som är körning av PHP äger filen. Den här användaren kan nu redigera, radera, köra etc. filen. Detta är okej så länge bara du är användaren som kör PHP på ditt system.

Låt oss anta att du är på en ”dåligt” konfigurerad delad värd. Många människor driver sina PHP-webbplatser på detta system. Låt oss säga att bara en Linux-användare kör PHP för alla dessa människor. En av webbansvariga på den här delade värden har dåliga avsikter. Han ser din sida och han räknar ut vägen till din WordPress-installation. Till exempel är WP_DEBUG satt till true och det finns ett felmeddelande som

[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1 

”Ha!” säger den dåliga pojken. Låt oss se om den här killen har ställt in FS_METHOD till direct och han skriver ett skript som

<?php unlink( "/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php" ); ?> 

Eftersom endast en användare kör PHP och den här användaren också används av bad boy kan han ändra / ta bort / exekvera filerna på ditt system om du har laddat upp dem via PHP och därmed bifogat PHP användare som ägare.

Din webbplats har hackats.

Eller som det står i Codex:

Många värdsystem har webbservern som en annan användare än WordPress-filens ägare. När detta är fallet kommer en process som skriver filer från webbserveranvändaren att ha de resulterande filerna som ägs av webbserverns användarkonto istället för den faktiska användarens konto. Detta kan leda till ett säkerhetsproblem i delade värdsituationer, där flera användare delar samma webbserver för olika webbplatser.

Vad är risken?

På en dåligt konfigurerad delad värd kommer varje kunds PHP att köra som samma användare (låt oss säga apache för diskussion). Denna inställning är överraskande vanligt.

Om du är på en sådan värd och använder WordPress för att installera plugin-programmet med direkt filåtkomst, dina plugin-filer tillhör apache. En legitim användare på samma server skulle kunna attackera dig genom att skriva ett PHP-skript som injicerar ond kod i dina plugin-filer. De laddar upp sitt skript till sin egen webbplats och begär dess URL. Din kod komprometteras framgångsrikt eftersom deras skript körs som apache, samma som äger dina plugin-filer.

Vad gör FS_METHOD "direct" har det att göra med det?

När WordPress behöver installera filer (till exempel ett plugin) använder det get_filesystem_method () funktion för att bestämma hur du kommer åt filsystemet. Om du inte definierar FS_METHOD kommer den att välja en standard för dig, annars använder den ditt val så länge det är vettigt.

Standardbeteendet försöker för att upptäcka om du befinner dig i en riskmiljö som en som jag beskrev ovan, och om den tycker att du är ”säker” kommer den att använda metoden "direct". I det här fallet skapar WordPress filerna direkt via PHP, vilket gör att de tillhör apache användaren (i det här exemplet). Annars faller det tillbaka till en säkrare metod, som att be dig om SFTP-referenser och skapa filerna som du.

FS_METHOD = "direct" ber WordPress att kringgå det vid -risk upptäckt och alltid skapa filer med metoden "direct".

Varför använda FS_METHOD = "direct"?

Tyvärr är WordPress-logiken för att upptäcka en riskmiljö bristfällig och ger både falska positiva och falska negativ. Oj då. Testet handlar om att skapa en fil och se till att den tillhör samma ägare som katalogen den bor i. Antagandet är att om användarna är desamma körs PHP som ditt eget konto och det är säkert att installera plugins som det Om de är annorlunda antar WordPress att PHP körs som ett delat konto och att det inte är säkert att installera plugins som det kontot. Tyvärr är båda dessa antaganden utbildade gissningar som ofta kommer att vara fel.

Du skulle använda define("FS_METHOD", "direct" ); i ett falskt positivt scenario som det här: du är en del av ett pålitligt team vars medlemmar alla laddar upp filer via sitt eget konto. PHP körs som en egen separat WordPress kommer att anta att detta är en riskmiljö och kommer inte att vara "direct" som standard. I verkligheten delas den bara med användare du litar på och som sådan "direct" -läget är säkert. I det här fallet bör du använda define("FS_METHOD", "direct" ); för att tvinga WordPress att skriva filer direkt.

Kommentarer

• Tack du @mark, det var väldigt användbart! Du kan behöva uppdatera länken get_filesystem_method() till den här: developer.wordpress.org/reference/functions/…

Det finns en” väl konfigurerad ” situation där ”direkt” kommer att leda till problem.

Det är också möjligt att konfigurera delad WP-hosting med icke-delade PHP-exekveringsanvändare, annorlunda än användare av fil- / katalogägande. Så du hamnar med filerna som ägs av user1 och PHP-koden körs som php-user1.

I den situationen kan hackade plugins eller kärnkod (a) inte skriva till (eller till och med läsa från , beroende på behörigheter) andra användares ”regissör; (b) kan inte skriva den här användarens filer och så kan inte lägga till trojankod i kärnan eller plugin-koden.

Så om värdet är inställt så , MÅSTE du använda FTP för uppdateringar och ”direkt” fungerar inte.

Om du ställer in ”direkt” i wp-config.php och PHP-körningsanvändaren inte har skrivbehörighet får du Uppdatering Misslyckade meddelanden och har ingen popup som ber om FTP-referenser.