Jeg har for nylig haft et problem, hvor jeg ikke har været i stand til at installere WP Smush Pro-pluginet, fordi jeg ikke har manuel installation eller installation med et enkelt klik tilgængelige muligheder.
Jeg stødte på dette indlæg , som foreslog at finjustere indstillingerne i wp-config.php. Jeg tilføjede de foreslåede indstillinger, men den der synes at være den vigtigste er:
define("FS_METHOD", "direct");
Hvad jeg gerne vil vide er hvilke reelle bekymringer skal jeg have omkring indstilling af FS_METHOD til direct? Er der andre alternativer til installation af plugin?
Dette har den officielle dokumentation at sige:
FS_METHOD tvinger filsystemmetoden. Den skal kun være “direkte”, “ssh2″, ” ftpext “eller” ftpsockets “. Generelt bør du kun ændre dette, hvis du oplever opdateringsproblemer. Hvis du ændrer det, og det ikke hjælper, skal du ændre det tilbage / re Flyt det. Under de fleste omstændigheder fungerer det at “ftpsockets” fungerer, hvis den automatisk valgte metode ikke gør det.
(Primær præference) “direkte” tvinger det til at bruge direkte fil I / O-anmodninger fra PHP, dette er fyldt med at åbne sikkerhedsproblemer på dårligt konfigurerede værter, Dette vælges automatisk, når det er relevant.
Svar
Dette er bare, hvordan jeg forstod ideen om WordPress File API . Hvis det er forkert, bedes du nedstemme 🙂
Okay. Hvis du uploader en fil, har denne fil en ejer. Hvis du uploader din fil med FTP, logger du ind, og filen ejes af FTP-brugeren. Da du har legitimationsoplysninger, kan du ændre disse filer via FTP. Ejeren kan normalt udføre, slette, ændre osv. Filen. Selvfølgelig kan du ændre dette ved at ændre filtilladelser .
Hvis du uploader en fil ved hjælp af PHP, er Linux-brugeren, som er eksekvering af PHP ejer filen. Denne bruger kan nu redigere, slette, udføre osv. Filen. Dette er okay, så længe kun du er brugeren, der udfører PHP på dit system.
Lad os antage, at du er på en “dårligt” konfigureret delt vært. Mange mennesker kører deres PHP-websteder på dette system. Lad os sige, at kun en Linux-bruger udfører PHP for alle disse mennesker. En af webmasterne på denne delte vært har dårlige intentioner. Han ser din side, og han finder ud af stien til din WordPress-installation. For eksempel er WP_DEBUG indstillet til sand, og der er en fejlmeddelelse som
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1 “Ha!” siger den dårlige dreng. Lad os se, om denne fyr har indstillet FS_METHOD til direct, og han skriver et script som
<?php unlink( "/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php" ); ?> Da kun en bruger kører PHP, og denne bruger også bruges af den dårlige dreng, kan han ændre / slette / udføre filerne på dit system, hvis du har uploadet dem via PHP og ved denne vedhæftede PHP bruger som ejer.
Dit websted er hacket.
Eller som det står i Codex:
Mange hosting-systemer kører webserveren som en anden bruger end ejeren af WordPress-filerne. Når dette er tilfældet, vil en proces, der skriver filer fra webserverbrugeren, have de resulterende filer, der ejes af webserverens brugerkonto i stedet for den faktiske brugers konto. Dette kan føre til et sikkerhedsproblem i delte hosting-situationer, hvor flere brugere deler den samme webserver for forskellige websteder.
Svar
Hvad er risikoen?
På en dårligt konfigureret delt vært vil hver kundes PHP udføre som den samme bruger (lad os sige apache til diskussion). Denne opsætning er overraskende almindelig.
Hvis du er på en sådan vært og bruger WordPress til at installere pluginet ved hjælp af direkte filadgang, vil alle dine plugin-filer tilhører apache. En legitim bruger på den samme server ville være i stand til at angribe dig ved at skrive et PHP-script, der injicerer ond kode i dine plugin-filer. De uploader deres script til deres eget websted og anmoder om dets URL. Din kode er kompromitteret, fordi deres script kører som apache, det samme som ejer dine plugin-filer.
Hvad gør FS_METHOD "direct" har det at gøre?
Når WordPress skal installere filer (f.eks. et plugin) bruger det get_filesystem_method () funktion til at bestemme, hvordan du får adgang til filsystemet. Hvis du ikke definerer FS_METHOD, vælger den en standard for dig, ellers bruger den dit valg, så længe det giver mening.
Standardadfærden forsøger for at opdage, om du “befinder dig i et udsat miljø som f.eks. en, jeg beskrev ovenfor, og hvis den mener, at du er “sikker, vil den bruge metoden "direct". I dette tilfælde opretter WordPress filerne direkte via PHP, hvilket får dem til at tilhøre apache brugeren (i dette eksempel). Ellers falder det tilbage til en mere sikker metode, såsom at bede dig om SFTP-legitimationsoplysninger og oprette filerne som dig.
FS_METHOD = "direct" beder WordPress om at omgå det kl. -risikodetektion og altid opret filer ved hjælp af "direct" -metoden.
Hvorfor bruge FS_METHOD = "direct"?
Desværre er WordPress “-logik til at opdage et udsat miljø mangelfuld og producerer både falske positive og falske negativer. Ups. Testen indebærer at oprette en fil og sikre, at den tilhører den samme ejer som den mappe, den bor i. Antagelsen er, at hvis brugerne er de samme, kører PHP som din egen konto, og det er sikkert at installere plugins som det konto. Hvis de “er forskellige, antager WordPress, at PHP kører som en delt konto, og det er ikke sikkert at installere plugins som den konto. Desværre er begge disse antagelser uddannede gæt, der ofte vil være forkerte.
Du bruger define("FS_METHOD", "direct" ); i et falskt positivt scenarie som dette: du er en del af et betroet team, hvis medlemmer alle uploader filer via deres egen konto. PHP kører som sin egen separate bruger. WordPress antager, at dette er et risikomiljø og ikke som standard er "direct" -tilstand. I virkeligheden deles det kun med brugere, du stoler på, og som sådan "direct" -tilstand er sikker. I dette tilfælde skal du bruge define("FS_METHOD", "direct" ); til at tvinge WordPress til at skrive filer direkte.
Kommentarer
- Tak dig @mark, det var meget nyttigt! Du skal muligvis opdatere
get_filesystem_method()-linket til dette: developer.wordpress.org/reference/functions/…
Svar
Der er en” godt konfigureret ” situation, hvor “direkte” vil føre til problemer.
Det er også muligt at konfigurere delt WP-hosting med ikke-delte PHP-udførelsesbrugere, forskelligt fra brugerne af fil- / katalogejerskab. Så du ender med de filer, der ejes af user1, og PHP-koden udføres som php-user1.
I den situation kan hackede plugins eller kernekode (a) ikke skrive til (eller endda læse fra , afhængigt af tilladelser) andre brugeres “direktør; (b) kan “ikke skrive denne brugerens filer, og det kan også” ikke tilføje trojanskode til kernen eller plugin-koden.
Så hvis hosting er konfigureret sådan , SKAL du bruge FTP til opdateringer, og “direkte” fungerer ikke.
Hvis du indstiller “direkte” i wp-config.php, og PHP-udførelsesbrugeren ikke har skrivetilladelse, får du opdatering Mislykkede meddelelser og har ingen pop-up, der beder om FTP-legitimationsoplysninger.