Sebastiaan van Erk wrote:
How does the crypted web url request coding strategy work with
bookmarkable pages and nice urls? Do they play nice together?
Im also thinking of Ajax, how does fit it...
The form with the token looks good, the question I have is, why is
something like it not the default (since almost everybody's site will
be vulnerable without it)?
I was thinking that too, or at least bring in the option, having a
safeForm or something like it packaged with wicket..
Currently protection from CSRF requires people 1) to know about CSRF
and either 2a) to code their own form solution (which might be broken)
or to rip it from the web (which might also be broken ;-)), or 2b) to
enable the CryptedUrlWebRequestCodingStrategy.
In any case, knowledge of such attacks is required and an action needs
to be taken, if you want to be protected. That's something maybe the
framework could do for you?
Hmm, if theres not performance/memory issues i'd say go for it aswell.
Making stuff secure as default is always nice...
Regards,
Sebastiaan
Nino Saturnino Martinez Vazquez Wael wrote:
Hmm, Im a little slow this week.. Theres even an article about it:
http://javathoughts.capesugarbird.com/2007/08/protecting-wicket-application-against.html
Johan Compagner wrote:
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?
--
-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]