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 thanthepeople who wrote the software to keep them out. Nick Heudecker wrote:Arthur, Only what you can *prove* matters, not what you think. Have youcreatedan example application with a CSRF attack?
smime.p7s
Description: S/MIME Cryptographic Signature
