CSRF Prevention

Hi,

Are we able to describe how CSRF is prevented?

When we deliver actions via POST in the Dash interface, I understand that preflight requests are made to the server from the browser for non-standard headers like application/json, indicated in the OWASP guide https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet under “Content-Type Header Validation” and Mozilla https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

Is this how Dash and DPD are preventing CSRF by default? I have spent a while looking at both Dash and DPD but am having a difficult time decoding whether we should be implementing our own CSRF token methods.

[eddy-ojb]

As far as I can tell from my first cut I have this working as per your thoughts.

Django’s get_token method is called from the initial layout method and the token is assigned as a replacement value for a component in the layout using the walk_tree_and_replace method in WrappedDash. Django’s CsrfViewMiddleware is extended to search for a component with ‘csrfmiddlewaretoken’ in the body if its a POST request and no csrf token is otherwise found.

I have a few couple of thoughts as to how this can be improved e.g.

• It would be ideal to have every callback wrapped with this functionality instead of using the ‘anti-csrf component’ as an input to every callback
• the code could set and search for the csrf token more efficiently - this is something I would gladly receive some feedback for
• I am open to any other better ideas and implementations

I will revisit the code again this week and send a pull request.

[GibbsConsulting]

From this I’m wondering if something along the lines of the following might work:

• Use the Django CSRF framework as a base
• In place of a hidden form attribute, use something like a hidden extra component in the Dash layout to contain the CSRF token
• Replace the django.middleware.csrf.CsrfViewMiddleware (if needed) with an enhanced version that is the Django middleware for all non-Dash views, and instead picks out the CSRF token from the hidden component when in use

This would have the advantage of keeping things fairly close to (and consistent with) the main Django CSRF approach.