Wicket has support for protection just enable it: CryptedUrlWebRequestCodingStrategy
and you can use that in combination with: UrlCompressingWebRequestProcessor The problem with this is i guess that the normal form get then also still works but i am not sure On Tue, Mar 4, 2008 at 11:42 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > 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? > >>> > >>> > >> > >> > > >
