Jeg har nylig hatt et problem der jeg ikke har klart å installere WP Smush Pro-pluginet fordi jeg ikke har manuell installasjon eller installasjon med ett klikk tilgjengelige alternativer.
Jeg kom over dette innlegget som foreslo å justere innstillingene i wp-config.php. Jeg la til de innstillingene som ble foreslått, men den som ser ut til å være den viktigste er:
define("FS_METHOD", "direct");
Hva jeg ønsker å vite er hvilke virkelige bekymringer jeg bør ha rundt å sette FS_METHOD til direct? Er det noen andre alternativer for å installere pluginet?
Dette har den offisielle dokumentasjonen å si:
FS_METHOD tvinger filsystemmetoden. Den skal bare være «direkte», «ssh2″, » ftpext «, eller» ftpsockets «. Generelt sett bør du bare endre dette hvis du har oppdateringsproblemer. Hvis du endrer det og det ikke hjelper, kan du endre det tilbake / re flytt den. Under de fleste omstendigheter vil det å sette den til «ftpsockets» fungere hvis den automatisk valgte metoden ikke gjør det.
(Primær preferanse) «direct» tvinger den til å bruke Direct File I / O-forespørsler fra PHP, dette er fulle av å åpne sikkerhetsproblemer på dårlig konfigurerte verter, Dette velges automatisk når det er aktuelt.
Svar
Dette er bare hvordan jeg forsto ideen om WordPress File API . Hvis det er feil, kan du nedstemme 🙂
Ok. Hvis du laster opp en fil, har denne filen en eier. Hvis du laster opp filen din med FTP, logger du på og filen eies av FTP-brukeren. Siden du har legitimasjonen, kan du endre disse filene via FTP. Eieren kan vanligvis kjøre, slette, endre etc. filen. Selvfølgelig kan du endre dette ved å endre filtillatelser .
Hvis du laster opp en fil med PHP, er Linux-brukeren, som er å utføre PHP eier filen. Denne brukeren kan nå redigere, slette, utføre osv. Filen. Dette er greit så lenge bare du er brukeren som kjører PHP på systemet ditt.
La oss anta at du er på en «dårlig» konfigurert delt vert. Mange kjører sine PHP-nettsteder på dette systemet. La oss si at bare en Linux-bruker utfører PHP for alle disse menneskene. En av webansvarlige på denne delte verten har dårlige intensjoner. Han ser siden din, og han finner ut veien til WordPress-installasjonen din. For eksempel er WP_DEBUG satt til true, og det er en feilmelding som
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1 «Ha!» sier den dårlige gutten. La oss se om denne fyren har satt FS_METHOD til direct og han skriver et skript som
<?php unlink( "/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php" ); ?> Siden bare en bruker kjører PHP, og denne brukeren også brukes av bad boy, kan han endre / slette / utføre filene på systemet ditt hvis du har lastet dem opp via PHP og ved dette vedlagt PHP bruker som eier.
Nettstedet ditt er hacket.
Eller som det står i Codex:
Mange hosting-systemer har webserveren som en annen bruker enn eieren av WordPress-filene. Når dette er tilfelle, vil en prosess som skriver filer fra webserverbrukeren ha de resulterende filene som eies av webserverens brukerkonto i stedet for den faktiske brukerens konto. Dette kan føre til et sikkerhetsproblem i delte vertssituasjoner, hvor flere brukere deler den samme webserveren for forskjellige nettsteder.
Svar
Hva er risikoen?
På en dårlig konfigurert delt vert vil hver kundes PHP utføre som samme bruker (la oss si apache for diskusjon). Dette oppsettet er overraskende vanlig.
Hvis du er på en slik vert og bruker WordPress for å installere pluginet ved hjelp av direkte filtilgang, vil alle pluginfilene dine vil tilhøre apache. En legitim bruker på samme server vil kunne angripe deg ved å skrive et PHP-skript som injiserer ond kode i plugin-filene dine. De laster opp skriptet sitt til sitt eget nettsted og ber om URL-adressen. Koden din er kompromittert fordi skriptet deres kjører som apache, det samme som eier plugin-filene dine.
Hva gjør FS_METHOD "direct" har å gjøre med det?
Når WordPress trenger å installere filer (for eksempel et plugin) bruker den get_filesystem_method () funksjon for å bestemme hvordan du får tilgang til filsystemet. Hvis du ikke definerer FS_METHOD, vil den velge standard for deg, ellers vil den bruke valget ditt så lenge det er fornuftig.
Standardoppførselen vil prøve for å oppdage om du er i et utsatt miljø som en jeg beskrev ovenfor, og hvis den mener at du er trygg, vil den bruke "direct" -metoden. I dette tilfellet vil WordPress opprette filene direkte gjennom PHP, og føre til at de tilhører apache brukeren (i dette eksemplet). Ellers faller det tilbake til en tryggere metode, for eksempel å be deg om SFTP-legitimasjon og opprette filene som deg.
FS_METHOD = "direct" ber WordPress omgå dette -risikodeteksjon og alltid opprett filer ved hjelp av "direct" -metoden.
Hvorfor bruke FS_METHOD = "direct"?
Dessverre er WordPress-logikken for å oppdage et miljø som er i fare feil og produserer både falske positive og falske negativer. Uss. Testen innebærer å lage en fil og sørge for at den tilhører samme eier som katalogen den bor i. Antagelsen er at hvis brukerne er de samme, kjører PHP som din egen konto og det er trygt å installere plugins som Hvis de «er forskjellige, antar WordPress at PHP kjører som en delt konto, og det er ikke trygt å installere plugins som den kontoen. Dessverre er begge disse antagelsene utdannede gjetninger som ofte vil være gale.
Du vil bruke define("FS_METHOD", "direct" ); i et falskt positivt scenario som dette: du er en del av et pålitelig team hvis medlemmer alle laster opp filer via sin egen konto. PHP kjører som sin egen separat WordPress vil anta at dette er et miljø som er i faresonen og vil ikke som standard være "direct" -modus. I virkeligheten deles det bare med brukere du stoler på og som sådan "direct" -modus er trygg. I dette tilfellet bør du bruke define("FS_METHOD", "direct" ); for å tvinge WordPress til å skrive filer direkte.
Kommentarer
Svar
Det er et» godt konfigurert » situasjon der «direkte» vil føre til problemer.
Det er også mulig å konfigurere delt WP-hosting med ikke-delte PHP-kjøringsbrukere, forskjellig fra brukerne av fil- / katalogeierskap. Så du ender opp med filene som eies av user1 og PHP-koden blir utført som php-user1.
I den situasjonen kan hackede plugins eller kjernekode (a) ikke skrive til (eller til og med lese fra , avhengig av tillatelser) andre brukere «regissør; (b) kan ikke skrive denne brukerens filer, og det kan også ikke legge til trojanskode til kjernen eller plugin-koden.
Så hvis hosting er konfigurert slik , MÅ du bruke FTP for oppdateringer og «direkte» vil ikke fungere.
Hvis du setter «direkte» i wp-config.php og PHP-kjøringsbrukeren ikke har skrivetillatelse, får du oppdatering Mislykkede meldinger og har ingen forgrunnsvindu som ber om FTP-legitimasjon.
get_filesystem_method()lenken til denne: developer.wordpress.org/reference/functions/…