nebezpečnost parametrů GET
- tomaass
- Člen | 74
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ěď
- Ondřej Mirtes
- Člen | 1536
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)
- Jan Tvrdík
- Nette guru | 2595
Zkus si pročíst tento příspěvek: https://forum.nette.org/…zeni-smazani?…
- _Martin_
- Generous Backer | 679
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
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
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
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
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
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..
- David Grudl
- Nette Core | 8227
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.
- Jan Tvrdík
- Nette guru | 2595
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
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 | 8227
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
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
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
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
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
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
phpDoc: http://manual.phpdoc.org/…nverter/PHP/
a tady jsou popsány trochu více do podrobna
javaDoc: http://java.sun.com/…doccomments/#tag