A fájlok feltöltése a kiszolgálóra, biztonság
Képzelje el a fájlok szokásos letöltését php használatával. Azt hiszem, mindenkinek szembe kellett néznie ezzel. Elvetheti a perverz beállításokat, például fájlok tárolását az adatbázisban, átnevezés, stb. A szokásos legegyszerűbb formátumú fájlfeltöltés.
Ez általában xmlml formátumú, majd kiszolgálóoldali érvényesítés a feltöltött fájl kibővítéséhez, majd a letöltött fájl áthelyezése az ideiglenes mappából a letöltési mappába. Elutasítjuk a programozók által a látszólag legegyszerűbb dolgokban elkövetett hibák millióit, és kiszámítjuk, hogy ez a funkció helyesen és hibamentesen valósul meg.
Van kérdés, de hogyan kell a fájlkiterjesztéseket szűrni? Két lehetőség közül választhat:
- A fehér listán - készítsen listát az érvényes fájlkiterjesztésekről és az összes többi blokkról
- A feketelistán - készítsen listát a blokkolt kiterjesztésekről, és mindazt, amit töltünk
A probléma az, hogy a szűrés végrehajtásához a fehér listán meg kell adnunk minden lehetséges lehetőséget a szükséges bővítmények számára, amelyek betölti a szkriptet. És ha olyan helyekre, ahol csak a képek letöltésére van szüksége - mindent egyszerű, akkor sok esetben a törvényes kiterjesztések meglehetősen nagy listáját kell összeállítania. Ezért sok fejlesztő úgy gondolja, hogy az ellenkezőjétől kell megy, és meg kell tiltani a veszélyes kiterjesztéseket.
És ha az első esetben sokan biztosak benne, hogy csak a szükséges bővítményekkel rendelkező fájlok lesznek kitöltve (ebben a cikkben megmondom, hogyan juthatsz hozzá), akkor a második esetben ez nem olyan egyszerű.
Kezdjük a szűrési problémákkal a fekete listán.
Heap kiterjesztések
Az első probléma az, hogy az alapértelmezett apache (bár ez nem lehet az alapértelmezett, de legalábbis nagyon gyakran), sok különböző kiterjesztésű fájl feldolgozása php parancsfájlként történik. Még mindig úgy gondolja, hogy elég csak blokkolni a ".php" -t? És itt vannak a számok, itt van egy hiányos lista lehetséges kiterjesztésekről:
php. phtml .php4 .php5.html
Igen, igen, bizonyos konfigurációkban az Apache ".html" php parancsfájlként feldolgozható.
És mi is elfelejtettük a cgi-t, a gyöngyöt és más finom cukrot. Igen, általában csak a / cgi-bin mappából lehet futtatni, de ki tudja, hogy a kiszolgáló másképpen van beállítva ...
És ez elég ahhoz, hogy ne hagyj ki legalább egy mellék, és a támadó, amikor megpróbálja feltörni, bizonnyal megpróbálja betölteni kiterjesztésű fájl, majd végrehajtja azt, ami valószínűleg egy teljes törés a webhelyen.
Változtassa meg a konfigurációt
Nos, mindent, az admin kiderült, hogy paranoiás, és minden futtatható kiterjesztést hozzáadott a szűrőhöz. De, ahogy mondják, minden trükkös csavarhoz van egy ravasz anya. Végül is a rendszergazda nem gondolt arra, hogy hozzáadja a ".htaccess" kiterjesztést (ha ez természetesen kiterjesztés: D) a szűrőlistára.
Megpróbálunk betölteni egy fájlt a ".htaccess" névvel az alábbiak szerint:
AddType alkalmazás / x-httpd-php .doc
És most a mappában, ahol ezt a fájlt letöltötték, a ".doc" kiterjesztéssel rendelkező fájlok php szkriptekként fognak kapcsolódni, és ennek megfelelően végrehajtják őket. Továbbra is letöltheti a php szkriptet ezzel a kiterjesztéssel, és sikeresen végrehajtódik.
Pour php.ini
Tegyük fel, hogy az admin tovább ment, és hozzáadta a ".ht *" kiterjesztést a listához, vagy ellenőrizzük a nem üres fájlnevet (ez megakadályozza a ".htaccess" fájl letöltését).
Nem is olyan régen írtam egy érdekes funkcióról a php + cgi csomag (és ahogyan a fastcgi is): PHP és CGI. A biztonsági korlátozások megkerülése
A támadás végrehajtásához a következő körülmények kombinációjával kell rendelkeznünk:
- A Php-t CGI-n keresztül kell csatlakoztatni
- A fájlok letöltött mappájának tartalmaznia kell legalább egy php parancsfájlt (például index.php)
- A szűrő nem vághatja le a .ini kiterjesztést (azaz meg kell kapnunk a php.ini fájlt)
A PHP-ben ilyen érdekes lehetőség van: auto_prepend_file:
Megadja a fájl nevét, amely automatikusan feldolgozza a főfájlt. A fájl úgynevezett, mintha a szükséges függvény használatával lett volna csatlakoztatva, így az include_path is használható.
Ha egy dióhéjban, minden parancsfájl végrehajtása előtt, az "auto_prepend_file" parancsban megadott script lesz először végrehajtva. Gondolod, mit vezetek?
; Engedélyezi a törölt fájlok olvasását (ehhez allow_url_include szükséges)
allow_url_fopen = 1
; Tegye bele a távoli befogadás lehetőségét
allow_url_include = 1
Feltöltötte a fájlt? Kiváló! Most minden olyan php szkriptre utalunk, amely abban a könyvtárban található, ahol az összes fájlt feltöltöttük (ezért írtam, hogy php script-re van szükségem ebben a mappában). Amikor elérte a parancsfájlt ebből a mappából, az automatikus_prepend_file fájlban megadott fájl végrehajtásra kerül.
"Dupla" kiterjesztés
"A mimikai kód az a referencia, hogy nem vagy tevék."
egy szomorú darab a magazinból] [akep
És tudod, hogy minden egyes kiterjesztésű fájlnak megvan a maga mimikai típusa? És ha letölti a fájlt, a webszerver megmondja a böngészőnek, hogy milyen típusú fájlt tartalmaz. Ezt a mime-típust az apache határozza meg, ha a fájlt speciális leképezési táblázattal bővíti ki. Bizonyos típusú webkiszolgáló végezhet bizonyos műveleteket ezzel a fájllal, például végrehajthatja ezt a fájlt php parancsfájlként vagy perl parancsfájlként, vagy egyszerűen feldolgozás nélkül adhatja meg a tartalmát.
Egyébként a .htaccess-ról szóló fejezetben hozzáadtuk mime-típusunkat a doc fájlokhoz, ezáltal kényszerítve a webszervert, hogy ezeket a fájlokat php parancsfájlokként feldolgozza. De általában nem arról szól.
Az a tény, hogy az apache általában "egyedi" webszerver. Logikusnak tűnik, hogy csak a fájl kiterjesztését ellenőrizze és nyugodjon meg, ugye? De itt a füge! Ha hirtelen kiderül, hogy nincs ilyen kiterjesztés a regisztrált felhasználók között, akkor az apache ellenőrzi a pont jelenlétét a fájl nevében, és kiválasztja a második kiterjesztést. Vagyis a mime típusát már a fájlnév részeként határozzák meg, nem pedig a "klasszikus" kiterjesztéssel. Így a mime-típus megadásáig vagy a fájlnév "kiterjesztései" nem fejeződnek be.
Mivel nagyon kevesen ismerik ezt a funkciót, ez a módszer lehetővé teszi a szűrők sikeres megkerülését, valamint a fehér listát (egyes esetekben) és a feketelistát (szinte mindig). Kerülő a fehér listán, meg kell találnunk a megengedett terhelést a kiterjesztés, amelyre a mime-type nincs megadva, akkor általában a kiterjesztése - «.rar» (Ez is egyetértenek, akkor soha nem gondolta volna, hogy így «.rar» betölteni megnyit egy hatalmas lyuk a biztonság?).
Szkriptet készítünk, átnevezzük "script.php.rar" -nek, és feltöltjük a szerverre. És egy csoda! Ezt a fájlt php szkriptnek értelmezzük!
Jegyezzük meg, hogy ez az apache chip veszélyes, mert nem teljesen logikus viselkedés a webszerver, és kevesen ismerik. Ez lehetővé teszi, hogy elkerülje a nagyszámú szűrőt.
És hogyan védekezhetsz?
Ideális esetben természetesen teljesen átnevezi a fájlt (beleértve a kiterjesztést is) egy bizonyos azonosítóba, és tárolja a fájllal kapcsolatos információkat az adatbázisban. Ezután, egy további kezelő használatával, nyissa ki a kívánt fájlt és annak adatait azonosítójával. De ez a módszer rossz, mert egy további kezelő használatát igényli.
De a fájlok közvetlen mentésével és azok későbbi visszaküldésével csak egy webszerver segítségével sokkal könnyebb és kevésbé erőforrásigényes, bár veszélyesebb. Annak érdekében, hogy egy normális szűrőt ezt a folyamatot, azt kell használni: első szűrés whitelist, másrészt, hogy távolítsa el / cserélni a speciális karaktereket a fájl nevét (pont törtvonal, nulbayty stb.)
És hogyan tölt fel fájlokat a kiszolgálóra?
Lásd még
- A PHP webhely védelme
A tetszőleges kód letöltésével és végrehajtásával szembeni védelem leírása. Hogyan védheti meg a php webhelyet a hackeléssel az auto_prepend_file használatával? A jogosulatlan szkriptek blokkolása.
Mindannyiunknak, egyféleképpen, biztos akar lenni abban, hogy senki sem csaphat le oldalunkon vagy blogunkon.
A php-támadás helyes lebonyolítása, beleértve a sávok hozzáadását a végéig. Az alternatíva null bájt. Miért ne vágja el a php inliding használatát?
A programozás mellett élvezem a webes alkalmazások biztonságát is. Rendelést végzek, és így tovább. És itt van.
Példa a PHP-től való védelemre. Egy módja annak, hogy megakadályozzuk a cracker támadásának felderítését és végrehajtását.
Gondoljunk csak veled, aki egy hacker? A hacker nem betörő! Az emberek gyakran összetévesztik ezeket a fogalmakat. Ez egy hacker.
A biztonságos mód megkerülésének módja és a nyitott alapú eljárás leírása. Biztonsági korlátozások megkerülése a phgi cgi-n keresztül történő csatlakozáskor.
Ma úgy éreztem, hogy jó lenne beszélni a php és cgi köteg (és a fastcgi) ilyen érdekes tulajdonságáról.
ne töltsön le, használja fel a külső szolgáltatók ingyenes forrásait)
Szintén opcióként) Csak ő, sajnos, nem illik minden esetben
Ami a kettős terjeszkedést illeti, ez az ón ... Nem tudtam ... Most ellenőriztem, és nagyon meglepődtem
A kétszeres bővítményekről komolyan félel ...
De nyilvánvalóan ez a hír a történelemkönyvekből. Csak ellenőrizni az Apache 2.2.17 (ami mellesleg már több mint két éve), hogy megpróbálja megnyitni egy fájlt script.php.rar mondta, felajánlva, hogy töltse le, kifejtve Típus: ismeretlen fájltípus, 13 bájt
Vagy fordítva ez a legfrissebb jellemző?
A mod_mime engedélyezve van.
Lehet, hogy különböző beállításaink vannak?
A httpd.conf tartalmaz: MIMEMagicFile conf / magic?
Sőt, a php.ini minden egyes könyvtárban való felvetésének megkérdezésével kérdezhetem, hogy a httpd.conf PHPIniDir utasítással tilos máshol keresni a php.ini-t?
Próbáljon meg egy nem szabványos "1.php.trololo" kiterjesztést megadni a fájlhoz, lehet, hogy van egy kezelője a * .rar kiterjesztéshez.
Ha nem tévedek, akkor a mod_mime_magic meghatározza a mime típusát a tartalmából, azaz. A MIMEMagicFile nem befolyásolja a problémát. De ha valami történik, akkor ki van kapcsolva.
És a php.ini felvételéről nem tudom elmondani. A LAN-on és a dev-kiszolgálón php kapcsolatom van a mod_php-en keresztül, nem pedig a cgi-n keresztül, így nem tudok ellenőrizni.
Erről a PHPIniDir-ről is kérdeztem, mert gondoltam, hogy PHPasCGI-nál (mindig is csak a modul volt).
Hmm ... Kiderül, hogy a rar valóban meghatározott mime.types
Még azt sem gondoltam, hogy ellenőrizem a képernyőt a képernyőn - Típus: Ismeretlen Fájltípus, 13 bájt (és kiderült, hogy ez a Windowsom nem tudta, mi a rar). Az 1.php.trololo verzió valóban megnyílt.
Feltöltés közben az admin panelen - még mindig módosíthatja a pontokat a kötőjelre, és amikor az ügyfélnek lehetősége van feltölteni a fájlokat ftp-en keresztül - nincs semmi védelme ...
Teljesen módosítanám a fájlnevet a kiterjesztéssel együtt, és az eredeti fájlnév tárolná az adatbázisban. Mondjuk a bűntől távol.
És mi van a ftp-vel? Itt is, ha megadja a lehetőséget, akkor töltsön fel fájlokat csak egy másik kiszolgálóra, ahol a php, a perl, a cgi és más dolgok le vannak tiltva. Nos, vagy írd fel saját ftp démonodat)
És az Apache beállításaiban nem adhat meg olyan demilitarizált zónát, amelyben semmilyen szkript nem fut le?
Egyszerre feltaláltam egy opciót: az FTP fájlokat helyez el olyan mappába, amely nem elérhető az interneten, és a fájlok különleges funkciót kapnak. Bár ismét - fejfájás lesz, hogy egy ember valami csodával ne küldjön valami hasonlóat:
MySite / GetFile.php? X = 123 /../../../../ jelszavakat
És az Apache beállításaiban nem adhat meg olyan demilitarizált zónát, amelyben semmilyen szkript nem fut le?
Tisztán elméletileg lehetséges. De az a tény, hogy egy személy kitöltheti a .htaccess-ot, amelyben újból meghatározhatja ezt a tilalmat.
Egyszerre feltaláltam egy opciót: az FTP fájlokat helyez el olyan mappába, amely nem elérhető az interneten, és a fájlok különleges funkciót kapnak.
Szintén meglehetősen ésszerű lehetőség)
És mi van akkor, ha a webhely tulajdonosa behozza a mappába még egy .htaccess fájlt, és rávetíti a jogokat "csak olvasásra"? Vagy más .htaccess letöltése nélkül még mindig nem ment?
Tévedhetek, de elméletben ebben az esetben továbbra is fennáll annak a lehetősége, hogy ezt a .htaccess fájlt egyszerűen törölni kell. És hozzon létre egy újat.
Hacsak nem lehetetlen a .htaccess mappák letöltésekor egyszerűen kikapcsolni az összes kezelőt az összes nyelven?
És mégis, valahogy azt a benyomást kelti, hogy a PHP-ben és az Apache-ban túl sok ilyen finomság, annyira kritikus a biztonság szempontjából
Elvileg nem szükséges feltölteni egy fájlt a public_html-en kívül. Lehetőség van betöltésre és public_html fájlba átnevezni például egy véletlenszerű md5 hash-ban vagy az aktuális időbélyegben, miközben az eredeti nevén lévő adatokat menteni az adatbázisban, és adja meg a script download.php
Ez két kölyköt öl meg egy kővel - és biztonságosan, és minden fajta UTF-8 és különleges karakter a fájlnévben nem érdekel.
Szintén egy lehetőség. Lehetőség van arra, hogy minden problémát megöljenek a bővítményekkel
Egy átlagos web-ra-bot-chik vagyok. Pi-shu itt, hogy én vagyok a-res, de amivel I-te-szükség-dan-ki-va-tsya a WEB területén, a gondolatok, Megváltoztathatom saját cikkeit.
Ne felejts el feliratkozni:
És nagyon pro-shu, nem for-would-wai, ami a kom-men-tari-t pro-chi-tan-ny-for-pi-syam-ra hagyta.