Arthur, Only what you can *prove* matters, not what you think. Have you created an example application with a CSRF attack?
On Mon, Mar 3, 2008 at 10:42 AM, Arthur Ahiceh <[EMAIL PROTECTED]> wrote: > 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] > > > > > -- Nick Heudecker Professional Wicket Training & Consulting http://www.systemmobile.com Eventful - Intelligent Event Management http://www.eventfulhq.com
