What about using the CryptedUrlWebRequestCodingStrategy? In your WebApplication:
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
protected IRequestCodingStrategy
newRequestCodingStrategy() {
// encrypt URL with a hash format
return new
CryptedUrlWebRequestCodingStrategy(new WebRequestCodingStrategy());
}
};
}
-----Original Message-----
From: Arthur Ahiceh [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 9:04 AM
To: users@wicket.apache.org
Subject: Re: Security Features offered by Wicket
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/>,
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?
thanks!
Arthur.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
