Bezpecnost n:href odkazu pri zpracovani signalu

Ahoj,

přece nemůžeš mít v aplikace volně linky na mazaní databáze, a button to nezachrání… :)

Takže se musí použít nějaké přihlašování uživatelů https://doc.nette.org/…thentication

A pak si musíš ten link zabezpečit tak aby se robotovy vůbec nezobrazil. A zároveň by jsi měl kontrolovat oprávnění i v handle metodě, když by ti někdo podvrhnul url.

Tady je nějaký screencast, kde se na to můžeš podívat https://doc.nette.org/cs/quickstart

Neshrnuj;)

Přece ti to Ani napsal – musíš kontrolovat oprávnění i v akci, robot práva mít nebude, takže nic nesmaže

Jakto, ze nebude mit prava, kdyz se bude tvarit jako legitimne prihlaseny uzivatel?
Vezme se cely pozadavek (ne URI) na server (od aktualne prihlaseneho uzivatele), zkopiruje se, da se do curl a zacne se stahovat (zjednodusene). Tedy se tvari jako prihlaseny uzivatel (jako by se na to koukal prohlizec), ale prochazi vsechny linky na strance a stahuje je. Tedy problem stale existuje. Nebo nevim jak co znamena „kontrolovat opravneni v akci“.

Ono to nikoho netrapi, protoze to neni az tak velky problem jak si myslis. Ve verejne casti typicky nemas odkaz na smazani clanku a tu neverejnou nikdo nestahuje a kdyz jo, tak si ma dat bacha sam (kdyz tam das rel=„nofollow“, tak budes z obliga :))

Pokud by te to opravdu trapilo, tak muzes pozadavky posilat ajaxove, pouzit formular nebo nejakou formu captchy.

Jeste k otazce jak volat signal pres formular: signal se vola GET parametrem do=„<nazev-signalu>“, takze staci pouzit <input type="hidden" name="do" value="<nazev-signalu>" />

Editoval Elijen (3. 2. 2012 2:39)

Tak u rel="follow" je samozřejmě jen na konkrétní implementaci bota – dokonce se myslim spekulovalo, jestli to google sám vůbec dodržuje.

Plete se tu problematika botů a celková bezpečnost. Pokud nechceš, aby ti boti chodili na určité adresy (signál je prostě adresa!), tak tam dáš podmínku, že to ignoruje boty, podle nějakých hlaviček – a víc ověřovat není třeba, pokud je to nějaký co neposílá hlavičky že je bot, pak jde o nějaké promile a to se třeba v hlasování neprojeví – a pokud je to něco jiného, zde stále mluvím o bot VS člověk. Neodchycení jednoho bota prostě znamená, že danou url nezkusil člověk ale stroj, což by mě zajímal případ, kdy to kriticky vadí i v zanedbatelném množství.

Dále je zde obecná otázka bezpečnosti.

Použij https://github.com/…tte/pull/469 + ověření práv + se koukni na obecné zabezpečení session

Každopádně argument, že si někdo stáhne stránku botem co kliká na odkazy a použije na to vlastní session, tak je to jeho blbost, že si to tak nakódoval. Je to stejné, jako by na ty tlačítka klikl sám a pomazal si to. Jako by se nepoužilo Nette, ale normální aplikace s odkazy. Atd.

Proti robotům se dá použít JavaScriptová ochrana. JavaScript přidá do URL &confirmed=1 a na straně presenteru se přidá proměnná $confirmed a kontroluje se, zda je nastavená.

A podporuje to primo nette, nebo se o to musim starat sam? Jinak velmi dobre reseni :) Sice prijdu o lidi s vypnutym js, ale ty cert vem.

David Grudl napsal(a):

Proti robotům se dá použít JavaScriptová ochrana. JavaScript přidá do URL &confirmed=1 a na straně presenteru se přidá proměnná $confirmed a kontroluje se, zda je nastavená.

babcca napsal(a):

Vznika otazka, je najaky specialni duvod proc jsou signaly odkazy?

A hned na ní vzniká protiotázka: a co jiného by to mělo být?

To, co pořád řešíš, je spíše filosofická otázka než technická. Automaticky bereš signál jako něco, co vykonává nějakou akci. Ale tak to vůbec není! Signál je univerzální signál komponentě od uživatele. A tím signálem může být „teď mi zobraz detaily“, nebo „změň filtrování v tabulce“. Pokud potřebuješ, aby byla akce signálu ve formuláři, udělej jí formulářem. A to už není problém signálu jako takového, ale jeho realizace, která je na Tobě.

A pokud Ti formulář přijde pracný na psaní, napiš si na to makro. :-)

//EDIT: nebo tu komponentu, podle toho, co přesně potřebuješ.

Editoval Panda (3. 2. 2012 12:39)

@Panda Koncept signalu chapu. Jen mi dela problem, jak jsou prezentovany. Vsechny tipy signalu se hazi do jednoho pytle a ma se na ne odkazovat pres n:href (viz. tutorial [kde delete je odkaz]), tedy jak na ty
>„teď mi zobraz detaily“, nebo „změň filtrování v tabulce“
coz jsou pohledove akce, tak i na
„ted mi vymaz zaznam“ nebo „ted mi proved hlasovani“
coz jsou jenom akce.
Ale oni totozne nejsou. Chapu, ze signaly jsou prostredek. Nechapu styl jejich volani, tak jak se prezentuje (lidi mylne z navodu ziskaji pocit, ze mazat data z db pred odkazy je v poradku). Jinak dekuji za reakci k tematu :).

@HosipLan: Dekuji.
@David Grudl: Dekuji.

Upřímě řečeno, má to několik aspektů.

• už jsem „slyšel“ jednu story, jak se to opravdu s tím robotem stalo. muze byt kec, ale…
• neni nic otravnejsiho, nez mit mezistranku s otazkou, jestli to opravdu chci udelat (dokonce to tak je v nette examples)
• destruktivni akce by mely byt reseny pomoci POST pozadavku
• Nette zatim stale nema CSRF ochranu na signaly, takze v tuto chvili, pokud nekdo ma mazani bez csrf ochrany na signalech, je normalni hazarder
• zaver: pokud si nemergnech https://github.com/…tte/pull/469, tak ani neuvazuji o danem chovani, dale odkazy tvor

  <a href="{delete! $id}" data-confirm="Opravdu chceš?">smazat</a>

  a pak v javascriptu neco, jak rikal David.

$('a[data-confirm]).live('click', function() {
	var q = $(this).attr('data-confirm');
	if (!confirm(q)) {
		event.preventDefault();
		return false;
	}

	// tady pridat danej &confirm=1, coz moc nevim, jak efektivne zjistit,
	// jestli link uz ma nejaky nejaky query argumenty (jinak by bylo ?confirm=1)
	$(this).attr('href', $(this).attr('href') + '&confirm=1');
});

Elijen napsal(a):

Ono to nikoho netrapi, protoze to neni az tak velky problem jak si myslis. Ve verejne casti typicky nemas odkaz na smazani clanku a tu neverejnou nikdo nestahuje a kdyz jo, tak si ma dat bacha sam (kdyz tam das rel=„nofollow“, tak budes z obliga :))

To je sice bohužel pravda, že to skoro nikoho netrápí, ale pokud nějaká aplikace umožňuje měnit data pomocí GET požadavků, třebaže po přihlášení, tak je velmi zranitelná. Jestli je někde v dokumentaci mazací tlačítko dělané přes <a n:href="...">delete</a>, tak je to chyba. Tohle bychom nováčky učit neměli.

Mazací tlačítko jedině přes formulář s CSRF ochranou: https://doc.nette.org/cs/forms#…

Já vím co myslel, chtěl jsem tim říct toto:

Tento signál:

<?php
handleAction ($id, $confirm = null){}
?>

Presneter:
{link action! 1}
vygeneruje:
?do=action&id=1
přes JS přidáme confirm=1:
?do=action&id=1&confirm=1

handle obdrží $id=1 a $confirm=1

Ale když to celé bude v komponentě, třeba foo:
{link action! 1}
vygeneruje:
?do=foo-action&foo-id=1
přes JS přidáme confirm=1:
?do=foo-action&foo-id=1&confirm=1

handle obdrží $id=1 a $confirm=null, protože není v getu foo-confirm

Editoval Ani (3. 2. 2012 19:22)

@Ani Vyborne, dekuji :)
Jinak takovy odstrasujici priklad je zde https://doc.nette.org/cs/quickstart u signalu markDone, pokud by tim robot probehl, tak nemame sanci obnovit db do konzistetniho stavu zpet.

llook napsal(a):

Mazací tlačítko jedině přes formulář s CSRF ochranou: https://doc.nette.org/cs/forms#…

No CSRF ochrana se da udelat i pro odkaz … nekde jsem na to dokonce mel komponentu.

Destruktivní akce by měly být řešeny pomocí DELETE požadavku, když už jsme u toho.

Ma to nejaky hlubsi smysl z hlediska bezpecnosti nebo pouzitelnosti? Jelikoz HTML formulare podporuji pouze GET/POST, tak by se DELETE pozadavek musel delat pres AJAX.

Editoval Elijen (4. 2. 2012 12:31)

Nedelejme z toho zase vzpouru stroju… Pokud vim, rec je o automatickych preloaderech stranek. Kdyz bude chtit nekdo udelat bota, co bude pouzivat JS, tak to pro nej nebude problem (staci pouzit napriklad htmlunit), pripadne script do browseru a primamanipulace s DOM. Coz mimochodem obejde i to pridavani &confirm do adresy. Takze bud formular, nebo nemit odkaz primo, ale menit adresu az onclick po potvrzeni uzivatelem,pripadne rovnou AJAX. Ale to zase snizuje pouzitelnost na zarizenich bez JS, pripadne s emulovanym JS (opera mini), kde se takove udalosti obcas chovaji dost divoce.