Jaké bezpečnostní obavy bych měl mít, když nastavím FS_METHOD na “ direct ” ve wp-config?

Právě tak jsem pochopil myšlenku WordPress File API . Pokud je to špatné, hlasujte proti 🙂 🙂

Dobře. Pokud nahrajete soubor, má tento vlastník. Pokud nahrajete soubor pomocí FTP, přihlásíte se a soubor bude vlastněn uživatelem FTP. Protože máte pověření, můžete tyto soubory změnit pomocí FTP. Vlastník může soubor obvykle spustit, smazat, upravit atd. Samozřejmě to můžete změnit změnou oprávnění souboru .

Pokud nahráváte soubor pomocí PHP, uživatel linuxu, který je provádění PHP je vlastnictvím souboru. Tento uživatel nyní může soubor upravovat, mazat, spouštět atd. To je v pořádku, pokud pouze vy jste uživatel, který ve vašem systému provádí PHP.

Předpokládejme, že jste na „špatně“ nakonfigurovaném sdíleném hostiteli. Mnoho lidí provozuje na tomto systému své webové stránky PHP. Řekněme, že pouze jeden uživatel linuxu provádí PHP pro všechny tyto lidi. Jeden z webmasterů na tomto sdíleném hostiteli má špatné úmysly. Vidí vaši stránku a zjistí cestu k vaší instalaci WordPress. Například WP_DEBUG je nastaven na hodnotu true a zobrazuje se chybová zpráva jako

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

„Ha!“ říká zlý chlapec. Uvidíme, jestli tento člověk nastavil FS_METHOD na direct a napíše skript jako

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

Protože PHP používá pouze jeden uživatel a tento uživatel je také používán špatným klukem, může měnit / mazat / spouštět soubory ve vašem systému, pokud jste je nahráli přes PHP a podle toho připojili PHP uživatel jako vlastník.

Vaše stránka je hacknutá.

Nebo, jak se uvádí v kodexu:

Mnoho hostingových systémů má webový server spuštěný jako jiný uživatel než vlastník souborů WordPress. V takovém případě bude mít proces zápisu souborů od uživatele webového serveru výsledné soubory vlastněné uživatelským účtem webového serveru namísto účtu skutečného uživatele. To může vést k bezpečnostnímu problému v situacích sdíleného hostování, kdy více uživatelů sdílí stejný webový server na různých webech.

Jaké to je riziko?

Na špatně nakonfigurovaném sdíleném hostiteli bude PHP každého zákazníka spuštěno jako stejný uživatel (řekněme apache pro diskusi). Toto nastavení je překvapivě běžné.

Pokud jste na takovém hostiteli a používáte WordPress k instalaci pluginu pomocí přímého přístupu k souborům, všechny vaše soubory pluginů budou patřit do apache. Legitimní uživatel na stejném serveru by vás mohl napadnout napsáním skriptu PHP, který do vašich souborů pluginu vloží zlý kód. Nahrají svůj skript na svůj vlastní web a požádají o jeho URL. Váš kód byl úspěšně prolomen, protože jeho skript běží jako apache, stejný jako ten, který vlastní soubory vašich pluginů.

Co FS_METHOD "direct" to má společného?

Když WordPress potřebuje instalovat soubory (například plugin), použije get_filesystem_method () funkce k určení způsobu přístupu k souborovému systému. Pokud nedefinujete FS_METHOD, vybere vám výchozí nastavení, jinak použije váš výběr, pokud to má smysl.

Výchozí chování zkusí zjistit, zda se nacházíte v rizikovém prostředí, jako je ten, který jsem popsal výše, a pokud si myslí, že jste v bezpečí, použije metodu "direct". V tomto případě WordPress vytvoří soubory přímo přes PHP, což způsobí, že patří uživateli apache (v tomto příkladu). Jinak „se vrátím k bezpečnější metodě, jako je výzva k zadání pověření SFTP a vytváření souborů jako vy.

FS_METHOD = "direct" požádá WordPress, aby to obešel na -detekce rizik a vždy vytváření souborů pomocí metody "direct".

Proč tedy používat FS_METHOD = "direct"?

Logika WordPressu „pro detekci rizikového prostředí je bohužel chybná a vytváří falešně pozitivní i falešně negativní údaje. Jejda. Test zahrnuje vytvoření souboru a ujištění se, že patří stejnému vlastníkovi jako adresář, ve kterém žije. Předpokládá se, že pokud jsou uživatelé stejní, běží PHP jako váš vlastní účet a je bezpečné instalovat takové pluginy. Pokud se liší, WordPress předpokládá, že PHP běží jako sdílený účet a není bezpečné instalovat doplňky jako tento účet. Bohužel oba tyto předpoklady jsou poučené odhady, které se často mýlí.

Použili byste define("FS_METHOD", "direct" ); ve falešně pozitivním scénáři, jako je tento: jste součástí důvěryhodného týmu, jehož členové všichni nahrávají soubory prostřednictvím svého vlastního účtu. PHP běží jako svůj vlastní samostatný uživatel. WordPress bude předpokládat, že se jedná o rizikové prostředí, a nebude standardně v režimu "direct". Ve skutečnosti je sdílen pouze s uživateli, kterým důvěřujete, a "direct" režim je bezpečný. V takovém případě byste měli define("FS_METHOD", "direct" ); vynutit WordPressu, aby soubory psal přímo.

Komentáře

• Děkuji ty @mark, bylo to velmi užitečné! Možná budete muset aktualizovat get_filesystem_method() odkaz na tento: developer.wordpress.org/reference/functions/…

Existuje„ dobře nakonfigurovaný “ situace, kdy „přímé“ povede k problémům.

Je také možné nakonfigurovat sdílený hosting WP s nesdílenými uživateli spouštění PHP, odlišnými od uživatelů vlastnictví souborů / adresářů. Takže skončíte se soubory vlastněnými uživatelem1 a kód PHP se spustí jako php-uživatel1.

V takové situaci nemohou hacknuté doplňky nebo základní kód (a) zapisovat (ani z nich číst). , v závislosti na oprávnění) ředitelství ostatních uživatelů; (b) nemůže psát soubory tohoto uživatele a také nemůže přidávat trojský kód do kódu jádra nebo pluginu.

Takže pokud je hosting nastaven takhle , MUSÍTE pro aktualizace použít FTP a „přímý“ nebude fungovat.

Pokud nastavíte „přímý“ ve wp-config.php a uživatel, který provádí PHP, nemá oprávnění k zápisu, získáte aktualizaci Neúspěšné zprávy a nemají žádné vyskakovací okno vyžadující pověření FTP.