yes, Sebastian, wicket resolved data tampering because it stores in session form data. I commented "data tampering" too to refer to security features that could be provided by frameworks, like HDIV does...
;-) Arthur. 2008/3/4, Sebastiaan van Erk <[EMAIL PROTECTED]>: > > Hi, > > The tampering with data part is resolved by Wicket, since Wicket does > not use hidden fields but stores the data in the session on the server > side. > > Furthermore, Wicket by default does server side validation of all input, > even if you add ajaxy behaviors to also do client side validation. > > Regards, > Sebastiaan > > Arthur Ahiceh wrote: > >>> I believe that answers the original question, that CSRF protection is > > *NOT* a security feature offered by Wicket. > > > > I think the same, I said it and they tell me that URLs wasn't > predictables > > when the page identifiers are a correlative numbers, so vulnerable to > CSRF > > attacks. > > > > I want to emphasize that I think that these tasks (avoid CSRF attacks, > to > > offer confidentiality, avoid tampering data in forms) would must be > resolved > > by default by frameworks like Wicket to offer "a security framework". > > > > Arthur. > > > > > > > > > > > > > > > > 2008/3/4, Sebastiaan van Erk <[EMAIL PROTECTED]>: > >> Wicket does nothing to protect from CSRF attacks, and it is trivially > >> vulnerable. Sure it's a lot more difficult with the standard > >> ?wicket:interface type URLs than it would be with more predictable > URLs, > >> but you can still quite easily guess the URLs, and futhermore, to > >> improve your chances of success you can simply include many images in > >> the attacking page with different values for the URLs, i.e., > >> > >> img > >> src=" > >> > http://thesiteiwannahack.com/?wicket:interface=:11:formToHack::IFormSubmitListener::&myparam1=val1 > >> " > >> > >> and then for page id 11, 12, 13, 14, for 1 to 100 for all I care, all > in > >> one page. > >> > >> Furthermore, most people actually LIKE predictable urls and go to great > >> length to mount pages and make them bookmarkable. There's even a > >> StatelessForm component, which is entirely vulnerable to CSRF. > >> > >> Thus, I'd say that even without a quickstart, it's obvious that Wicket > >> does not offer any CSRF protection out of the box, and that if you want > >> this kind of protection, you will have to do it yourself (which is > >> probably not really difficult; though I think many people are not aware > >> of these kind of attack vectors and don't even think about it, which is > >> why it would be nice if Wicket *could* do it out of the box). > >> > >> I believe that answers the original question, that CSRF protection is > >> *NOT* a security feature offered by Wicket. > >> > >> Regards, > >> Sebastiaan > >> > >> Nino Saturnino Martinez Vazquez Wael wrote: > >>> While that is true.. It's also true that wicket devs favor stuff > proven > >>> with a quickstart, because it becomes easier to make a fix for > something > >>> you can see in code.. > >>> > >>> So as I've written once before a quickstart should be the way to go or > >>> just use one of the existing applications, phone book or blog tutorial > >>> etc. And make a hack at that... > >>> > >>> regards Nino > >>> > >>> Ned Collyer wrote: > >>>> Nick, I think you would be quite surprised at the level of auditing > >>>> something > >>>> has to pass to be used in a financial system, especially a bank. > >>>> (unless u > >>>> have some dodgy bank) > >>>> > >>>> If something is theoretically possible, then thats as good as > "proven". > >>>> > >>>> Gotta remember that hackers are a lot smarter in many instances than > >> the > >>>> people who wrote the software to keep them out. > >>>> > >>>> > >>>> Nick Heudecker wrote: > >>>> > >>>>> Arthur, > >>>>> > >>>>> Only what you can *prove* matters, not what you think. Have you > >> created > >>>>> an > >>>>> example application with a CSRF attack? > >>>>> > >>>>> > >>>> > >> > > > >
