Nick Heudecker wrote:
I don't think it's possible to hijack the Wicket URL like you're
describing.
Exactly my words! it is not possible, while starting to use
jmeter(sometime ago) I forgot to close my browser inorder to get a new
session. And when replaying the scenarios it only caused errors. You
need to hijack the users session aswell.
Why don't you put together a quickstart application and publish
it? I'm guessing that you haven't actually built anything with Wicket.
Trying a CSRF attack in an example application would be a good first pass.
This sounds like the way to go... And if any weaknesses are discovered,
I do not think its that hard to produce secure versions of components..
On Fri, Feb 29, 2008 at 8:03 AM, Arthur Ahiceh <[EMAIL PROTECTED]>
wrote:
Hi Igor,
4. CSRF attacks
>> first you would have to hijack the session...
>> then in order for you to hit
?wicket:interface=:0:goGerman::ILinkListener::
>> a few things have to be true:
>> a) attacker has to hijack the session
>> b) page id (the 0 part of the url) has to match with the link path
in
>> the user's session. this depends on the order user has visited the
>> pages
>> c) user had to actually have visited the page previously
>> even if thats not enough it is trivial to write your own coding
>> strategy that appends the random token and stores its mirror in
>> session....
While pages ids have been correlatives, hacker could always construct a
valid url to generate a CSRF attack. Let's see a typical example...
Consider a bank web site that allows its users to make account transfers.
Once a user has logged in and received an authentication cookie, he needs
only to request the URL
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::&inputForm4_hf_0&transferTo=123&amount=1000in
order to transfer $1000 to account number 123. If an attacker can
trick
an already-authenticated user into visiting a malicious page that contains
an image link like <img src=
http://www.bank.com/manageaccount/?wicket:interface=:0:inputForm::IFormSubmitListener::&inputForm4_hf_0&transferTo=456&amount=1000/
True, if they could get the random stuff right. But still they need for
the user to have opened the page in the same browser inorder todo this.
But one solution could to be to require confirmation of transfers,
involving captchas...You could also have a very short timed keepalive
involved.
,
the user's (victim) browser will automatically request that URL, thus
making
an account transfer without the user's knowledge or consent.
Once the victim makes a valid transfer, the transfer's values are in
session, so if the attacker generates many images like commented with
different values in "interface" parameter, he would obtain the objective.
So, I think that it is necessary to insert a random value to all requests
or
generate confidential values for all parameters of a request. What do you
think?
3. CONFIDENTIALITY: I have seen in forms that radio's options an
checkbox's
values have no confidential values. Could I put automatically all form
values confidentiality in Wicket? I don't want that the attacker sees the
original values...
Is it possible to apply encrypt strategy to forms?
? I not sure I know what you mean here, if you've worried about that
theyll be able to guess the id's you could use a IChoicerender which
added some random noise to the id's, or gave an encrypted value..
thanks!
Arthur.
--
-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]
