Hi again, The example that I put here is a typical example when you read articles about CSRF attacks. It demonstrates that the "attack" request is made by a valid user with his credentials (cookies).
>> "This second authentication usually also contains an encrypted version of the amount that should be transfered." yes! this is random token solution that I have commented. You can add a random parameter to all requests or to encrypt the values of all the noneditable parameters (links, lists, radios, etc.). Therefore, if we did not adopt automatic solutions it is probable that most of the applications they are vulnerable to this type of attacks. Is it not better than frameworks like Wicket solves certain vulnerabilities to us? >> CryptedUrlWebRequestCodingStrategy... (William Hoover) This strategy as I know is only applied to urls and not to data forms! But I would like that this point was confirmed by a wicket's developers group. >> public wiki document... (Martin Makundi) First, I would like to know Wickets' features better and they confirmed me if my questions are correct or no... >> CONFIDENTIALITY >> It is not possible out of the box afaik but you could either try to >> subclass Form or write a filter to intercept and replace form values >> when wicket sends the response and reverse it when the user submits >> the form. right, I know that I could do it as HDIV does but I like to know if this feature is provided by Wicket framework, I think that it would be very interesting...what do you think about an automatic solution? Excuse me, I'm french and my english is poorer than I would like. Thanks again four your time! I consider that it is a subject that to all interests to us. Arthur. 2008/2/29, Maurice Marrink <[EMAIL PROTECTED]>: > > > 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? > > In this case i think the problem would be the app allowing the > transfer without requiring additional authentication and not the > framework. > Fortunately my online bank does require this and thus no amount of > links will ever get past the response of "authenticate yourself > again". > This second authentication usually also contains an encrypted version > of the amount that should be transfered. > > > > > > 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? > > It is not possible out of the box afaik but you could either try to > subclass Form or write a filter to intercept and replace form values > when wicket sends the response and reverse it when the user submits > the form. > > > Maurice > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
