nebezpečnost parametrů GET

Ten příklad na zdrojáku zrovna zabezpečený není, taková věc by měla být v databázi či v té session. Je přeci uživatelova věc, kolik do automatu hodí peněz :) Pouhý pohled do zdrojáku Presenteru, kde persistentní proměnná musí být public, dává tušit, že si na ni kdokoli může sáhnout a změnit ji.

Jinak GET parametry zrovna nějaké zabezpečení nepotřebují, tady snad hrozí jedině SQL injection, která, pokud správně používáš dibi, nehrozí…

Nette tě od většiny bezpečnostních problémů chytře odstíní. XSS (automatické escapování v šablonách), žádná bezpečnostní rizika okolo přihlašování uživatelů, kontrola odeslaných polí formulářů (co si sám nenadefinuješ, to aplikace nepřijme), již zmíněná SQL injection díky dibi, volitelná ochrana u formulářů proti CSRF, dobrá kontrola MIME typu uploadovaných souborů…

Editoval LastHunter (24. 10. 2009 22:30)

Zkus si pročíst tento příspěvek: https://forum.nette.org/…zeni-smazani?…

Já rozumím tomu co říkáte. Nejde mi o uchovávání proměnných v url, nýbrž o posílání signálů s parametry. Nemohu teď přijít na nějaký konkrétní příklad, který by se bez POSTu neobešel (to jen čistě teoreticky). V takových případech, jako je logování uživatele, bez problémů použiji formulář, který data posílá metodou POST. Jen mi šlo o to, jestli toto neumí Nette lépe zabezpečit.
Přízpěvek, jenž přidal Jan Tvrdík nejspíše vystihuje, co mám na mysli. Bohužel nejsem na takové programátorské úrovni, abych použitý kód uměl realizovat/rozchodit.

Ale i tak děkuji. Snad nikdy nejdu situaci, která se bez zabezpečených parametrů v oblasti url neobejde :D

tomaass napsal(a):

Aha. Těď jsem přečet celé téma, které jste mi zaslal. To je přesně to, o čem mluvím. CSRF útok . Ano, přesně o tom to je. JEstli-ze mam textove odkazy v tabulce, a ty odkazy maji mazat zaznam tabulky, pak to bude neco jako {plink AkceSmazat, $id} No, a uživatele nenapadne nic jiného (když vidí url adresu), že do url začne psát čísla, co se mu zamanou. To je ten problém.
Tady to někdo řešil: zde ale nějak to asi nedořešil. Nechám se překvapit další verzí Nette :)

Ten odkaz od Honzy Tvrdíka vede na jednu z možností řešení. Možná to není z příspěvku zřejmé,
ale po nakopírování metod do presenteru (ideálně BasePresenteru) stačí metody pro zpracování signálů
označit phpdoc komentářem @secured. Všechny linky odkazující na tyto handlery budou mít automaticky zakódovanou uživatelem neměnitelnou URL.

Editoval jasir (25. 10. 2009 0:26)

tomaass napsal(a):

Tady to někdo řešil: zde ale nějak to asi nedořešil. Nechám se překvapit další verzí Nette :)

To jsem byl já, ale když se podíváš dál, tak to tam dobře a asi elegantněji pořešil jasir. Ale nezkoušel jsem. U něj stačí overridovat pár metod, já jsem hrabal přímo do kódu presenteru, čili jeho způsob bude asi lepší. Proto jsem se to nechal být..

Trošku odbočím, ale když už to bylo nakousnuto: co udělat něco jako

class MyPresenter {

	/** @persistent(session) */
	public $param;

	...

Ono to dokonce kdysi v nějaké historické verzi Nette bylo a fakt už si nepamatuju, proč to zmizelo. Ale když už persistence, tak volba mezi URL a session by mohla být.

+1 taky ale potřebuji verzi bez anotací :)

Jan Tvrdík napsal(a):

Když už do toho budeš „hrabat“, nechceš rozšířit syntaxi na @persistent(url) int, které by automaticky přetypovalo na integer?

Není to tak, že když se uvede u té proměnné výchozí hodnota, tak podle té to přetypuje? Jakože:

public $param = 0; // hodnota bude vždy int

eAccelerator, anotace jsou fajn, píšu je tam, ale kvůli eAcceleratoru se nepoužijí.

//EDIT: Co používáš za accelerator, že ti anotace fungují?

Editoval honzakuchar (28. 10. 2009 14:20)

Jednak kvůli eAcceleratoru (ne vždy si ho můžeš na serveru nastavit k obrazu svému) a jednak někomu anotace nemusí vyhovovat (vše, co je v komentářích, by mělo být postradatelné).

paranoiq napsal(a):

ale tohle není zrovna nejlepší způsob. proč komplikovat syntax @persistent, když na typy proměnných už dávno existuje zavedená syntax dokumentačních anotací:

Je někde seznam všech dokumentčních anotací?