I don't think it's possible to hijack the Wicket URL like you're describing. 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.
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/ > >, > 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. > -- Nick Heudecker Professional Wicket Training & Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com
