Route::SECURED nevynucuje HTTPS 100%

před 3 lety

_Martin_
Generous Backer | 680
+
0
-

Ahoj,

všiml jsem si, že v některých přístupech Nette povolí přístup přes HTTP protokol, ačkoliv má routa nastaven příznak Route::SECURED. V dokumentaci o tom zmínka není, takže nevím, zda jde o cílené chování nebo o chybu. K druhé variantě se kloním víc.

K situaci dojde, pokud z presenteru odešlu jinou odpověď než standardně přes šablonu. Tj. například při použití TextResponse nebo při klasickém echování a příkazu $this->terminate(). Nezkoumal jsem chování pro FileResponse a další, ale hádám, že se to bude chovat obdobně.

před 3 lety

Jan Tvrdík
Nette guru | 2550
+
-1
-

Ano, to je feature. Tohle má vynucovat server.

před 3 lety

_Martin_
Generous Backer | 680
+
+4
-

Co přesně je feature? Že funkce, která má vynucovat HTTPS nevynucuje HTTPS? Viz dokumentace:

U routy lze vynutit používání zabezpečeného protokolu HTTPS uvedením příznaku SECURED.

Nevím, zda mluvíš za tým kolem Nette. Jestli v okruhu Nette vývojářů padlo rozhodnutí, že takovou věc má dělat server a ne framework, tak by ale tahle funkcionalita a tenhle kus dokumentace měly zmizet, jinak uvádějí všechny uživatele frameworku do mylné představy, že jejich aplikace je chráněná pomocí HTTPS.

A pokud takové rozhodnutí nepadlo, pak by ta funkce měla fungovat 100% a k tomuto zjištění by se mělo přistoupit jako k bugreportu. A pokud by bylo nesmírně složité fungování opravit, tak alespoň upozornit v dokumentaci, že pro určité typy odpovědí HTTPS nevynucuje.

před 3 lety

Jan Tvrdík
Nette guru | 2550
+
-2
-

Co přesně je feature?

Současná chování. Spojení „to je feature“ znamená, že to chování nevniklo omylem a nejedná se o chybu. Naopak jde o zcela záměrné chování.

Jestli v okruhu Nette vývojářů padlo rozhodnutí, že takovou věc má dělat server a ne framework

To rozhodnutí padlo před více než 7 lety, kdy to David implementoval.

Viz dokumentace

Dokumentaci můžeš opravit.

před 3 lety

David Grudl
Nette Core | 6828
+
+9
-

Flag SECURED jen říká, jaké URL má router generovat, se zabráněním přístupu přes HTTP to nesouvisí. Máš pravdu, že dokumentace to neříká jasně, a bude super, pokud pošleš opravu na https://github.com/nette/docs

před 3 lety

_Martin_
Generous Backer | 680
+
0
-

Davide, a nebylo by lepší, aby to ta funkce uměla? Zatím jsem blíže nezkoumal zdrojáky, ale přišlo by mi to fajn, když už to ta funkce částečně umí. V každém případě doporučuji upozornit ostatní vývojáře, protože nejspíš nebudu jediný, kdo kvůli té zmínce v dokumentaci věří, že se k žádným datům v jeho aplikaci nedá bez HTTPS dostat. To zavání zásadní bezpečnostní chybou.

Honzo, trochu mě mrzí tvůj arogantní přístup. Pamatuji si fórum mnohem vstřícnější.

Editoval _Martin_ (20. 5. 2016 11:25)

před 3 lety

Jan Tvrdík
Nette guru | 2550
+
+2
-

a nebylo by lepší, aby to ta funkce uměla?

Nemyslím si, výchozí protokol na internetu je HTTP. Je prakticky nezbytné, aby web běžící na HTTPS dokázal přesměrovat požadavky, které přijdou přes protokol HTTP, protože normální uživatelé nikdy https:// do adresního řádku psát nebudou. Správné řešení je přesměrovat na úrovni serveru. Pokud je server chybně nastavený, tak Nette jako nouzové řešení to přesměrování taky vynutí.

Diskutovat můžeme leda tak o tom, že by přes HTTP akceptoval pouze metodu GET, ale jsem dost přesvědčený, že ani takovou změnu nepůjde udělat kvůli BC, neboť někdo určité spoléhá na funkčnost nějakých starých formulářů, co se odesílají ještě přes HTTP.

kvůli té zmínce v dokumentaci věří, že se k žádným datům v jeho aplikaci nedá bez HTTPS dostat.

Pokud máš špatně nastavený server, tak minimálně ke všem statickým datům se půjde dostat, ať už Nette udělá cokoliv.

Honzo, trochu mě mrzí tvůj arogantní přístup.

Arogance je jeden z konceptů společnosti, který nechápu, omlouvám se.

před 3 lety

Milo
Nette Core | 1127
+
0
-

@_Martin_ Odkud tu response posíláš? Z action nebo z render? Tipuji, že z action. IMHO bys měl v render, tam se mají vykreslovat data na výstup.

EDIT: Ptám se proto, protože SECURED je aplikováno při kanonizaci URL a kanonizace se provádí po action, ale před render.

Data by se tak měly vypisovat (šablona, response) až v render, jinak je kanonizace k ničemu. Z mého pohledu je to správně. Například pro HEAD metodu se volá jen action, kde si mohu nastavit HTTP hlavičky, ale render už ne, protože HEAD nemá tělo.

PS: Do dalších verzí Nette bych se SECURED stejně radši moc nepočítal :)

před 3 lety

David Grudl
Nette Core | 6828
+
+6
-

_Martin_ napsal(a):

Davide, a nebylo by lepší, aby to ta funkce uměla?

Router samotný není místem, kde by se měl blokovat přístup. Ten může pouze URL neakceptovat, což by ale způsobilo dost kolosální BC break. Přístup může odmítnout Presenter, ale aby mohl respektovat flag na routě, musel by vědět, jak byl naroutován a to taky není košer. Presenter nicméně dělá kanonalizaci URL, v důsledku čehož k přesměrování dojde, ale na tohle není úplně záhodno spoléhat (viz tvůj issue, navíc k ní nedochází při POST nebo AJAX požadavku). Navíc je to docela drahé přesměrování, sestaví se celá aplikace, než se zjistí, že se má přesměrovat.

Tím pravým místem je skutečně nastavení serveru. Protože

  • chceš přesměrovávat veškerý traffic, nikoliv jen ten, co jde na presentery
  • chceš veškerý traffic mít na HTTPS (předpokládám)

V každém případě doporučuji upozornit ostatní vývojáře, protože nejspíš nebudu jediný, kdo kvůli té zmínce v dokumentaci věří, že se k žádným datům v jeho aplikaci nedá bez HTTPS dostat.

Budu fakt rád, když to do dokumentace přidáš.

Honzo, trochu mě mrzí tvůj arogantní přístup. Pamatuji si fórum mnohem vstřícnější.

Jo, tohle mě taky štve.