>> Having an quickstart as a usecase could help developers decide if its worth the effort. Since the moment that wicket does not add any random parameter to urls, the applications are vulnerable to CSRF attacks, so I think that quickstart application could be a good example but I think that we can view easily that URLs are predictable and therefore a framework vulnerable (by default) to this attack type.
>> "Nothing is secure" I "agree" with this confirmation but if we develop a secure frameworks BY DEFAULT, we will prevent a lot of attacks BY DEFAULT! Security features must be functionalities offered by frameworks by default and they do not have to be an option of the final users. Arthur. 2008/3/4, Nino Saturnino Martinez Vazquez Wael <[EMAIL PROTECTED]>: > > As with all thing's you can make them more or less secure. As stated > before, depending on a level of paranoia nothing are secure! > > Mounting a page and making it stateless, and further more making it take > parameters is one of less safer ones. > > If the application is a web one, well use CSRF attacks, use random > attacks, Bruteforce the site, go to their operator and get inside the > database. Eventually you will get in, if you cover your tracks. > > If the application is a desktop version, deploy a keylogger and a mouse > recorder, grab their password file. If they cycle passwords, bruteforce > that too. Might not work with the first 100 users, but in time and > theory you will get in. > > Nothing is secure. > > Having an quickstart as a usecase could help developers decide if its > worth the effort. Whats a reasonable level for security... I guess the > best one is telling the users to use the browser exclusivly for the bank > site and be sure to logout before leaving it. > > -Nino > > Sebastiaan van Erk 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. > This is not new, it's been discussed a few messages ago... You still > need to hijack the users session. > > > > 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. > I believe that true in the sense that you can always make your pages > vulnerable if you want to (also if its unknowingly). > > > > 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? > >>>> > >>>> > >>> > >>> > >> > > -- > -Wicket for love > -Jme for fun > > Nino Martinez Wael > Java Specialist @ Jayway DK > http://www.jayway.dk > +45 2936 7684 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
