Am avut recent o problemă în care nu am putut instala pluginul WP Smush Pro, deoarece nu am instalarea manuală sau instalarea cu un singur clic opțiuni disponibile.
Am dat peste această postare care sugera modificarea setărilor în wp-config.php. Am adăugat setările sugerate, însă cea care pare a fi cea mai importantă este:
define("FS_METHOD", "direct");
Ce aș vrea să știu ce preocupări reale ar trebui să am în legătură cu setarea FS_METHOD la direct? Există alte alternative la instalarea pluginului?
Iată ce spune documentația oficială:
FS_METHOD forțează metoda sistemului de fișiere. Ar trebui să fie doar „direct”, „ssh2″, ” ftpext „, sau” ftpsockets „. În general, ar trebui să schimbați acest lucru numai dacă întâmpinați probleme de actualizare. Dacă îl modificați și nu vă ajută, schimbați-l înapoi / re mișcă-l. În majoritatea circumstanțelor, setarea la „ftpsockets” va funcționa dacă metoda aleasă automat nu funcționează.
(Preferință primară) „direct” îl obligă să utilizeze cereri de I / O de fișiere directe din PHP, acesta este plin de deschiderea problemelor de securitate pe gazde slab configurate, acest lucru este ales automat atunci când este cazul.
Răspuns
Acesta este doar modul în care am înțeles ideea WordPress File API . Dacă este greșit, vă rugăm să votați negativ 🙂
Bine. Dacă încărcați un fișier, acest fișier are un proprietar. Dacă încărcați fișierul cu FTP, vă autentificați și fișierul va fi deținut de utilizatorul FTP. Deoarece aveți acreditările, puteți modifica aceste fișiere prin FTP. Proprietarul poate executa, șterge, modifica fișierul etc. Desigur, puteți schimba acest lucru schimbând permisiunile de fișiere .
Dacă încărcați un fișier folosind PHP, utilizatorul Linux, care este executarea PHP este proprietarul fișierului. Acest utilizator poate acum edita, șterge, executa etc. fișierul. Acest lucru este în regulă atâta timp cât doar dvs. sunteți utilizatorul, care execută PHP pe sistemul dvs.
Să presupunem că sunteți pe o gazdă partajată „slab” configurată. O mulțime de oameni își rulează site-urile PHP pe acest sistem. Să spunem că un singur utilizator Linux execută PHP pentru toți acești oameni. Unul dintre webmasterii de pe această gazdă partajată are intenții proaste. El vă vede pagina și își dă seama de calea către instalarea WordPress. De exemplu, WP_DEBUG este setat la adevărat și există un mesaj de eroare precum
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1 „Ha!” zice băiatul cel rău. Să vedem, dacă tipul acesta a setat FS_METHOD la direct și scrie un script ca
<?php unlink( "/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php" ); ?> Deoarece un singur utilizator rulează PHP și acest utilizator este folosit și de băiatul rău, el poate modifica / șterge / executa fișierele din sistemul dvs. dacă le-ați încărcat prin PHP și prin aceasta atașat PHP utilizator ca proprietar.
Site-ul dvs. este piratat.
Sau, așa cum se spune în Codex:
Multe sisteme de găzduire au serverul web care rulează ca un utilizator diferit de proprietarul fișierelor WordPress. Atunci când este cazul, un proces de scriere a fișierelor de la utilizatorul serverului web va avea fișierele rezultate deținute de contul de utilizator al serverului de web în locul contului de utilizator real. Acest lucru poate duce la o problemă de securitate în situații de găzduire partajată, în care mai mulți utilizatori partajează același server web pentru site-uri diferite.
Răspuns
Care este riscul?
Pe o gazdă partajată slab configurată, PHP-ul fiecărui client va fi executat ca același utilizator (să spunem apache pentru discuție). Această configurare este surprinzător de comună.
Dacă sunteți pe o astfel de gazdă și utilizați WordPress pentru a instala pluginul folosind accesul direct la fișiere, toate fișierele dvs. plugin vor aparține apache. Un utilizator legitim de pe același server ar putea să vă atace scriind un script PHP care injectează cod rău în fișierele dvs. plugin. Își încarcă scriptul pe propriul site web și îi solicită adresa URL. Codul dvs. este compromis cu succes deoarece scriptul lor rulează ca apache, același cod care deține fișierele dvs. plugin.
Ce înseamnă FS_METHOD "direct" aveți de-a face cu asta?
Când WordPress trebuie să instaleze fișiere (cum ar fi un plugin), acesta folosește get_filesystem_method () funcție pentru a determina cum să accesați sistemul de fișiere. Dacă nu definiți FS_METHOD va alege o valoare implicită pentru dvs., altfel va folosi selecția dvs. atâta timp cât are sens.
Comportamentul implicit va încerca pentru a detecta dacă vă aflați într-un mediu cu risc cum ar fi una pe care am descris-o mai sus și, dacă credeți că sunteți în siguranță, va folosi metoda "direct". În acest caz, WordPress va crea fișierele direct prin PHP, făcându-le să aparțină utilizatorului apache (în acest exemplu). În caz contrar, va reveni la o metodă mai sigură, cum ar fi să vă solicităm acreditări SFTP și să creați fișierele așa cum doriți.
FS_METHOD = "direct" solicită WordPress să ocolească acest lucru la -detectarea riscurilor și întotdeauna creați fișiere folosind metoda "direct".
Atunci de ce să folosiți FS_METHOD = "direct"?
Din păcate, „logica WordPress pentru detectarea unui mediu cu risc este defectă și produce atât fals-pozitive, cât și false-negative. Hopa. Testul implică crearea unui fișier și asigurarea faptului că aparține aceluiași proprietar ca și directorul în care trăiește. Presupunerea este că, dacă utilizatorii sunt aceiași, PHP rulează ca propriul dvs. cont și este sigur să instalați pluginuri ca acel Dacă sunt „diferiți, WordPress presupune că PHP rulează ca un cont partajat și nu este sigur să instalați pluginuri ca acel cont. Din păcate, aceste două ipoteze sunt presupuneri educate care vor fi greșite frecvent.
Ați utiliza define("FS_METHOD", "direct" ); într-un scenariu fals pozitiv, precum acesta: faceți parte dintr-o echipă de încredere ai cărei membri încarcă fișiere prin propriul cont. PHP rulează ca propriul său separat utilizator. WordPress va presupune că acesta este un mediu cu risc și nu va intra în mod implicit în modul "direct". În realitate, acesta este partajat numai cu utilizatorii în care aveți încredere și ca atare este sigur. În acest caz, ar trebui să utilizați define("FS_METHOD", "direct" ); pentru a forța WordPress să scrie direct fișiere.
Comentarii
Răspuns
Există un„ bine configurat ” situație în care „direct” va duce la probleme.
Este, de asemenea, posibil să configurați găzduirea WP partajată cu utilizatorii de execuție PHP care nu sunt partajați, diferiți de utilizatorii proprietății fișierului / directorului. Așadar, ajungeți la fișierele deținute de user1 și codul PHP este executat ca php-user1.
În această situație, pluginurile sau codul de bază piratat (a) nu pot scrie în (sau chiar citi din , în funcție de permisiuni) directorii altor utilizatori; (b) nu se poate scrie fișierele acestui utilizator și astfel nu se poate adăuga cod troian la codul de bază sau la plugin.
Deci, dacă găzduirea este configurată astfel , TREBUIE să utilizați FTP pentru actualizări și „direct” nu va funcționa.
Dacă setați „direct” în wp-config.php și utilizatorul de execuție PHP nu are permisiunea de scriere, veți primi Update Mesaje nereușite și nu au nicio fereastră pop-up care solicită acreditări FTP.
get_filesystem_method()la acesta: developer.wordpress.org/reference/functions/…