Dňa 22.10.2007, Martin Kuba <[EMAIL PROTECTED]> napísal(a):
>
> > 0. Prihlasovanie odosielane cez POST-metodu :-)
>
> Vsechny odesilani formularu by mely jit pres POST metodu, ne jen
> prihlasovani.
> A po POSTu je dobre delat redirect.
tomuto celkom nerozumiem...
>
> > 3. Kazda stranka (okrem prihlasovacej) na zaciatku testuje ci existuje
> > session s id uzivatela, teda iba uz prihlaseny mozu pristupovat
>
> Je zbytecne duplikovat kod a mit to v kazde strance na zacatku,
> mnohem lepsi je udelat si na to Filter mapovany na vsechny stranky
> (a pro prihlasovaci v nem mit vyjimku).
ano, ano, ja to mam v tzv. page-header, v struts sa to vola include-prelude
alebo podobne
> > 4. Testovanie vsade, kde sa neocakvaju GET parametre, ci je metoda POST
> > 5. Osetrovanie parametrov, napr. ak ocakavam jediny, nieco ako if (
> > (request.getParameterMap().size!=1) spolu s testovanim presneho mena a
> > hodnoty
>
> Jak uz psal Filip Jirsak, Java neni skriptovaci jazyk, a proti nekterym
> typum utoku je z principu odolna.
znameno to, ze v jave ak ma uzivatel pristup k spracovaniu formulara, nevadi
ak by povynechaval ci popridaval nekorektne parametre?
>
> > oplati sa este nieco??
>
> Jiste, napriklad pokud se vypisuji do stranky data zadana uzivatelem,
> vzdycky je treba je prohnat pres neco, co osetri specialni znaky,
> napriklad JSTL tag
>
> <c:out value="${data}"/>
>
> protoze jinak muze zly uzivatel napsat do dat kus JavaScriptu
> a delat Cross-Site Scripting utoky.
ze <c:out ...> osetruje toto som netusil, vdaka
v mojom pripade idu ale vsetky data najprv do databazy, neskor sa z nej
nejake vypisuju na stranku
A hlavne pri kazdem pristupu k datum si kontrolovat, zda na to
> ma uzivatel opravneni, protoze zly uzivatel si muze rucne
> vytvaret URL tak, aby volal zpracovani formularu, aniz
> by se k formularum musel dostat.
musel by poznat presnu URL adresu:-)
Zda sa, ze v z principu odolnej Jave, nie je az taka hotova veda pisat
bezpecne web-aplikacie...
Vdaka za vsetky rady.
Ivan
