Minulla on äskettäin ollut ongelma, jossa en ole voinut asentaa WP Smush Pro -laajennusta, koska minulla ei ole manuaalista tai yhdellä napsautuksella tehtävää asennusta käytettävissä olevat vaihtoehdot.
törmäsin tähän viestiin , jossa ehdotettiin asetusten muokkaamista wp-config.php
-sivulla. Lisäsin ehdotetut asetukset, mutta tärkeimmältä vaikuttava on:
define("FS_METHOD", "direct");
Mitä haluaisin tietää mitä todellisia huolenaiheita minun pitäisi olla siitä, kun asetan FS_METHOD
arvoon direct
? Onko laajennuksen asentamiselle muita vaihtoehtoja?
Näin virallisessa dokumentaatiossa on sanottava:
FS_METHOD pakottaa tiedostojärjestelmän menetelmän. Sen tulisi olla vain ”suora”, ”ssh2″, ” ftpext ”tai” ftpsockets ”. Yleensä tämä tulisi muuttaa vain, jos sinulla on päivitysongelmia. Jos muutat sitä ja se ei auta, vaihda se takaisin / uudelleen Siirrä se. Useimmissa tapauksissa sen asettaminen ftpsocketsiksi toimii, jos automaattisesti valittu menetelmä ei toimi.
(Ensisijainen asetus) ”direct” pakottaa sen käyttämään suoria File I / O -pyyntöjä PHP: ltä, tämä on täynnä tietoturvaongelmien avaamista huonosti määritetyille koneille. Tämä valitaan tarvittaessa.
Vastaa
Juuri näin ymmärsin WordPress File API -sovelluksen idean. Jos se on väärin, alenna äänestystä 🙂
Okei. Jos lataat tiedoston, tällä tiedostolla on omistaja. Jos lataat tiedoston FTP: llä, kirjaudut sisään ja tiedosto on FTP-käyttäjän omistuksessa. Koska sinulla on kirjautumistiedot, voit muuttaa näitä tiedostoja FTP: n kautta. Omistaja voi yleensä suorittaa, poistaa, muuttaa jne. Tiedoston. Voit tietysti muuttaa tätä muuttamalla -tiedoston käyttöoikeuksia .
Jos lataat tiedoston PHP: llä, linux-käyttäjä, joka on PHP: n suorittaminen on tiedoston omistaminen. Tämä käyttäjä voi nyt muokata, poistaa, suorittaa jne. Tiedostoa. Tämä on okei niin kauan kuin vain sinä olet käyttäjä, joka suorittaa PHP: tä järjestelmässäsi.
Oletetaan, että olet ”huonosti” määritetyllä jaetulla isännällä. Monet ihmiset käyttävät PHP-verkkosivustojaan tässä järjestelmässä. Sanotaan vain, että vain yksi Linux-käyttäjä suorittaa PHP: tä kaikille näille ihmisille. Yhdellä tämän jaetun isännän verkkovastaavista on huonoja aikomuksia. Hän näkee sivusi ja selvittää polun WordPress-asennukseesi. Esimerkiksi WP_DEBUG on asetettu tosi-arvoon ja virheilmoitus, kuten
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1
”Ha!” paha poika sanoo. Katsotaan, jos tämä kaveri on asettanut FS_METHOD
-asetukseksi direct
ja kirjoittaa komentosarjan, kuten
<?php unlink( "/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php" ); ?>
Koska vain yksi käyttäjä käyttää PHP: tä ja paha poika käyttää myös tätä käyttäjää, hän voi muuttaa / poistaa / suorittaa järjestelmässäsi olevia tiedostoja, jos olet ladannut ne PHP: n kautta ja täten liittänyt PHP: n käyttäjä omistajana.
Sivustoosi on hakkeroitu.
Tai, kuten Codexissa sanotaan:
Monissa isäntäjärjestelmissä verkkopalvelin toimii eri käyttäjänä kuin WordPress-tiedostojen omistaja. Tällöin prosessissa, joka kirjoittaa tiedostoja verkkopalvelimen käyttäjältä, tuloksena olevat tiedostot omistaa verkkopalvelimen käyttäjätili todellisen käyttäjän tilin sijaan. Tämä voi johtaa tietoturvaongelmiin jaetuissa isännöintitilanteissa, joissa useat käyttäjät jakavat saman verkkopalvelimen eri sivustoille.
Vastaa
Mikä riski on?
Huonosti määritetyllä jaetulla isännällä jokaisen asiakkaan PHP suorittaa saman käyttäjän (sanotaan apache
keskusteluun). Tämä asetus on yllättävän yleinen.
Jos olet tällaisessa isännässä ja asennat laajennuksen WordPress-sovelluksella suoraa tiedostoa käyttämällä, kaikki laajennustiedostosi kuuluvat ryhmään apache
. Saman palvelimen laillinen käyttäjä voisi hyökätä sinua kirjoittamalla PHP-komentosarjan, joka pistää pahan koodin laajennustiedostoihisi. He lataavat käsikirjoituksen omalle verkkosivustolleen ja pyytävät sen URL-osoitetta. Koodisi vaarantuu, koska heidän komentosarjansa toimii nimellä apache
, joka on sama kuin laajennustiedostosi.
Mitä FS_METHOD "direct"
Onko sinulla tekemistä sen kanssa?
Kun WordPress tarvitsee asentaa tiedostoja (kuten laajennuksen), se käyttää get_filesystem_method () -toiminto määrittääksesi, miten tiedostojärjestelmää käytetään. Jos et määritä FS_METHOD
, se valitsee sinulle oletusasetuksen, muuten se käyttää valintasi niin kauan kuin sillä on järkeä.
Oletuskäyttäytyminen yrittää havaita, oletko vaarallisessa ympäristössä, kuten yhden, jonka kuvasin edellä, ja jos se uskoo olevasi turvallinen, se käyttää menetelmää "direct"
. Tässä tapauksessa WordPress luo tiedostot suoraan PHP: n kautta, jolloin ne kuuluvat apache
-käyttäjälle (tässä esimerkissä). Muuten se palaa turvallisempaan menetelmään, kuten SFTP-kirjautumistietojen pyytämiseen ja tiedostojen luomiseen samalla tavalla.
FS_METHOD = "direct"
pyytää WordPressiä ohittamaan sen -riskien tunnistus ja aina luo tiedostoja "direct"
-menetelmällä.
Miksi sitten käyttää FS_METHOD = "direct"
?
Valitettavasti WordPress-logiikka vaarallisen ympäristön havaitsemiseksi on puutteellinen ja tuottaa sekä vääriä positiivisia että vääriä negatiivisia. Oho. Testi sisältää tiedoston luomisen ja sen varmistamisen, että se kuuluu samalle omistajalle kuin hakemisto, jossa se asuu. Oletuksena on, että jos käyttäjät ovat samat, PHP toimii omana tilinäsi ja laajennusten asentaminen on turvallista. Jos ne eroavat toisistaan, WordPress olettaa, että PHP toimii jaettuna tilinä, eikä laajennusten asentaminen kyseisenä tilinä ole turvallista. Valitettavasti molemmat oletukset ovat harhaanjohtavia arvauksia, jotka ovat usein vääriä.
Käytät define("FS_METHOD", "direct" );
väärässä positiivisessa tilanteessa, kuten tässä: olet osa luotettua tiimiä, jonka jäsenet lähettävät kaikki tiedostot oman tilinsä kautta. PHP toimii omana erillisenä Käyttäjä. WordPress olettaa, että tämä on vaarassa oleva ympäristö, eikä se oletusarvoisesti ole "direct"
-tilaa. Todellisuudessa se jaetaan vain luotettavien käyttäjien kanssa ja sellaisenaan "direct"
-tila on turvallinen. Tässä tapauksessa sinun on pakotettava define("FS_METHOD", "direct" );
pakottamaan WordPress kirjoittamaan tiedostoja suoraan.
Kommentit
vastaus
On olemassa” hyvin määritetty ” tilanne, jossa ”suora” johtaa ongelmiin.
On myös mahdollista määrittää jaettu WP-isännöinti muiden kuin jaettujen PHP-suorituskäyttäjien kanssa. Joten päädyt käyttäjän1 omistamiin tiedostoihin ja PHP-koodi suoritetaan nimellä php-käyttäjä1.
Siinä tilanteessa hakkeroidut laajennukset tai ydinkoodi (a) eivät voi kirjoittaa (tai edes lukea) , käyttöoikeuksista riippuen) muiden käyttäjien hakemisto; (b) ei voi kirjoittaa tämän käyttäjän tiedostoja, joten ei voi lisätä troijalaiskoodia ydin- tai laajennuskoodiin.
Joten jos isännöinti on määritetty näin , sinun on käytettävä FTP: tä päivityksiin ja ”suora” ei toimi.
Jos asetat ”suora” wp-config.php -ohjelmaan ja PHP-suorituskäyttäjällä ei ole kirjoitusoikeuksia, saat päivityksen Epäonnistuneet viestit, eikä ponnahdusikkunassa ole kysytty FTP-kirjautumistietoja.
get_filesystem_method()
-linkin tähän linkkiin: developer.wordpress.org/reference/functions/…