Thx!
Yes, this helps :-)
regards,
michael
On 6 Aug., 13:24, Florian <sideral.undergro...@gmail.com> wrote:
> If you want to override the way CSRF token is created in a clean
> manner, you can override the getCsrfToken method in your BaseForm
> class.
>
> protected function getCsrfToken()
> {
> return md5($this->csrfSecret.session_id().get_class($this)); // or
> whatever else you
>
> want
> }
>
> The BaseForm class is in the "user land", it has been created to
> customize all your application forms without having to modify core
> classes.
>
> Hope it helps!
>
> On Aug 6, 11:22 am, "mlu...@gmail.com" <mlu...@gmail.com> wrote:
>
> > For functional tests i turn off captcha in general.
> > I do test them manually.
>
> > Isn't the way how the token is generated implemented in the symfony
> > framework?
> > I don't want to make any changes in the framework, because it leads to
> > problems when updating the framework.
> > Can I control this part?
>
> > On 6 Aug., 10:30, Florian <sideral.undergro...@gmail.com> wrote:
>
> > > Use something else than the session_id to generate the CSRF token
> > > maybe ?
> > > Or increase the session timeout ;)
>
> > > what about functional tests with captcha ?
>
> > > On Aug 6, 7:57 am, "mlu...@gmail.com" <mlu...@gmail.com> wrote:
>
> > > > Don't you really have an opinion about this?
> > > > I'm sure you have ;-)
>
> > > > On 4 Aug., 16:44, "mlu...@gmail.com" <mlu...@gmail.com> wrote:
>
> > > > > Hi!
>
> > > > > I want to show you my attempt of a security/form strategy and want to
> > > > > know what you are thinking about it.
>
> > > > > *The problem:*
> > > > > If I read the source correct the CSRF_token is made of the session id
> > > > > and the class name of the form.
>
> > > > > When you load a form and submit it after a certain time you get a csrf
> > > > > attack because the session id has changed in the meanwhile. The
> > > > > problem is that the wrong tiken gets delivered with the form to the
> > > > > user again, so every time the user resubmitts the form you get an
> > > > > attack. The only way to get rid of the wrong token is to reload the
> > > > > form, but than the user will lose all entered values.
>
> > > > > A solution could be to reset the token when redelivering the form to
> > > > > the user. This way the user can resubmit the form with his/her values.
> > > > > But this makes the form accessable for XSS attacks, because an
> > > > > attacker just needs to submit the form twice, what can be done via
> > > > > javascript too.
>
> > > > > My ideas is to add a captcha to the form if it sees a csrf attack. The
> > > > > captcha can't be solved viy javascript.
>
> > > > > What does it look like for the user?
>
> > > > > 1. The user loads a form
> > > > > 2. After a certain time he submits the form.
> > > > > 3. The form gets delivered to the user with his values, with reset
> > > > > csrf_token and an added captcha.
> > > > > 4. The user solves the captcha and submits the form.
> > > > > 5. Everything is fine.
>
> > > > > What do you think about it.
>
> > > > > regards,
>
> > > > > michael
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
