One token per form about csrf HOT 9 CLOSED

Adding one token per form will significantly increase the attack surface for the vast majority of web apps, because lots of valid tokens will never be consumed, leaving them available for compromise.

However, separate tokens per form would be required if an application is to use AJAX to allow multiple forms per page to be submitted.

How about adding a parameter to the protectAndInject() method, allowing the caller to force generation of individual tokens per form?

from csrf.

Coincidentally, when I was submitting this repo to packagist, I forgot to
submit the page and came back a few hours later. I submitted the form and
it showed me an error that the csrf token had expired, and I simply had to
submit the form again.

This could be the solution to the problem of having many tokens out in the
wild, as I think I'd prefer to have my pages Ajax ready as standard.

On Wed, 2 Mar 2016, 20:41 James Fellows, [email protected] wrote:

Adding one token per form will significantly increase the attack surface
for the vast majority of web apps, because lots of valid tokens will never
be consumed, leaving them available for compromise.

However, separate tokens per form would be required if an application
is to use AJAX to allow multiple forms per page to be submitted.

How about adding a parameter to the protectAndInject() method, allowing
the caller to force generation of individual tokens per form?

—
Reply to this email directly or view it on GitHub
#14 (comment).

from csrf.

In the ArrayTokenStore, the tokens would effectively expire when the session expires. Are you suggesting having tokens automatically expire after a period of time? That would be a separate feature I guess.

It would have a performance impact - I'd need to check every token's timestamp against the current time, but it's easy enough.

from csrf.

I don't know whether it's a better solution, but it was certainly how Packagist did it.

Regarding performance, wouldn't the timestamp only need to be checked when there is a POST made? Not every time the page renders?

I'll do some research as to how other frameworks do it.

from csrf.

Yes good point - in which case this would form a tiny part of the POST processing time.

from csrf.

Just realised that we could be missing the point here. If the developer is going to use ajax for submitting forms, they will need a way of refreshing tokens on the client-side anyway - in case the user submits the same form twice.
My knowledge of the workings of ajax/ javascript is rather poor - wouldn't it completely miss the point of the CSRF protection if we provided a URL that hands-out tokens willy-nilly? Or would the tokens be associated with the session from which they originated, so be "secure" so long as the javascript runs in the same ssl session?

from csrf.

You're falling into the trap of jquery style ajax, where page logic is duplicated client side.

The clean way of using ajax to submit forms is to simply perform a standard HTTP request, and just replace the part of the DOM that changes, including the new CSRF token from the new page.

from csrf.

Isn't this library supposed to be good for the jquery crew too? :)

from csrf.

We shouldn't introduce something that promotes bad coding; there's nothing inherently wrong with jquery's ajax, stopping jquery coders using this repo - I was referring to the tonne of bad advice online that gives jquery a bad name.

To be clear: JavaScript/jquery/curl can use this library, but we should not introduce any mechanism for arbitrarily generating new tokens (via a URL call, for example), just to satisfy bad coding style.

from csrf.