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]
