Nette by měl generovat warning, když bude config přístupný z URL

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Filip Procházka
Moderator | 4668
+
0
-

Během compilace containeru by Nette mohlo (pokud bude mít k dispozici file_get_contents, nebo curl) zkusit udělat http request na předpokládanou url configu, tedy pokud bude v document rootu přístupná nějaká cesta ze specifikovaných configů v configuratoru.

Když tedy přidám config(y)

$configurator->addConfig(__DIR__ . '/config/config.neon');
$configurator->addConfig(__DIR__ . '/config/local.neon');
$configurator->addConfig(__DIR__ . '/../../config/local.neon'); // někde kompletně mimo document_root

tak by měl zkusit, jestli se k nim dostane přes url a generovat warning. (nápad by Roman Sklenář)

Co myslíš, komunito?

Editoval HosipLan (29. 3. 2012 19:57)

Aurielle
Člen | 1281
+
0
-

+1

Tomáš Votruba
Moderator | 1110
+
0
-

+1 (myslel jsem, že je to tak logické)

hrach
Člen | 1819
+
0
-

Blbost. Url to vygeneruje blbě a budeš mít falešný pocit. –10.

Filip Procházka
Moderator | 4668
+
0
-

Udej příklad prostředí, kde to vygeneruje špatně URL. To, co ještě není implementované. Takže samozřejmě už dopředu víme, kde to nebude fungovat, žejo ;)

Nemusí se to nijak drasticky hlásit, ale pokud to zachrání aspoň jeden web, tak to smysl má. Nebyl jsi to ty, kdo před pár dny psal na github pod signály, že aspoň nějaké zabezpečení, než žádné?

Editoval HosipLan (29. 3. 2012 21:54)

Patrik Votoček
Člen | 2221
+
0
-

Jsem pro. Ale nemělo by se to nějak moc propagovat aby to nevyvolávalo falešný pocit bezpečí pokud by to náhodou generovalo špatnou cestu (něco jako error když nezavolám parent::starup() v presenteru).

Majkl578
Moderator | 1364
+
0
-

-1, z důvodu, který uvedl hrach. Vymyslet si URL a tu pak testovat, to dává falešný pocit bezpečí (např. si ji vymyslí blbě nebo kontrolu vůbec nebude moci provést) a zároveň to může potenciálně způsobovat problémy (je to HTTP request jako každý jiný, který je položen na neznámou URL).

Dva jednoduché scénáře k zamyšlení:
a)

/app/config/config.neon
/www/index.php

Co když aplikace poběží ve špatném prostředí (= standardní hosting) kde složka = subdoména? Pak (hypoteticky) může být URL http://app.example.com/config/config.neon, ale jak by to Nette zjistilo?

b)

/app/config/config.neon
/index.php

Tohle řešení použil už kdekdo, právě kvůli hostingům, aby neměl app jako subdoménu. Nicméně, každá aplikace nějak nakládá s neexisující URL. Tady by URL byla: http://example.com/app/config/config.neon. A co teď? Na té URL bude vždy něco existovat (každá Nette aplikace reaguje na neplatný request) a vrátí buď 404 nebo klidně i dokonce 200 (resp. na status kód se nelze spolehnout). Zároveň se ale, za předpokladu, že se na té URL opravdu jedná o config.neon, nelze spolehnout ani na obsah souboru (co když bude např. prázdný?). Z toho tak trochu vyplývá, že i když ta URL existuje, nedá se vlastně snadno určit, jestli to config.neon je nebo ne.

Filip Procházka
Moderator | 4668
+
0
-
  1. Víceméně tvrdíš, že Nette neumí generovat basePath. Porovnáním documentRoot, wwwDir a appDir (nebo libovolne slozky ve ktere je config) můžeš skovo vždycky zjistit správnou url. A skoro píšu jenom proto, že mě nenapadá, kdy by to nešlo.
  2. Obsah souboru vždy znáš, protože znáš absolutní cestu, tedy můžeš vždy porovnat, jestli se to rovná.

Jak říká vrták, když se to nebude nijak extra roztrubovat, ale prostě to tam jen bude, tak to pár lidem určitě zachrání krk.

Asi si půjdu hrát a napíšu pár testů…

Editoval HosipLan (29. 3. 2012 22:58)

paranoiq
Člen | 390
+
0
-

raději bych přidal přesměrování přípony .neon (a .ini) do nastavení url rewriteru v příkladech a skeletonu

hrach
Člen | 1819
+
0
-

paranoiq: +1
hosiplan: motáš dohromady zase plno věcí, zabezpeceni signalu „funguje“ vzdy. Nejaky jeden wget pri generovani system containeru sice krasne muze fungovat ted, ale za par minut uz muze byt config dostupny. (Spatne nastaveny deploy, rsync atp.) O vrtkavosti detekce cesty taky nemluve.

llook
Člen | 407
+
0
-

$i--;
Každý request sám o sobě představuje určitou zátěž. Pokud bys to chtěl udělat neprůstřelné, znamenalo by to každý request prodloužit o ten tvůj bezpečnostní subrequest.

Ascaria
Člen | 187
+
0
-

paranoiq napsal(a):

raději bych přidal přesměrování přípony .neon (a .ini) do nastavení url rewriteru v příkladech a skeletonu

+1
a mohlo by to rovnou přesměrovat na error presenter

Filip Procházka
Moderator | 4668
+
0
-

@**paranoiq**: v app je ve skeletonu .htaccess, který zabraňuje aby složka byla přístupná. Tohle by tedy bezpečnosti nepřidalo.

Tyhle průsery vznikají tak, že programátor nenahraje .htaccess na server, nebo server neběží na apachi/iis.

Problém by se dal řešit ještě tak, že pokud bude app složka v document rootu, nette bude kontrolovat jestli je htaccess ve správné složce (v app) a jestli současné prostředí ho neignoruje. Nginx na něj totiž rozhodně kašle.

hrach
Člen | 1819
+
0
-

Jde o to, ze rewrite (tedy htaccess) zapomenout dneska nemuzes, nejel by ti web. Pokud tedy rewritnes vsecko *.neon na index.php, problem neexistuje :)

Tomáš Jablonický
Člen | 115
+
0
-

Tohle by Nette asi řešit neměl. Je to zbytečná režie navíc.

tomhrb
Člen | 23
+
0
-

trosku se vratim k tomuto vlaknu, ponevadz to nyni resim. jako blbuvzdorne reseni se mi jevi, kdyby neon.config povolil syntaxi s <?php na zacatku souboru. to by pak pristup k takovemu souboru (jmenoval-li by se neon.config.php) vypsalo prazdno. pokud neco takoveho jiz nette umi, vi nekdo prosim, jak prenastavit configurator aby ignoroval tyto uvodni znaky (tedy <?php)?
dekuji

llook
Člen | 407
+
0
-

tomhrb napsal(a):

trosku se vratim k tomuto vlaknu, ponevadz to nyni resim. jako blbuvzdorne reseni se mi jevi, kdyby neon.config povolil syntaxi s <?php na zacatku souboru. to by pak pristup k takovemu souboru (jmenoval-li by se neon.config.php) vypsalo prazdno. pokud neco takoveho jiz nette umi, vi nekdo prosim, jak prenastavit configurator aby ignoroval tyto uvodni znaky (tedy <?php)?
dekuji

Můžeš použít Neon komentář:

# <?php die(); ?>
common:
	parameters:
		atd: ...

Jenže config loader u přípony PHP očekává PHP, konfiguráky se totiž dají psát i v čistém PHP. Tohle se nedá změnit úplně snadno. Nejjednodušeji asi poděděním Configuratoru, předefinováním createLoader() a přepsáním private property $adapters. Je to trochu špína, ale mělo by to fungovat:

	/**
	 * @return Loader
	 */
	protected function createLoader()
	{
		$loader = new Loader;
		$loader->reflection->properties['adapters']->setAccessible(TRUE);
		$loader->reflection->properties['adapters']->setValue($loader, array('php' => 'Nette\Config\Adapters\NeonAdapter'));
		return $loader;
	}