Ce probleme de securitate ar trebui să am în vedere când setez FS_METHOD la "direct" în wp-config?

Care este riscul?

Pe un host partajat configurat prost, PHP-ul fiecărui client va fi executat ca același utilizator (să spunem apache pentru discuție). Această configurație este surprinzător de comună.

Dacă ești pe un astfel de host și folosești WordPress pentru a instala plugin-ul folosind acces direct la fișiere, toate fișierele tale de plugin vor aparține utilizatorului apache. Un utilizator legitim de pe același server ar putea să te atace scriind un script PHP care injectează cod rău intenționat în fișierele tale de plugin. Ei încarcă scriptul lor pe propriul website și îi solicită URL-ul. Codul tău este compromis cu succes deoarece scriptul lor rulează ca apache, același utilizator care deține fișierele tale de plugin.

Ce legătură are FS_METHOD 'direct' cu asta?

Când WordPress are nevoie să instaleze fișiere (cum ar fi un plugin), folosește funcția get_filesystem_method() pentru a determina cum să acceseze sistemul de fișiere. Dacă nu definești FS_METHOD, acesta va alege o valoare implicită pentru tine, altfel va folosi selecția ta atâta timp cât are sens.

Comportamentul implicit va încerca să detecteze dacă te afli într-un mediu riscant precum cel descris mai sus și, dacă consideră că ești î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). Altfel, va reveni la o metodă mai sigură, cum ar fi solicitarea credențialelor SFTP și crearea fișierelor ca și tine.

FS_METHOD = 'direct' cere WordPress să ocolească acea detectare a riscului și să întotdeauna creeze fișiere folosind metoda 'direct'.

Atunci de ce să folosești FS_METHOD = 'direct'?

Din păcate, logica WordPress pentru detectarea unui mediu riscant este defectuoasă și produce atât false-pozitive cât și false-negative. Hopa. Testul implică crearea unui fișier și verificarea faptului că aparține aceluiași proprietar ca și directorul în care se află. Presupunerea este că, dacă utilizatorii sunt aceiași, PHP rulează ca propriul tău cont și este sigur să instalezi plugin-uri ca acel cont. Dacă sunt diferiți, WordPress presupune că PHP rulează ca un cont partajat și nu este sigur să instalezi plugin-uri ca acel cont. Din păcate, ambele presupuneri sunt estimări educate care vor fi adesea greșite.

Ai folosi define('FS_METHOD', 'direct' ); într-un scenariu de fals-pozitiv precum acesta: faci parte dintr-o echipă de încredere ai cărei membri încarcă fișiere prin propriile conturi. PHP rulează ca propriul utilizator separat. WordPress va presupune că acesta este un mediu riscant și nu va folosi modul implicit 'direct'. În realitate, este partajat doar cu utilizatori de încredere și, ca atare, modul 'direct' este sigur. În acest caz, ar trebui să folosești define('FS_METHOD', 'direct' ); pentru a forța WordPress să scrie fișiere direct.

Există o situație 'bine-configurată' în care opțiunea 'direct' va duce la probleme.

De asemenea, este posibil să configurezi un hosting WordPress partajat cu utilizatori de execuție PHP nepartajați, diferiți de utilizatorii care dețin drepturile asupra fișierelor/directoarelor. Astfel, ajungi să ai fișierele deținute de user1, iar codul PHP este executat ca php-user1.

În această situație, plugin-uri sau cod de nucleu compromis (a) nu pot scrie (sau chiar citi, în funcție de permisiuni) directoarele altor utilizatori; (b) nu pot scrie fișierele acestui utilizator și astfel nu pot adăuga cod troian în nucleu sau în codul plugin-urilor.

Deci, dacă hosting-ul este configurat în acest fel, TREBUIE să folosești FTP pentru actualizări, iar opțiunea 'direct' nu va funcționa.

Dacă setezi 'direct' în wp-config.php și utilizatorul de execuție PHP nu are permisiuni de scriere, vei primi mesaje de tip Actualizare eșuată și nu va apărea niciun pop-up care să solicite credențialele FTP.