4. Yes. See mailing list for earlier answers. There are more hardening
options such as encrypting urls.
Even encrypting the urls Wicket is vulnerable to CSRF because the key used
to encrypt is shared by all users of application. Wicket is an extensible
framework where you to add some new
Arthur Ahiceh wrote:
4. Yes. See mailing list for earlier answers. There are more hardening
options such as encrypting urls.
Even encrypting the urls Wicket is vulnerable to CSRF because the key used
to encrypt is shared by all users of application. Wicket is an extensible
ok! you have not used the word easily but only saying There are more
hardening options such as encrypting urls it only seems that encrypting
urls the problem is solved and it is not the case! The user has to
implement a custom security factory, one different than provided by Wicket
This assumes that the hacker correctly guesses the application key
(which you of course changed from the default setting), or has access
to your application to harvest URLs.
Making the SunJceCrypt user specific is as simple as:
new SunJceCrypt() {
@Override public String getKey() {
Arthur Ahiceh wrote:
ok! you have not used the word easily but only saying There are more
hardening options such as encrypting urls it only seems that encrypting
urls the problem is solved and it is not the case! The user has to
implement a custom security factory, one different than provided
CSRF uses urls to do something on another side right?
for example
img src=
http://bank.example/withdraw?account=bobamount=100for=mallory;
How would that work in a default wicket application?
Is it really so stupid developed that these kind of things uses client side
state?
So this cant be
Thank you all
Marcelo Morales
On Thu, Aug 7, 2008 at 2:44 AM, Erik van Oosten [EMAIL PROTECTED] wrote:
Hello Marcelo,
1. No. The flip side of having full control of the HTML is that you need
to write it yourself.
2. In Wicket it is trivial to keep state (read the conversation state)
on
Erik, if you did not mean that I feel it, I understood that. ;-)
Arthur
Erik van Oosten wrote:
Arthur Ahiceh wrote:
ok! you have not used the word easily but only saying There are more
hardening options such as encrypting urls it only seems that encrypting
urls the problem is solved
Martijn, this solution is correct but I tell that I said in post [1]...
Wicket is a framework where you can implement an easy solution but I prefer
that these types of solutions were distributed by default!
[1]
http://www.nabble.com/Security-Features-offered-by-Wicket-to15738864.html#a15738864
Arthur Ahiceh write:
Erik, if you did not mean that I feel it, I understood that. ;-)
Arthur
Okay, thanks. (I didn't.)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Johan Compagner wrote:
...Which is pretty random. Only if all users would go over the same path
always to the same page then the id could be guessed.
Actually, I do not think that is completely far fetched. In my banking
applications I mostly follow the same path. In some applications there
but all actions on bookmarkable pages have session relative urls,
which makes guessing the correct URL still problematic.
Martijn
On Thu, Aug 7, 2008 at 3:16 PM, Erik van Oosten [EMAIL PROTECTED] wrote:
Johan Compagner wrote:
...Which is pretty random. Only if all users would go over the same
I was talking about the case where you are silly enough to code an
action in the constructor of a bookmarkable page. (Really, I have seen
it happen.)
Regards,
Erik.
Martijn Dashorst wrote:
but all actions on bookmarkable pages have session relative urls,
which makes guessing the correct
Hello
I've browsed over the wicket documentation and examples. There are a
couple of things I don't seem able to determine. So I would really
appreciate your input on this questions.
1. Can I write a web application without coding any HTML
whatsoever?...
I mean, is there some kind of html
14 matches
Mail list logo
