I would like to discuss the reason behind using the app's secret key in the hashed csrf token cookie value.

Hashing the secret key in the CSRF token cookie value means if someone discovers how to predict python's random number generation then they will have an unsalted hash of the app's secret key.

The point of FlaskSeaSurf is to validate the X-CSRFToken header value equals the randomly generated CSRF token cookie value. This ensures the request is coming code running on the same domain as the csrf token cookie. How does using the app's secret key provide any added security?

Some info on when Python's random number generator becomes predictable:

http://www.godsmonsters.com/Features/how-random-python/

http://stackoverflow.com/questions/2145510/python-random-is-barely-random-at-all

https://spideroak.com/blog/20121205114003-exploit-information-leaks-in-random-numbers-from-python-ruby-and-php

By setting self.app = app in init_app, you can't effectively share one instance of SeaSurf in the same process that has multiple Flask apps. self.app should only be set in the SeaSurf constructor.

While running a dynamic scan against an app protected by seasurf, Burp Suite Pro flagged an issue with the CSRF token.

For a GET operation, it altered the _csrf_token value as below, and raised an alarm when the app didn't respond for > 20 seconds, indicating the sleep operation was successfully run, indicating a Python injection vulnerability.

Cookie: _csrf_token=eval(compile('for%20x%20in%20range(1)%3a%5cn%20import%20time%5cn%20time.sleep(20)'%2c'a'%2c'single'));

The last release to pypi was 0.2.2 on 3/16/2016. It looks like some of the commits since then are nice to have published. Is there another release planned?

Currently, flask-seasurf will only send the client a cookie containing a CSRF token if someone has called the _get_token() function, usually from a Jinja2 view.

If you are doing AJAX requests and don't use the Jinja2 tag {{ csrf_token }} - that is, if you just want to use the value in the cookie for doing some AJAX after loading a CSRF-protected view, this change lets you do that.

It adds a bit of the request context into the application global g so that the response can know whether or not it should include a cookie. I thought that it would be reasonable to set the cookie on the response if the page should be protected per the app config.

Because all views that are protected per the config can now get the cookie upon render, there is no need to check and see if someone actually used the csrf_token tag. Previously, the 'used' flag was never set, meaning the cookie never got set.

i think the csrf token must not just be stored in a cookie.

A cookie comes from the client. The cookie name is known and the client (attacker) can (at least potentially) put any value it likes in there. Maybe not easily (different domain) , but browsers could have bugs also...

Then, you compare that value against another value (the csrf token form field or http header value) that also comes from same client.

So, if client just puts same value at both places, it can do any csrf it likes.

If the csrf token is not read from the cookie, but from the session (which either comes from a file on the server or from a signed SecureCookie), the client can not tamper it.

See also there: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

And there: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ """ Limitations

Subdomains within a site will be able to set cookies on the client for the whole domain. By setting the cookie and using a corresponding token, subdomains will be able to circumvent the CSRF protection. The only way to avoid this is to ensure that subdomains are controlled by trusted users (or, are at least unable to set cookies). Note that even without CSRF, there are other vulnerabilities, such as session fixation, that make giving subdomains to untrusted parties a bad idea, and these vulnerabilities cannot easily be fixed with current browsers. """

I've been reading about CSRF and it looks like one should only do retrieval with GET request and everything else with a POST request. This is quite inconvenient with a list of delete links in a list or a logout link.

I added include decorator and one parametr in app config 'SEASURF_INCLUDE_OR_EXEMPT_VIEWS'. Also add new test for new decorator and some minor changes.

In current version, only views could be exempted from CSRF check. It seems not that convenient sometimes since users have to put csrf.exempt to each views.

I just added a new method to allow users to exempt from CSRF check based on url rules.

The fact that you can disable testing with app.config["TESTING"] = True is amazing.

I'm not sure about the security implementations but please document this in the official documentations.

what is the point of that code (compared to just using a random value as csrf token)?:

    salt = (randrange(0, _MAX_CSRF_KEY), self._secret_key)
    return str(hashlib.sha1('%s%s' % salt).hexdigest())

(flask-csrf just uses str(uuid4()) btw.)

Anyone got a hint how to add a Blueprint's route to the _exempt_views set? Something like csrf._exempt_views.add("bp_user.someroute") Importing the root @csrf.exempt decorator in the Blueprint doesn't seem to work either

I might be missing something here, but there seems to be a flaw with the disable_cookie logic.

If I set disable_cookie to True using app.csrf.disable_cookie(lambda r: True) Seasurf stops returning the set-cookie header as expected. However, the token value it generated (in its _before_request function) only seems to get set into session during the _set_csrf_cookie function, which is now bypassed because I have disabled_cookies. Since the token is never set into session, a new token will be generated on every request so I will never be able to get CSRF to pass validation.

The only way around this is to call current_app.csrf.generate_new_token() in the view function, as this function does set the new token value into session, but that means a new token value will be generated every request (thankfully previous ones will validate before they change).

Would it not make more sense to set the token value into session in _before_request when it is generated? Perhaps I am missing something obvious here?

With the django middleware the default settings are such that the CSRF token is stored in a cookie, with an optional setting to store in a server side session instead of using the cookie.

With Flask-Seasurf it appears that the default is to store the token in both the session and the cookie, but always use the session to validate against. I can't see a way to configure things to set just the session and not the cookie, or to use just the cookie and not store/validate against the session.

There is a disable_cookie() decorator, but that appears to disable session based storage too (as the session is actually updated in _set_session_cookie), Not sure if that's intentional - feels like a bug?

Ideally it would be nice for Flask-Seasurf to have the same flexibility as the django middleware, but if not it would be good to get a way to optionally disable the cookie as it doesn't seem to be strictly required.

The init_app function loads some options from app.config, I think this should be added to the docs, as it provides a mean of configuration.

self._csrf_name = app.config.get('CSRF_COOKIE_NAME', '_csrf_token')
self._csrf_header_name = app.config.get('CSRF_HEADER_NAME',
                                                'X-CSRFToken')
self._csrf_disable = app.config.get('CSRF_DISABLE',
                                            app.config.get('TESTING', False))
self._csrf_timeout = app.config.get('CSRF_COOKIE_TIMEOUT',
                                            timedelta(days=5))
self._csrf_secure = app.config.get('CSRF_COOKIE_SECURE', False)
self._csrf_httponly = app.config.get('CSRF_COOKIE_HTTPONLY', False)
self._type = app.config.get('SEASURF_INCLUDE_OR_EXEMPT_VIEWS',
                                    'exempt')

Especially CSRF_COOKIE_NAME which can be set to 'csrf_token' to get compatibility with Flask-Admin.