Formulář přes SSL

LastHunter napsal(a):

Pro https se používá parametr Route::SECURED pro danou routu, takže bych dané stránce asi vytvořil speciální routu s tímto parametrem.

To, cos napsal, je fakt špatný :o))

To nepůjde, protože by musel předělat celý web na https – formulář má na každé stránce, je definovaný v BasePresenteru. Taky jsem chtěl napsat něco o IRouter::SECURED, ale pak jsem si to přečetl pořádně…

Ja som vyššie spomínaný postup s dvoma routami použil úspešne (a bezpečne). Dôležité je vedieť, že formulár sa musí zobraziť na už zabezpečenej stránke – preto musí byť každá stránka, na ktorej ho chceme zobrazovať, zabezpečená. U mňa má prihlasovací formulár na starosti prezenter Security:Auth, teda je to v poriadku.

$router[] = new SecureRouter(array(
	'presenter' => 'Security:Auth',
	'action' => 'default',
));
$router[] = new SimpleRouter(array(
	'presenter' => 'Common:Home',
	'action' => 'default',
));

class SecureRouter extends SimpleRouter
{
    public function __construct($defaults = array(), $flags = 0)
    {
        parent::__construct($defaults, $flags | self::SECURED);
    }

    public function match(IHttpRequest $httpRequest)
    {
	// by default, SimpleRouter is greeeeedy...
        if (!$httpRequest->isSecured()) {
            return NULL;
        }

        return parent::match($httpRequest);
    }

    public function constructUrl(PresenterRequest $appRequest, IHttpRequest $httpRequest)
    {
	// by default, SimpleRouter is greeeeedy...
        if ($appRequest->getPresenterName() !== $this->defaults[self::PRESENTER_KEY]) {
            return NULL;
        }

        return parent::constructUrl($appRequest, $httpRequest);
    }
}

Pripomienky a zdrby vítané :)

kravčo napsal(a):

Dôležité je vedieť, že formulár sa musí zobraziť na už zabezpečenej stránke – preto musí byť každá stránka, na ktorej ho chceme zobrazovať, zabezpečená

Deja vu.

Zabezpečený action nestačí!

oktam napsal(a):

Preco nie?

To by mě také zajímalo. Takto to má řešené například i centrum.cz, seznam.cz, apod.

Jinak bych musel mít https:// celý web, protože, jak jsem říkal, je to formulář na každé stránce (něco jako třeba na czc.cz)

Ale hlavně nevím, proč pro takto zdánlivě jednoduchou věc musím zasahovat do implementace Nette Presenteru. Buď za Boha nemůžu přijít jak na to Nette-way a nebo to skutečně Nette netankuje :)

Editoval DocX (24. 8. 2009 23:33)

David Grudl napsal(a):

Formulář se nemusí zobrazovat na https, stačí ho na https odesílat.

Tak to je fajn :) Řešilo by to dost věcí. Vlastně by stačilo jenom nějak přesvědčit router, aby i když to nemá v definici routy vyrobil URL s https://.

Co jsem na to teď rychle koukal, tak by možná stačilo, aby se Router řídil při rozhodování zda http:// nebo https:// i podle příznaků nastavených v PresenterRequestu. Pak už by stačilo jen přidat nějaký parametr (flags nebo jen konkretně na SSL) metodám Presenter::createRequest() a PresenterComponent::link() (který by to předal createRequestu) a ještě upravit třídu Link, aby také uměla zacházet s těmito příznaky.

Výsledek by mohl být ten, že kdykoliv by se tvořil link, mohlo by se říci, že chci SSL (nebo naopak nechci), a on by se tak vytvořil. Ve Formu by to mohlo být nějak zapouzředné (třeba metodou setSSL).

Akorát to tak trochu narušuje filozofii routů, že by pak aplikace věděla tak trochu o výsledné url.

Nette to netankuje. Budu tohle vlákno brát jako feature request.

Díky, jsem zvědav co nakonec vymyslíš :)

Editoval DocX (26. 8. 2009 13:01)

kravčo napsal(a):

… Dôležitý rozdiel je v tom, že podvrhnutý odkaz na stránku s formulárom sa objaví v adresnom riadku a teda je možné naň prísť vcelku jednoducho. …

Kdyby už byl útočník uprostřed mojí komunikace, mohl by podvrhnout ten odkaz na stránku s formulářem tak, že by jen odstranil „s“ v https://.. Po té by podvrhl stránku s formulářem a dělo by se to, co jsi popsal. Uživatel by neměl šanci nic poznat.

Ale jinak jde o kokrétní situaci. Pokud půjde o e-banking tak budu mít celou aplikaci přes SSL. Pokud mi jde jen o relativně vyšší pocit bezpečí uživatelů, stačí mi zabezpečená akce.

Kdybych to vzal úplně do hloubky, tak mi ani celý web v HTTPS nemusí zaručit bezpečí, protože když uživatel zadá http://ebanking.cz, může mi útočník nabídnout místo přesměrování na https normálně stránku přímo na http. Může pak fungovat jako nějaká proxy, kde z pohledu banky to jede normálně přes SSL, mezi útočníkem a uživatelem to je nešifrovaný (proč řešit podvržený certifikát ;) ). Samozřejmě jde o uživatele jestli si všimne toho, že mu to neběží zabezpečeně.

Ale i kdyby si toho všiml, mohl mi můj dlohouletý „kamrád na drátě“ podvrhnout odkaz na stažení firefoxu a přibalit si do něj vlastní důvěryhodný certifikát. Případně, že mám ff z distribuce, mohl mi podvrhnout instalační CD distribuce. (Hm z toho mi vyplívá, že nejbezpečnější je asi koupenej Windows s IE)

Atd… ;)

Editoval DocX (26. 8. 2009 17:21)

A ak používateľ bezpečnosť nijako nerieši, nepomôžeš mu…

S tím jsem ve svých úvahách počítal :) Navíc uživatel nemusí vědět že se měl ocitnout na HTTPS ;) Jinak s tebou samozřejmě souhlasím. Původně jsem myslel, že máš na mysli, že se změní na úplně jinou adresu :)

No ale ať uzavřem tento OT :) „Nejslabší článek je vždy uživatel…“

Editoval DocX (26. 8. 2009 18:51)

Já si zavedl do vlastní odvozeniny Route pole $secured, které určuje, co se má posílat přes SSL. V bootstrapu pak mám toto:

<?php
DbRoute::$secured = array(
	'PlaceOrder',  // cely presenter
	'JobDirectory:postJob', // jenom action postJob
);
?>

Editoval Gringo (26. 8. 2009 23:39)

Gringo napsal(a):

<?php
DbRoute::$secured = array(
	'PlaceOrder',  // cely presenter
	'JobDirectory:postJob', // jenom action postJob
);
?>

Tyjo, tohle mi přijde vážně geniální :) Navíc by to mohlo řešit to, že si každý presenter může sám určit jestli chce být zabezpečený jednoduše přidáním se do routeru ve startupu :)

Takže co myslíte?

Měl by Presenter rozhodovat o tom zda a jaké akce budou zabezpečené (potom by na tu šel určitě udělat nějaký obecný mechanismus), tak, že by to oznámil routeru, který by poté případně požadavek kanonizoval

nebo

by mělo toto rozhodovací právo zůstat na Routeru a jeho nastavení v bootstrapu?

Editoval DocX (27. 8. 2009 0:21)

Podle Marka Prokopa je https vs. http také duplicitní obsah, nepřímo to zmiňuje i Petr Fidler. Viz také SEO konference.

Ad. duplictiní obsah: a není možné předpokládat, že chci-li mít nějakou stránkou dostupnou pod šifrovaným spojením, chci také, aby byla dostupná pouze pod šifrovaným spojením?

Taky si myslím, že by měla být stránka pouze zabezpečená nebo pouze nezabazpečená. Případně by byl redirect.

Marek Malevič napsal(a):

Protoze jedina informace, kterou chci sifrovat, je poslani hesla, pak bych opravdu uvital moznost odeslat heslo pres https, ale zbytek aplikace by dal pokracovala zase klasicky pres http.

Jde to, já to vyřešil následovně:

<?php

// BasePresenter:

function createComponentLoginForm()
{
	$form = new AppForm();
	...

	// odkaz na action "dologin" v "LoginPresenter"
	$form->action = $presenter->link('Login:dologin');
}


// v bootstrapu pridat zabezpecenou routu, aby se link vyse vytovril s https://

$router[] = new Nette\Application\Route('login/dologin', array(
	'presenter' => 'Login',
	'action' => 'dologin',
), Nette\Application\Route::SECURED);

?>

Neni mi znam jediny duvod, proc by melo byt na zavadu takove reseni. V podstate neni zabezpecena nebo nezabezpecena stranka. Je pouze zabezpecena a nezabezpecena komunikace. A tu zabezpecenou vyzaduji pouze u hesla.

Duvod tam je.

Pokud by se nekdo dostal k moznosti jen slyset komunikaci (napr. bydli v baraku na jehoz srese je AP s nesifrovanym „signalem“ na nejz se pripojuje okolnich 10 baraku), tak to staci.

Predstav si ale ze se dostane nejakym zpusobem mezi (man in the middle), tzn ze komunikaci nejen ze slysi, ale muze ji i menit. Pak to nestaci, protoze v okamziku, kdy tvuj server posila nesifrovanou (a nepodepsanou) stranku s formularem, on v ni zmeni prislusnou hodnotu v action na http:// (bez „s“), klidne i stejne adresy. Jakmile pak uzivatel formular odesle (pres ne-ssl), data pujdou znovu skrz nej. K tvemu serveru se prihlasi jakoby on pres SSL a odezvu prelozi zpet uzivateli, aby nic nepoznal. Kdyby jsi ale mel cely web zabezpeceny s certifikatem podepsanym znamou autiritou, tohle by neslo. Teda slo, kdyby utocnik zamezil pristupu uzivatele na SSL, treba by zmenil odkaz ve vysledku google. Je ale fakt, ze dostat se nekomu doprostred komunikace je celkem obtizne.

Doufam ze u nas jeste neni trestne zverejnovani takovychto informaci :o))