PHP bizonsági kiegészítés: írható fájlok végrehajtásának blokkolása

Internet: PHP, CGI, stb.

Rég óta hányom-vetem magamban egy biztonsági kiterjesztés írását. Az ötlet egyszerű: ha egy fájl írható a PHP-t futtató process által, akkor tagadjuk meg a végrehajtást.

Ezzel egy támadási irány kiküszöbölhető: ha a támadó feltölt egy php fájlt (egy feltölő modult megtrükközve), vagy sikerül módosítania egy létező PHP szkript tartalmát.

A legtöbb rendszerben megoldható, hogy az FTP-hez használt user különbözzön a szkriptet végrehajtótól (modulnál eleve a www user hasjtja végre a szkripteket suPHP esetén pedig lehet egy külön FTP felhasználó más UIDdal).

Lenne értelme ilyesminek?

  • 4269 megtekintés

( joco01 v | 2014. 10. 11., szo – 13:28 )

Rosszindulató user feltölt egy PHP fájlt, és leveszi róla a saját írási jogát, úgysincs rá szüksége. Eleve akkor van baj, ha egyáltalán képes a PHP írni akár bárhova. Nem kell neki jogot adni erre, és ennyi. Kaphat jogot írni bizonyos feltöltős mappákba, de onnan meg webszerver configgal kell kitiltani a PHP végrehajtást.

--

Tényleg, bocsánat.

Kaphat jogot írni bizonyos feltöltős mappákba, de onnan meg webszerver configgal kell kitiltani a PHP végrehajtást.

Igen, ez a jó praktika, de amikor a tiltást külön el kell végezni, figyelmetlenségből könnyen kimaradhat. Néhány kulcsra kész tartalomkezelő (pl Wordpress és változó minőségű moduljai) lég szerteágazó kívánlamakkal rendelkeznek, ha a beállításokban le szeretnéd fedni az összes ilyen könytárat.

Hasonló kész megoldásokat telepíthetnek kellő tudás és körültekintés nékül is. Ha egy plugin nem tartalmaz saját htaccess szabályokat komolyan bele kellene nézni a kódjába, hogy mit és hogyan csinál, hogy szabályokat alkothass hozzá.

Wordpresst nem ismerem, de a Drupalnál van egy könyvtár, ahova a feltöltött fájlok kerülnek (általában ez a sites/default/files), ott a webszerver által tiltva van a futtatás. Ahova pedig engedélyezett a futtatás, oda nem lehet feltölteni külső fájlokat. Extra bónuszként alapértelmezetten átnevezi feltöltéskor a veszélyesebb fájlokat, extra 'txt' kiterjesztést kapnak. 

preg_match('/\.(php|pl|py|cgi|asp|js)(\.|$)/i', $file->filename)

https://api.drupal.org/api/drupal/includes!file.inc/function/file_save_…

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…

ezzel az erővel a jpg sem veszélytelen. php.hide találatok tucatjával potyognak be minden éjszaka. Bár az is igaz, hogy a fenti kiterjesztéseket utána meghívhatja, a jpg-t meg talán semmi nem akarja parse-olni.

http://php.webtutor.pl/en/2011/05/13/php-code-injection-a-simple-virus-…

KoviX

( VincentV | 2014. 10. 11., szo – 13:47 )

Masszív, 1000-es nagyságrendű weboldalakat kiszolgáló környezetben én azt tapasztaltam az elmúlt 6 évben, hogy kizárólag trójaival és egyébbel lenyúlt (kliens oldali mentett jelszó, vagy keylogger) valid ftp accounttal léptek be, és azzal írták felül a php vagy html file-okat.

Szóval az esetek nagy részére nem adna megoldást az ötleted, persze más esetekre ettől még igen, csak összességében én úgy érzem hogy kevésbé lépnél előre, a fentiek miatt.

Igen, valóban nem ez a leggyakoribb támadási irány (persze jelen lehet az általad detektált explitok között is).

Nem számítok rá, hogy ez nagyságrendeket dobna majd egy szerver biztonságán. Ami párhozammal tudok szolgálni az a régi PHPs allow_url_include beállítás, ami nem megfelelően ellenőrzött user input esetén könnyen kihasználható volt:


// sebezhető szkript
include($_GET["modul"] . ".php");

... ami után elég volt egy URL-t átadni a modul paraméterként.

Jó párhuzam, mert lehetnek legitim felhasznélássai távoli szerverről történő fájl betöltésének, viszont az esetek 99%-ban nem használt funckióról van szó.

Ez után a logikus lépés az volt, hogy alapértelmezésben kikapcsolttá tették ezt a funkcionalitást, aki meg bekapcsolja az jobb, ha tudja mit csinál.

"Szóval az esetek nagy részére nem adna megoldást az ötleted"

De, csak ne a tomeghosting piacot nezd, hanem a nagycegeset. "Minosegi" PHP alkalmazas ott is van epp eleg, de az admin gepen a jelszolopo malware szerencsere eleg ritka.

--
"You're NOT paranoid, we really are out to get you!"

( eax | 2014. 10. 11., szo – 19:24 )

"Lenne értelme ilyesminek?"

Teljesen, ez kb. a W^X alkalmazasa PHP-kodra, egyebkent a suhosin tud ilyet.
A gond ott van ezzel, hogy a PHP-nak neha megis tudnia kell irni futtathato kodot (auto-update, plugin install, templating engine-ek, stb).

--
"You're NOT paranoid, we really are out to get you!"

( uid_17626 | 2014. 10. 11., szo – 21:17 )

Miért kell neked a direkt fájlba írás? Nem tudod kihagyni a műveletből?