Hi igor, your response demonstrate that Wicket's behaviour is very simple to extend and it is that I like from wicket. I think that to prevent CSRF attacks is neccessary to add your random parameter to all requests...it was that I would like to comment here! To prevent CSRF with a random parameter is necessary to extend wicket's behaviour and it isn't an automatically task delegated in Wicket framework.
There are people that thinks that CSRF attacks are not possible in Wicket applications but I think that wicket's urls are easily created by an attacker with a valid values stored in a victim's session and therefore attacks are possible by "src" attribute of images. See: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics Using captchas this problem is resolved but as I said here what I wanted was that Wicket prevented by default CSRF attacks. I want to clarify that I like Wicket and what I'm doing is asking and helping to secure Wicket...I think that this solutions are not paranoia and they are necessary in production environments... Arthur. 2008/2/29, Igor Vaynberg <[EMAIL PROTECTED]>: > > here are some ideas to much over... > > class SecureForm extends Form { > private String token; > protected void onbeforerender() { token=UUID.randomUUID.toString(); } > protected void oncomponenttagbody() { > getresponse().write("<input type='hidden' name='token' > value='"+token+"'/>"); > super.oncomponenttagbody(); > } > public boolean process() { > if (!token.equals(getrequest().getparameter("token")) { > throw new IllegalStateException("token mismatch"); > } > return super.process(); > } > } > > so now you have token validation between http space and session space > > if you want to take it to the next level > > class SecureTextField extends TextField { > private String secureName; > > public String getInputName() { > if (secureName==null) { > secureName="a"+UUID.randomUUID().toString().replace("-",""); > } > return secureName; > } > } > > and now you have a textfield whose input name is unpredictable > > there are all kinds of things you can easily do in wicket, just > depends on your level of paranoia. > > -igor > > > > > > > > On Fri, Feb 29, 2008 at 7:33 AM, Arthur Ahiceh <[EMAIL PROTECTED]> > wrote: > > 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
