Default bezpecnostne opatrenia – htaccess

před 22 dny

vladimir.biro
Člen | 108
+
0
-

Ahojte.

Viete niekto, preco v nette baliku na githube nie su adresare v app a log automaticky zabezpecene pomocou .htaccess, ako je napriklad vendor? V dokumentacii je napisane, ze si to tam treba pridat a preto mi vrta v hlave, preco to tam nie je uz priamo v baliku.

Ma to nejaky dovod?

Dik :)

před 22 dny

David Grudl
Nette Core | 7057
+
0
-

Ten soubor tam je.

před 21 dny

Polki
Backer | 247
+
0
-

Myslím Davide, že na to se Vláďa neptal…

David Grudl napsal(a):

Ten soubor tam je.

Valná většina malých a středních projektů používá nějaký základní hosting, kam nahrají Nette Sandbox, ve VirtualHostech (které nemohou měnit) je od poskytovatele nastavený adresář ten, kam nahráli Nette Sandbox a teď musí řešit, jak přesměrovat dotazy, které přijdou do podsložky www.

  • DNS nepomůže, ta se nastavuje pouze na IP adresy ne na podsložky.
  • VirtualHost nepomůže, jelikož tam má přístup pouze poskytovatel hostingu
  • Poslední možnost (o které vím, případně mě doplň) je překopání .htaccess souboru co jsi poslal.

Tato poslední možnost znamená ale to, že ten soubor, na který odkazuješ je nutné předělat tak, že to co v něm je odstraníš a přidáš nové řádky, které veškeré dotazy do této složky přesměrují do složky /www

V tom případě se ale otevřela cesta i do ostatních složek, o kterých píše Vláďa. Takže ty .htaccess soubory jak Vláďa píše se tam musí přidat a je to strašně otravné. V minulých verzích sandboxu tam byly co vím. A upřímně taky nerozumím proč tam pořád nejsou.

Rozumím, že když si někdo pořídí VPSko, tak tam si to nastaví jak chce a nemusí toto řešit. Ale používat VPS za 1500/rok na projekt malého rázu, kam stačí hosting za 170/rok je asi jako vypustit přehradu abych z ní vytáhl 1 kapra…

Editoval Polki (5. 5. 13:09)

před 21 dny

David Grudl
Nette Core | 7057
+
0
-

To už teda hodně domýšlíš otázku – je to rozhodně zajímavé téma, ale spíš do nového vlákna. Zpracovat a dát do dokumentace nastavení adresářové struktury pro jednotlivé typy hostingů. Nebo možná ještě lépe seznam hostingu, kde nejde nastavit document_root (a proto je nepoužívat, .htaccess není řešení) + těch kde to lze.

před 21 dny

Polki
Backer | 247
+
0
-

@DavidGrudl To je dobrý nápad. Ovšem někdy má zákazník nějaký svůj hosting, který si platí a má jej předplacený na delší dobu a tedy jej měnit nechce. V takovém případě doporučení, které mi říká, že na tomto hostingu nemám Nette využívat, není relevantní, jelikož jej stejně budu muset využít.

před 21 dny

David Grudl
Nette Core | 7057
+
+3
-

Pokud má klient hosting s PHP 5.3, také na něm nemůže hostovat aktuální Nette. Obojí je relevantní informace.

(Možná to s tou adresářovou strukturou půjde nějak našolíchat, ale sám bych se toho bál a určitě to nebudu někomu radit.)

před 21 dny

Polki
Backer | 247
+
0
-

Ještě jsem snad nenarazil na hosting, na kterém by nešlo jednoduše v administraci přepnout, jaká se používá verze PHP. Dnes snad už všechny podporují minimálně PHP 7.3.12, což měnit document_root u všech tak jednoduše, zdali vůbec, nejde.

(Možná to s tou adresářovou strukturou půjde nějak našolíchat, ale sám bych se toho bál a určitě to nebudu někomu radit.)

Kdo to teda radí například tady? A proč to vůbec vzniklo, když je to tak špatně?

Editoval Polki (5. 5. 20:11)

před 21 dny

vladimir.biro
Člen | 108
+
0
-

Vsechno je to hodne zajimave, no pravdu mel David v prvni reakci :D

Myslel jsem opravdu ten soubor a vidim, ze co se SandBoxu tyce, tak tam opravdu je, ale je jen v rootu.
Proc ale neni primo v adresarech jako app, log?

před 20 dny

David Grudl
Nette Core | 7057
+
0
-

@Polki teď nevím, kam se mě snažíš dotlačit. Pokud někdo používá špatný hosting, tak ho má změnit, jsou jich stovky a stojí pár korun. Pokud nechce, ok, ale proč by mě to mělo zajímat? Kdo to napsal do docky můžeš najít v git blame.

před 20 dny

David Grudl
Nette Core | 7057
+
+3
-

Myslel jsem opravdu ten soubor a vidim, ze co se SandBoxu tyce, tak tam opravdu je, ale je jen v rootu.
Proc ale neni primo v adresarech jako app, log?

Připadá mi jako lepší řešení mít jeden soubor který navíc chrání všechny (i budoucí adresáře).

před 20 dny

Šaman
Člen | 2427
+
+1
-

No, vadilo by něčemu mít to navíc i v těch defaultních adresářích?

před 20 dny

David Grudl
Nette Core | 7057
+
0
-

Vy to někdo reálně v těch adresářích máte? A proč?

před 20 dny

Polki
Backer | 247
+
0
-

WEDOS
ENDORA
atd.

Zakázáno ručně měnit httpd.conf je povětšinou z důvodů sdílení hardwaru mezi různými virtuálními stroji bezpečnostní záležitostí. Pokud to má nějakým způsobem hosting povoleno a vše ošetřeno, nevidím problém.

Citace z jakpsatweb : Server Apache se obvykle konfiguruje pomocí souboru httpd.conf. Tento soubor httpd.conf leží kdesi na serveru a má k němu přístup jenom administrátor serveru. To je organizačně náročné, proto vznikla možnost používat .htaccess.

Obecně pokud je server sdílený a běží na něm povícero hostingů, je nezodpovědné nechat měnit uživatele nastavení serveru. (Jistě, dnes již jsou způsoby jak vše izolovat, ale to je na jinou debatu.) .htaccess je tedy náhrada za httpd.conf, která umožní aplikovat nastavení v rámci daného adresáře. Jestli se tedy problém přesměrování do výchozího adresáře {DOCUMENT_ROOT}/www provede pomocí přenastavení document_root v httpd.conf, nebo přesměrováním všech přístupů v .htaccess je z mého pohledu úplně jedno.

Tím, že se explicitně Nette chová tak, že nepodporuje obě verze (proč očividně nikdo netuší) se Nette staví do pozice ‚použiji ho jen tam, kde mi to hosting dovolí‘.

Pokud nechce, ok, ale proč by mě to mělo zajímat?

Myslel jsem, že jsi chtěl, aby se Nette používalo a bylo populární. Obecně se setkávám s přístupem, že lidi, kteří své práci rozumí stejně jako ty do takových projektů nejdou. Firma si pak najde méně zkušeného člověka, který práci nějak slepí jak se dočte různě na fórech a když se pak firma rozroste a potřebuje v systému změny, na které nezkušený člověk nestačí a najme si firmu, tak se firma zhrozí nad takovým kódem a potom slýchávám, jak je Nette špatné, jelikož se v něm píšou věci špatně. To obecně není pravda. Jen za to mohou takováto rozhodnutí. Obecně tato rozhodnutí platí pro všechny jazyky/frameworky. Toto mě přivádí k otázce, zdali právě tento tvůj přístup Davide není ten důvod, proč se Nette nerozrostlo jak jsi čekal, jak říkáš v jednom svém rozhovoru pro mladypodnikatel.

teď nevím, kam se mě snažíš dotlačit.

Nikam :) Snažím se vést nějakou konstruktivní debatu. Neber prosím nic z toho co píšu jako útok. Všichni se můžeme plést. Je i dosti možné, že se i v této konverzaci já pletu. Jde jen o to najít tu cestu a znát všechny důvody proč ji zvolit a jestli je v pohodě tyto věci co jsem popsal v tomto komentáři tak nechat tedy jestli je v pohodě se ošidit o skupinu zákazníků, kteří využívají nedoporučené hostingy. (Například na wedosu běží spousta firemních webů a přijde mi škoda o takové množství uživatelů Nette přijít.)

před 20 dny

David Grudl
Nette Core | 7057
+
0
-

Fakt netuším, co tě štve, vůbec nechápu smysl této diskuse, nevím jak v ní pokračovat. Nette je použitelné snad na každém hostingu, v jakýchkoliv adresářových strukturách a je to mimořádně úspěšný framework, ale chceš mi asi říct, že dělám něco špatně, je to možný, ale nechápu tvá slova, tak ukaž jak to udělat líp a změň kód nebo něco dopiš dokumentace nebo nevím co, napiš blogpost, prostě to nějak vyřeš a nesuď mě.

před 20 dny

Šaman
Člen | 2427
+
+6
-

Jestli to dobře chápu, tak Polki a vladimir.biro by byli rádi, kdyby byl .htaccess zakazující přístup i ve složkách app, log a temp (a v takovém případě bych to dal i do app/config, kde jsou klíčky). Protože když někdo neodborně upraví ten v rootu, může vzniknout bezpečnostní díra.

Otázkou je, jestli by tam ty soubory něčemu vadily, i když v defaultním použití jen duplikují už zděděné restrikce.

P.S. Tak koukám, že v projektu na Nette 2.4 tam ty htaccessy všude mám. Na novém už ne a na localhostu, kde mám upravený .htaccess pro snadné listování v projektech, tam mohu ručně zapsat adresu configu a on se zobrazí. Trochu mě to vyděsilo, ale na produkci je naštěstí ostrý .htaccess, tam je to v pořádku.

Imho mít ho ve všech složkách první úrovně kromě /www je bezpečnější. (A jak jsem psal, osobně bych ho dal i do config, kde jsou nejcitlivější data v textové podobě).

Editoval Šaman (7. 5. 2:08)

před 19 dny

Felix
Nette Core | 1004
+
+5
-

Šaman napsal(a):

Imho mít ho ve všech složkách první úrovně kromě /www je bezpečnější. (A jak jsem psal, osobně bych ho dal i do config, kde jsou nejcitlivější data v textové podobě).

V tomhle mam osobne opacny nazor. Zkusim popsat, jak to vnimam ja.

  1. Nikde neni psano, ze nette/sandbox nebo nette/web-project se ma nahravat na server nebo pouzivat v produkci. Jestli to nekdo takto dela, neni to dobre.
  2. Vnimam je jako projekty demonstrujici funkcnost Nette, ne webserveru. Pro minimalni vyvoj by mohl postacit PHP development server. Vsechno ostatni je bonus, ktery by mel ten, kdo to implementuje, vyresit.
  3. Neexistuje jenom Apache. Je rada i dalsich webserveru. To tam dame konfiguraci vsech?. Ikdyz je to mozna nejcastejsi volba u hostingu, tak porad, pred nasazenim, je nutne provest nejakou revizi.

Navrhoval bych tedy napsat sekci do dokumentace (klidne napisu), kde by byl zakladni manual jak dostat Nette na hosting a nejaky checklist co delat pred nasazenim a co delat kdyz…

před 19 dny

kamil_v
Člen | 194
+
0
-

Šaman napsal(a):

Protože když někdo neodborně upraví ten v rootu, může vzniknout bezpečnostní díra.

Bezpečnostní díra může vzniknout, když někdo neodborně upraví naprosto cokoliv.
A když někdo upraví ten v /app?
A když někdo upraví ten v /app/config?

Tohle může jít do nekonečna. Člověk bez odbornosti se vůbec v rootu nemá co „hrabat“.

Ano, ve starších verzích Nette byly tuším krom htaccessů i soubory pro IIS, zrovna tak by tam mohly být i pro Nginx…
Za implementaci odpovídá vývojář. Ani ten htaccess nemusí být na všech serverech stejný…

Nejrozumnější mi připadá jen v nápovědě nastínit best practice tipy.

před 19 dny

David Grudl
Nette Core | 7057
+
+1
-

Info o nasazování by bylo určitě užitečné, ať v docce nebo v podobě blogpostu na blog.nette.org. Kdo se toho za odměnu v podobě vděku komunity ujmete?

Podle mě existují tři možnosti:

  • nahrát web v podobě struktury sandboxu a v administraci hostingu nastavit document root do složky www (nebo udělat symlink)
  • přejmenovat složku www podle toho, jak ji má nastavenou hosting (např. web), když neumožňuje document root měnit
  • modifikovat strukturu tak, že kořenem bude www, v ní podsložka třeba x se zakázaným přístupem (buď pomocí .htaccess nebo jinak) a v ní pak známé app, log, vendor atd. Tedy varianta pro hostingy, co nabízejí jen document root. Tady je potřeba upozornit na brutální bezpečnostní riziko, kdy třeba omylem smazaný jeden soubor může odkrýt celý web, a že na takovém hostingu v žádném případě nemají hostovat.

V žádné z těchto variant nedává smysl mít soubory .htaccess v jednotlivých složkách jako je app, log, atd.

před 19 dny

Polki
Backer | 247
+
0
-

@Felix

1. Nikde neni psano, ze nette/sandbox nebo nette/web-project se ma nahravat na server nebo pouzivat v produkci. Jestli to nekdo takto dela, neni to dobre.

Ještě jsem nepotkal nikoho, kdo by to dělal jinak. Myslím, že sandbox má vše, co potřebuješ aby si mohl rozjet Nette aplikaci. Zaváděcí soubor, konfigurační soubory, oddělenou aplikační logiku od veřejné části… prostě i kdybych si ručně doinstalovával composerem balíčky tak bych asi stejně napsal ty soubory, které jsou v sandboxu, čímž bych z toho ten sandbox vytvořil. Máš tedy nějaké dodatečné info, proč je to špatně?

2. Vnimam je jako projekty demonstrujici funkcnost Nette, ne webserveru. Pro minimalni vyvoj by mohl postacit PHP development server. Vsechno ostatni je bonus, ktery by mel ten, kdo to implementuje, vyresit.

Tomu moc nerozumím. Nainstaluju Development server, spustím composer create-project … a měl bych mít hotovo ne? Pak bych se měl starat o to, co mě baví, tedy o vývoj. Proto frameworky vznikají ne? Aby se nemusely pořád dokola dělat ty samé konfigurace dokola a dokola. Jasně chápu, že si každá firma upraví sandbox podle svých potřeb a používá svůj nový sandbox. Tak by to i mělo být podle mě. Nebo špatně tento bod chápu?

3. Neexistuje jenom Apache. Je rada i dalsich webserveru. To tam dame konfiguraci vsech?. Ikdyz je to mozna nejcastejsi volba u hostingu, tak porad, pred nasazenim, je nutne provest nejakou revizi.

Myslím, že není třeba dávat všechny. To by asi ani nedávalo smysl. Spíš bych koukl na nějaké analýzy a zjistil, jak si na tom jaký hosting stojí. Tedy kolik % používá Apache, kolik NGINX atd.. No a pak bych to viděl tak, že pro ty nejvíce používané by se udělaly zvlášť sandboxy se základní konfigurací, jako například composer create-project nette/web-project-apache a composer create-project nette/web-project-nginx no a pro ty ostatní které mají mizivé zastoupení by byla jak píšeš sekce v dokumentaci (ta by mohla být klidně s vychytávkami i pro ty, které budou mít sandbox).

Pokud jde o tvorbu té dokumentace, tak kdyby jsi do toho šel a chtěl pomoct tak napiš. Určitě bych nějak rád přispěl.

před 19 dny

kamil_v
Člen | 194
+
+2
-

Polki napsal(a):

No a pak bych to viděl tak, že pro ty nejvíce používané by se udělaly zvlášť sandboxy se základní konfigurací, jako například composer create-project nette/web-project-apache a composer create-project nette/web-project-nginx

V počátku vývoje nemusím mít tušení, na čem to jednou pojede v produkci.

V průběhu projektu to ani nemusí být jeden typ http serveru, staging může jet u vývojáře třeba na Apache a produkce může být u klienta třeba na Nginx…

Chápu, čemu chceš pomoct, ale myslím si, že je to úzký pohled na věc, který vyhovuje jen někomu a jen někdy.

před 19 dny

Polki
Backer | 247
+
0
-

@kamil_v
od prvního kousku kódu v PHP, co jsem napsal, se vždy nastavoval development server tak, aby odpovídal produkčnímu serveru a to proto, aby to co se vyvíjí stačilo jen pushnout na server a vše běželo jak má. Učilo se to snad všude, kam jsem se podíval. Toto se značně zjednodušilo s nástupem dockeru.

Pokud jde o to, že někdy v budoucnu nebude hosting dostačující, nebo poskytovatel zkrachuje například, tak pak je to otázka přesunu. To by se ale nemělo myslím řešit při prvotním vývoji. Nehledě na to, že při přesunu z důvodů nedostatečného výkonu se většinou přesouvá aplikace na nějaké VPS, kde zase docker veškeré tyto problémy přenosu řeší ne?

před 15 dny

vladimir.biro
Člen | 108
+
+1
-

David Grudl napsal(a):

Info o nasazování by bylo určitě užitečné, ať v docce nebo v podobě blogpostu na blog.nette.org. Kdo se toho za odměnu v podobě vděku komunity ujmete?

Podle mě existují tři možnosti:

  • nahrát web v podobě struktury sandboxu a v administraci hostingu nastavit document root do složky www (nebo udělat symlink)
  • přejmenovat složku www podle toho, jak ji má nastavenou hosting (např. web), když neumožňuje document root měnit
  • modifikovat strukturu tak, že kořenem bude www, v ní podsložka třeba x se zakázaným přístupem (buď pomocí .htaccess nebo jinak) a v ní pak známé app, log, vendor atd. Tedy varianta pro hostingy, co nabízejí jen document root. Tady je potřeba upozornit na brutální bezpečnostní riziko, kdy třeba omylem smazaný jeden soubor může odkrýt celý web, a že na takovém hostingu v žádném případě nemají hostovat.

V žádné z těchto variant nedává smysl mít soubory .htaccess v jednotlivých složkách jako je app, log, atd.

Pak by ale bylo dobre upravit tohle v dokumentaci, protoze to vypada dulezite: https://nette.org/…rity-warning#…

V moji puvodni otazce sem prave zadal o nejake vysvetleni, jak by to melo byt spravne (nechtel jsem nic kritizovat, nebo tvrdit, ze nekdo dela neco spatne), abych to spravne pouzival.

před 14 dny

Milo
Nette Core | 1153
+
+3
-

Nebylo to tu explicitně řešeno tak jen doplním, že nastavení z .htaccess se automaticky dědí na podsložky a proto není technicky nutné ho do podložek kopírovat.