Nemrégiben volt egy olyan problémám, hogy nem tudtam telepíteni a WP Smush Pro plugint, mert nem rendelkezem kézi vagy egy kattintásos telepítéssel elérhető opciók.

Találtam ezt a bejegyzést , amely a beállítások módosítását javasolta a wp-config.php fájlban. Hozzáadtam a javasolt beállításokat, azonban az tűnik a legfontosabbnak:

define("FS_METHOD", "direct");

Amit szeretnék tudni milyen tényleges aggályok merülnének fel a FS_METHOD direct értékre állításával kapcsolatban? Van-e más alternatíva a bővítmény telepítésére?

A hivatalos dokumentáció ezt mondja ki:

Az FS_METHOD kényszeríti a fájlrendszer metódusát. Csak “direkt”, “ssh2″, ” ftpext “vagy” ftpsockets “. Általában ezt csak akkor szabad megváltoztatni, ha frissítési problémákkal küzd. Ha megváltoztatja, és ez nem segít, cserélje vissza / újra mozgatni. A legtöbb esetben az “ftpsockets” -re állítás akkor működik, ha az automatikusan kiválasztott módszer nem.

(Elsődleges beállítás) a “direct” arra kényszeríti, hogy a PHP-n belüli Direct File I / O kéréseket használja, ez tele van biztonsági problémák kinyitásával a rosszul konfigurált gazdagépeken. Ezt adott esetben automatikusan kiválasztják.

Válasz

Csak így értettem meg a WordPress File API ötletét. Ha ez téves, kérlek, mondj visszajelzést 🙂

Oké. Ha feltöltenek egy fájlt, ennek a fájlnak van tulajdonosa. Ha FTP-vel tölti fel a fájlt, akkor bejelentkezik, és a fájl az FTP felhasználó tulajdonában lesz. Mivel rendelkezik a hitelesítő adatokkal, ezeket a fájlokat az FTP-n keresztül módosíthatja. A tulajdonos általában végrehajthatja, törölheti, megváltoztathatja stb. A fájlt. Természetesen ezen változtathat a fájlengedélyek megváltoztatásával.

Ha egy fájlt PHP használatával tölt fel, akkor a linux felhasználó, amely a PHP végrehajtása a fájl tulajdonosa. Ez a felhasználó mostantól szerkesztheti, törölheti, futtathatja stb. Ez rendben van, amíg csak te vagy a felhasználó, aki a PHP-t futtatja a rendszereden.

Tegyük fel, hogy “rosszul” konfigurált megosztott gazdagépen vagy. Sokan ezen a rendszeren működtetik PHP-webhelyüket. Mondjuk, hogy csak egy linux felhasználó futtatja a PHP-t ezeknek az embereknek. A megosztott gazdagép egyik webmesterének rossz szándéka van. Meglátja az oldalát, és kitalálja a WordPress telepítés útját. Például a WP_DEBUG értéke true, és hibaüzenet jelenik meg, például 

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

“Ha!” a rossz fiú azt mondja. Lássuk, ha ez a srác a FS_METHOD -et direct -re állította, és ír egy olyan szkriptet, mint 

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

Mivel csak egy felhasználó futtatja a PHP-t, és ezt a felhasználót a rossz fiú is használja, megváltoztathatja / törölheti / végrehajthatja a rendszered fájljait, ha feltöltötted őket PHP-n keresztül, és ezzel csatoltad a PHP-t. felhasználó, mint tulajdonos.

Az Ön webhelyét feltörték.

Vagy, ahogy a Codex mondja:

Sok hosting rendszerben a webszerver más felhasználóként fut, mint a WordPress fájlok tulajdonosa. Ebben az esetben egy folyamatnak, amely fájlokat ír a webszerver felhasználójától, a kapott fájlok a webszerver felhasználói fiókjának tulajdonában lesznek a tényleges felhasználói fiók helyett. Ez biztonsági problémához vezethet megosztott tárhelyeken, amikor több felhasználó ugyanazt a webszervert osztja meg különböző webhelyeknél.

Válasz

Mi a kockázat?

Egy rosszul konfigurált megosztott gazdagépen minden ügyfél PHP-je ugyanazon felhasználóként fog végrehajtani (mondjuk apache beszélgetéshez). Ez a beállítás meglepően gyakori.

Ha ilyen gazdagépen tartózkodik, és a WordPress segítségével telepíti a bővítményt közvetlen fájleléréssel, a bővítményfájljai az apache fájlhoz tartoznak. Ugyanazon a szerveren egy jogos felhasználó megtámadhat egy PHP parancsfájl írásával, amely gonosz kódot juttat a plugin fájljaiba. Feltöltenék a szkriptet a saját webhelyükre, és kérik annak URL-jét. A kódod sikeresen sérült, mert a szkript apache néven fut, ugyanaz, amelyik a plugin-fájljaidé.

Mit jelent FS_METHOD "direct" köze van hozzá?

Ha a WordPress-nek fájlokat kell telepítenie (például egy plugint), akkor a get_filesystem_method () függvény a fájlrendszer elérésének meghatározásához. Ha nem definiálja a FS_METHOD beállítást, akkor az alapértelmezett értéket választja, ellenkező esetben addig használja a választást, amíg van értelme.

Az alapértelmezett viselkedés megpróbálja megpróbálni kideríteni, hogy veszélyeztetett környezetben van-e, például egyet, amelyet fentebb leírtam, és ha úgy gondolja, hogy biztonságban van, akkor a "direct" metódust használja. Ebben az esetben a WordPress közvetlenül a PHP-n keresztül hozza létre a fájlokat, ezáltal az apache felhasználóhoz tartozik (ebben a példában). Ellenkező esetben ez egy biztonságosabb módszerre fog visszatérni, például SFTP-hitelesítő adatok megadására és a fájlok önálló létrehozására.

FS_METHOD = "direct" arra kéri a WordPress-t, hogy kerülje meg ezt: -risk észlelés és mindig fájlokat hozhat létre a "direct" módszerrel.

Akkor miért használja a FS_METHOD = "direct"?

Sajnos a WordPress “kockázati környezet észlelésére szolgáló” logikája hibás, és hamis pozitívakat és hamis negatívokat egyaránt eredményez. Hoppá. A teszt egy fájl létrehozásával jár, és megbizonyosodik arról, hogy az ugyanazon tulajdonoshoz tartozik-e, mint a könyvtár, amelyben él. Feltételezzük, hogy ha a felhasználók azonosak, akkor a PHP saját fiókként fut, és biztonságosan telepítheti a beépülő modulokat. fiókot. Ha különböznek egymástól, a WordPress feltételezi, hogy a PHP megosztott fiókként fut, és nem biztonságos a beépülő modulok telepítése az adott fiókként. Sajnos mindkét feltételezés tanult találgatás, amely gyakran téves lesz.

A define("FS_METHOD", "direct" ); -et egy hamis pozitív helyzetben használná, mint ez: Ön egy megbízható csapat tagja, amelynek tagjai mind a saját fiókjukon keresztül töltenek fel fájlokat. A PHP különállóként fut felhasználó. A WordPress feltételezi, hogy ez veszélyeztetett környezet, és nem alapértelmezés szerint "direct" módot használ. A valóságban csak olyan felhasználókkal oszlik meg, akikben megbízik, és mint ilyenek "direct" mód biztonságos. Ebben az esetben a define("FS_METHOD", "direct" ); paranccsal kényszerítheti a WordPress-t a fájlok közvetlen írására.

Megjegyzések

Válasz

Van egy” jól konfigurált ” olyan helyzet, amikor a “közvetlen” problémákhoz vezet.

A megosztott WP-hosztolást nem megosztott PHP-végrehajtási felhasználókkal is konfigurálhatjuk, eltérően a fájlok / könyvtárak tulajdonosaitól. Tehát a user1 tulajdonában lévő fájlokhoz jutsz, és a PHP kódot php-user1 néven hajtják végre.

Ebben a helyzetben a feltört beépülő modulok vagy az (a) törzskód nem írhat (vagy nem is olvashat el onnan) , a jogosultságoktól függően) más felhasználók “címtár; (b) nem írhatja a ennek a felhasználónak a fájljait, és így nem adhat hozzá trójai kódot sem az alap-, sem a beépülő modulhoz.

Tehát ha a tárhely így van beállítva , KELL KELL használnia az FTP-t a frissítésekhez, és a “direct” nem fog működni.

Ha a wp-config.php fájlban beállította a “direct” beállítást, és a PHP végrehajtó felhasználónak nincs írási engedélye, akkor frissítést kap Sikertelen üzenetek, és nincsenek FTP-hitelesítő adatokat kérő előugró ablakok.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük