Skip to content

Notes about caching pages with a CSRF Form #4141

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 4, 2015
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions book/forms.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1791,6 +1791,13 @@ section.
The ``intention`` option is optional but greatly enhances the security of
the generated token by making it different for each form.

.. caution::

CSRF tokens are meant to be different for every user. This is why you
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for every request?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no. If the same user (user being related to a session here, so the same guy using 2 browsers will count as 2 users) is doing 2 requests, the same token will be used (for a given token id). Otherwise it would be impossible to check tokens later

need to be cautious if you try to cache pages with forms including this
kind of protection. For more information, see
:doc:`/cookbook/cache/form_csrf_caching`.

.. index::
single: Forms; With no class

Expand Down Expand Up @@ -1931,6 +1938,8 @@ Learn more from the Cookbook
* :doc:`/cookbook/form/form_customization`
* :doc:`/cookbook/form/dynamic_form_modification`
* :doc:`/cookbook/form/data_transformers`
* :doc:`/cookbook/security/csrf_in_login_form`
* :doc:`/cookbook/cache/form_csrf_caching`

.. _`Symfony Form component`: https://github.com/symfony/Form
.. _`DateTime`: http://php.net/manual/en/class.datetime.php
Expand Down
48 changes: 48 additions & 0 deletions cookbook/cache/form_csrf_caching.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
.. index::
single: Cache; CSRF; Forms

Caching Pages that Contain CSRF Protected Forms
===============================================

CSRF tokens are meant to be different for every user. This is why you
need to be cautious if you try to cache pages with forms including them.

For more information about how CSRF protection works in Symfony, please
check :ref:`CSRF Protection <forms-csrf>`.

Why Reverse Proxy Caches do not Cache these Pages by Default
------------------------------------------------------------

There are many ways to generate unique tokens for each user but in order get
them validated when the form is submitted, you need to store them inside the
PHP Session.

If you are using Varnish or some similar reverse proxy cache and you try to cache
pages containing forms with CSRF token protection, you will see that, by default,
the reverse proxy cache refuses to cache.

This happens because a cookie is sent in order to preserve the PHP session open and
Varnish default behaviour is to not cache HTTP requests with cookies.

If you think about it, if you managed to cache the form you would end up
with many users getting the same token in the form generation. When these
users try to send the form to the server, the CSRF validation will fail for
them because the expected token is stored in their session and different
for each user.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I like this type of description for showing the problem with caching CSRF pages

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I see that I should not say that is based on the session id, rephrasing it


How to Cache Most of the Page and still Be Able to Use CSRF Protection
----------------------------------------------------------------------

To cache a page that contains a CSRF token you can use more advanced caching
techniques like `ESI`_ fragments, having a TTL for the full page and embedding
the form inside an ESI tag with no cache at all.

Another option to be able to cache that heavy page would be loading the form
via an uncached AJAX request but cache the rest of the HTML response.

Or you can even load just the CSRF token with an AJAX request and replace the
form field value with it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would you have an example for this? it would mean not rendering the csrf hidden form element, and do an ajax call to retrieve the current csrf token?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, either get the full form markup, just the hidden field markup or even just the token string via an uncached AJAX request.

It may be tricky to explain it with words and make it clear for someone who is not familiar with all these concepts...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the symfony code example would be helpful. how do i render the form (no form_rest()?) and how do i render just the csrf for the ajax call? and how is this handled on the post, do we then keep the session cookie so the form layer just sees the csrf token automatically?

i think a closely related problem to what we discuss here is how to make sure a session is only present on requests that actually need it (csrf ajax request). is there a way on symfony side to prevent the session from being started, and to unset the cookie right away after successful form submission? or do you use varnish config with knowledge of which url needs or needs not a cookie? (the later would seem more error prone to me)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

once merged, we should also link to #4661 - this PR and #4661 are pieces of the same puzzle

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with merging this without the example for now - we've given them 3 options, and I actually think the first 2 are probably the best (include the form in an un-cached ESI or load it via AJAX entirely).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the latest comments and tweaks and rebased with 2.3, anything else missing @weaverryan @dbu ?


.. _`Cross-site request forgery`: http://en.wikipedia.org/wiki/Cross-site_request_forgery
.. _`ESI`: http://www.w3.org/TR/esi-lang
.. _`Security CSRF Component`: https://github.com/symfony/security-csrf
1 change: 1 addition & 0 deletions cookbook/cache/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -5,3 +5,4 @@ Cache
:maxdepth: 2

varnish
form_csrf_caching
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is also a cookbook/map.rst.inc that needs this entry

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

1 change: 1 addition & 0 deletions cookbook/map.rst.inc
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@
* :doc:`/cookbook/cache/index`

* :doc:`/cookbook/cache/varnish`
* :doc:`/cookbook/cache/form_csrf_caching`

* **Composer**

Expand Down