GNU/Linux >> Znalost Linux >  >> Linux

Proč je v kontextu PHP / Apache / Linux přesně chmod 777 nebezpečný?

Existuje mnoho dobrých obecných důvodů, proč se řídit minimalismem, pokud jde o oprávnění, ale v kontextu webhostingu LAMP je těch několik, které snadno napadnou

  • Na sdílené hostitelské platformě mohou nyní ostatní uživatelé sdílející váš hostitel číst vaše skripty a zapisovat do nich.
  • Na vyhrazeném hostiteli mohou nečestné procesy číst a zapisovat vaše soubory a náhodně je smazat. Řekněme, že na pozadí běží vlastní proces protokolování jako uživatel nikdo, který má chybu, která vede k pokusu o rm -rf / . Nyní to bude obecně neškodné, protože by stěží existoval nějaký soubor, do kterého by nikdo neměl mít oprávnění k zápisu, ale tento nepoctivý proces nyní vezme vaše soubory s sebou.
  • Chcete-li znehodnotit váš web, někdo potřebuje získat přístup pouze jako jakýkoli uživatel, třeba i nobody nebo nějaký takový fiktivní účet. Obecně by útočník musel provést další eskalační útok na uživatelské úrovni, aby se dostal na místo, kde může způsobit nějakou škodu. To je skutečná hrozba. Některé nekritické služby mohou být spuštěny pod fiktivními účty a mohou obsahovat chybu zabezpečení.

Výrazně zvyšuje profil zranitelnosti vašeho webu vůči škodlivé činnosti, protože je nutné proniknout pouze do jednoho účtu.

Kdokoli, kdo získá přístup k vašemu systému s jakýmkoliv přihlášením, může s vašimi stránkami dělat, co chce, včetně jejich změny na „Tento web je opravdu nezabezpečený, dejte mi prosím informace o své kreditní kartě.“

EDIT:(Pro upřesnění a vyřešení komentářů)

Mnoho serverů má v životě více než jeden účel. Provozují více služeb. Pokud tyto služby od sebe pečlivě izolujete tím, že každé z nich přiřadíte jedinečného uživatele a podle toho spravujete oprávnění k souborům, ano, jste stále v horké vodě, pokud někdo kompromituje přihlašovací údaje k účtu, ale škoda, kterou může způsobit, je omezena na tuto jednu službu. . Pokud máte pouze jeden obecný účet a celý souborový systém nastavíte na 777, jeden kompromitovaný účet ohrozí vše na počítači.

Pokud je váš server vyhrazen pouze pro běh Apache/PHP a neslouží žádnému jinému účelu v životě a existuje pouze jeden účet, pod kterým je Apache/PHP spuštěn, mít tento jeden účet kompromitován je stejně dobře, jako nechat kompromitovat celý počítač z z pohledu vaší aplikace (ačkoli byste stále měli mít systémové soubory chráněné a nezapisovatelné účtem používaným ke spuštění PHP... to by stále mělo být možné pouze pro účet správce/root).

Pokud mohou napsat soubor a ten je spustitelný, mohou jej změnit na něco, co se spustí na vašem počítači (spustitelný soubor nebo skript) a pak použít PHP shell_exec ke spuštění tohoto spustitelného souboru. Pokud jste nakonfigurováni tak, že nepovolíte shell_exec, mohou změnit vaši konfiguraci také


Zde je jeden scénář:

  1. Máte nechráněný adresář, do kterého mohou uživatelé nahrávat.
  2. Nahrají dva soubory:skript shellu a soubor php, který má system() zavolejte jej do skriptu shellu.
  3. K php skriptu, který právě nahráli, přistupují tak, že navštíví adresu URL ve svém prohlížeči, což způsobí spuštění skriptu shellu.

Pokud je tento adresář 777, znamená to, že jej může spustit kdokoli (včetně uživatele apache, což je to, co bude php skript provádět)! Pokud v tomto adresáři a pravděpodobně v souborech v adresáři není nastaven spouštěcí bit, pak výše uvedený krok 3 nic neudělá.

upravit z komentářů:nezáleží na oprávněních souboru PHP, ale na system() volání uvnitř souboru PHP, které bude spuštěno jako systémové volání linuxu linuxovým uživatelem apache (nebo cokoli, co máte na apache nastaveno, aby se spouštělo jako), a to je PŘESNĚ tam, kde na bitu provedení záleží.


Linux
  1. Příkaz chmod pro Linux

  2. Jak zkontrolovat moduly PHP a Apache, které jsou nainstalovány v systému Linux?

  3. Změna oprávnění pro Linux

  1. Jak nainstalovat Suphp s Apache na Ubuntu / Linux

  2. Jak nainstalovat LAMP (Linux, Apache, MySQL, PHP) na Debian 9

  3. Jak povolím SQLite na Linuxu/Apache/PHP?

  1. Změnit účet na Linux Dropbox?

  2. Upozornění na chyby segmentace webového serveru Linux / Apache

  3. Proč je chmod -R 777 / destruktivní?