nebezpečnost parametrů GET

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
tomaass
Člen | 74
+
0
-

Dobrý den,

s Nette teprve začínám. Nikde sem se nedočetl, jak jednoduše (nejlépe s použitím CurlyBracketsFilteru) zabezpečím GET parametry předávané v URL adrese. Jde o to, že né vždy by měl uživatel vidět, co aplikace posílá, a už vůbec by to neměl ovlivnit (například …/document_root/?money=7) -persistentní proměnná. Velmi jednoduše ji uživatel změní a značně to ovlivní bezpečnost aplikace. Jak tedy aplikaci ochráním před útoky „pozornějších“ ?
Děkuji za odpověď

Honza Marek
Člen | 1664
+
0
-

Což takhle dát money do session?

Ondřej Mirtes
Člen | 1536
+
0
-

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)

tomaass
Člen | 74
+
0
-

dobře, dám tedy $money do sessiony. Udelam si na nastavovani teto promene nejaky Setter v presenteru a volam ho z templatu nasledovne: {link insert!, 10}. Url adresa ale bude stejne obsahovat data nachylna ke zmene. Delam to spravne?

Jan Tvrdík
Nette guru | 2595
+
0
-

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

_Martin_
Generous Backer | 679
+
0
-

tomaass napsal(a):

dobře, dám tedy $money do sessiony. Udelam si na nastavovani teto promene nejaky Setter v presenteru a volam ho z templatu nasledovne: {link insert!, 10}. Url adresa ale bude stejne obsahovat data nachylna ke zmene. Delam to spravne?

Myslím, že se snažíš o něco trochu jiného, než ten příklad představuje. Ty v tom příkladu vidíš systém, kde uživatel nějakým způsobem vkládá peníze (třeba přes platební kartu) a systém si někde hlídá, kolik peněz jsi vložil – v takovém případě by opravdu šlo o bezpečnostní chybu, protože přepsáním parametru v adrese by jsi obešel kontrolní mechanismus platebního systému.

V tomhle případě jde ale o něco jiného. Zde není žádný mechanismus, který hlídá, zda jsi skutečně zaplatil. Zde se prostě bere, že co říkáš aplikaci, to platí.

Nejde totiž o příklad platební aplikace, ale o využití persistentního parametru. Samozřejmě, pokud bys někdy programoval takový systém, tak výši uživatelova konta nebudeš uchovávat v persistentní proměnné. Ovšem v tomto příkladu si aplikace nekontroluje, zda jsi do ní opravdu vložit „tolik peněz“, takže nevadí, pokud parametr měníš – pro tu aplikaci je to jedno a to samé.

Nicméně dobrý dotaz. Snad už je ti to nyní jasnější.

tomaass
Člen | 74
+
0
-

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
Člen | 74
+
0
-

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 :)

jasir
Člen | 746
+
0
-

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)

Ondrej
Člen | 110
+
0
-

tomaass napsal(a):
bez POSTu neobešel … posílá metodou POST…

Metoda POST neni o nic vic bezpecnejsi nez metota GET. V oboji muze uzivatel podstrcit co se mu zamane, takze musis aplikacne ohlidat jestli parametry jsou korektni, pripadne jestli takove parametry muze uzivatel na server posilat.

redhead
Člen | 1313
+
0
-

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..

tomaass
Člen | 74
+
0
-

Tak už jsem se těmi odbornými výrazy prokousal, realizoval, no a je to paráda. Sice do toho vůbec nevidím, ale funguje to podle mých představ.

Děkuju za pomoc a přeji pěkný den.

David Grudl
Nette Core | 8082
+
0
-

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.

Patrik Votoček
Člen | 2221
+
0
-

Jsem pro pokud bude existovat i varianta bez anotací… :-)

Honza Kuchař
Člen | 1662
+
0
-

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

Jan Tvrdík
Nette guru | 2595
+
0
-

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

_Martin_
Generous Backer | 679
+
0
-

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
David Grudl
Nette Core | 8082
+
0
-

Ještě bych přihodil variantu pro parametr, který byl předán v požadavku (tj. je dostupný přes getParam($key)), ale není persistentní. A teď babo raď, jakou tomu udělat syntax.

Klidně může využívat pananoiqovu rozšířenou syntax (zatím tedy neimplementovanou).

ad funkčnost bez anotací: kvůli tomu, že anotace ee, nebo kvůli eAcceleratoru?

Honza Kuchař
Člen | 1662
+
0
-

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)

Patrik Votoček
Člen | 2221
+
0
-

David Grudl napsal(a):

ad funkčnost bez anotací: kvůli tomu, že anotace ee, nebo kvůli eAcceleratoru?

eAccelerator se da nastavit tak aby anotace fungovaly takze kvuli tomu to neni. Spis je to kvuli tomu ze uz to zavani rozsirovanim moznosti ktere PHP má a že se může pořád vyskytnout server kde to prostě nebude fungovat. (Nebo se chlapci z PHP Dev teamu jednou rozhodnou něco takového implementovat a bum nám se to rozbije)

Ondřej Mirtes
Člen | 1536
+
0
-

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
Člen | 392
+
0
-

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?

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í:

/**
 * @persistent(url)
 * @var integer
 */
$persistentIntegerVariable;

Editoval paranoiq (29. 10. 2009 12:26)

Patrik Votoček
Člen | 2221
+
0
-

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í?

paranoiq
Člen | 392
+
0
-

phpDoc: http://manual.phpdoc.org/…nverter/PHP/

a tady jsou popsány trochu více do podrobna
javaDoc: http://java.sun.com/…doccomments/#tag