'SameSite' Cookie Attribute for Sessions tool

I’m submitting a …

• bug report
• feature request
• question about the decisions made in the repository

Do you want to request a feature or report a bug? feature

What is the current behavior?

Currently we cannot set a SameSite session cookie on cherrypy using the sessions tool.

What is the expected behavior?

Ideally we should be able to set the samesite attribute on any session using the standard configuration (eg.: ‘tools.sessions.samesite’) with either ‘lax’ or ‘strict’ values. This feature should also be exposed to custom session handlers.

What is the motivation / use case for changing the behavior?

As per the SameSite definition on caniuse.com:

Same-site cookies (“First-Party-Only” or “First-Party”) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.

Definition on OWASP wiki:

SameSite prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-origin information leakage. It also provides some protection against cross-site request forgery attacks. Possible values for the flag are lax or strict. As of November 2017 the SameSite attribute is implemented in Chrome, Firefox, and Opera. Since version 12.1 Safari also supports this. Windows 7 with IE 11 lacks support as of December 2018, see caniuse.com below.

Compatibility

As per current tests described at caniuse.com regarding the SameSite cookie attribute, all modern evergreen browsers seems to support this feature.

Related Links:

• https://caniuse.com/#feat=same-site-cookie-attribute
• https://www.owasp.org/index.php/SameSite
• https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
• https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00
• https://github.com/mozilla/http-observatory/pull/313
• https://web.dev/samesite-cookies-explained/

Please tell us about your environment:

• Cheroot version: 6.5.4
• CherryPy version: 18.1.0
• Python version: 3.6.7
• OS: Ubuntu 18.04.1 LTS
• Browser: all

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)

There is a reference RFC Draft for updating RFC6265 with SameSite Cookies

Suggested configuration option

tools.sessions.same_site

Possible Values:

• strict - prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. For example, for a GitHub-like website this would mean that if a logged-in user follows a link to a private GitHub project posted on a corporate discussion forum or email, GitHub will not receive the session cookie and the user will not be able to access the project.
• lax - provides a reasonable balance between security and usability for websites that want to maintain user’s logged-in session after the user arrives from an external link. In the above GitHub scenario, the session cookie would be allowed when following a regular link from an external website while blocking it in CSRF-prone request methods (e.g. POST).

If the option is not set, the feature will be disabled and the SameSite parameter won’t be set on the session cookie at all.

Sample Usage:

cherrypy.quickstart(AwesomeWebApp(), '/', config={
        'global':
        {
            'server.socket_host': "0.0.0.0",
            'log.screen': True,
            'error_page.default': error_page
        },
        '/':
        {
            'request.show_tracebacks': True,
            'tools.sessions.on': True,
            'tools.sessions.name': 'AwesomeWebApp',
            'tools.sessions.clean_freq': 5,
            'tools.sessions.timeout': 300,
            'tools.sessions.persistent': False,
            'tools.sessions.httponly': True,
            'tools.sessions.secure': False,
            'tools.sessions.same_site': 'strict'
})

Currently we can set this manually when creating a regular cookie, but this feature request specifically adresses the support for this feature on the standard cherrypy sessions tool.

** [2020-06-03] Changed the suggested configuration option to same_site using snake_case as suggested by @webknjaz and added more reference links

[ygbr]

Hey @ygbr, I like the idea and I’d accept a PR implementing it (please make sure to also include tests!).

The only suggestion I have is to use snake_case for the setting:

tools.sessions.samesite
tools.sessions.same_site

Hi @webknjaz, I have applied the changes you suggested using snake_case and will write some tests for samesite before submitting the PR.

While at it I’ve hit a snag and would like your guidance on how to proceed.

Since cherrypy uses Python http.cookies.SimpleCookie for cookie handling on _cprequest, those cookies are created based on the http.cookies.BaseCookie which values are dict-like objects derived from http.cookies.Morsel The problem is that Python versions prior to 3.8 don’t have the samesite attribute since this feature was introduced in the Cookies Morsel objects only on 3.8.

IMHO there are 2 approaches which we can explore:

1. Disable this feature on Python versions lower than 3.8 which we can do either by checking the Python version or by checking if the Morsel has the samesite reserved key using http.cookies.Morsel().isReservedKey("samesite")
2. For Python versions that return False on isReservedKey(“samesite”), I have found an approach to inject the samesite reserved key on the Morsel by using: http.cookies.Morsel._reserved['samesite'] = 'SameSite' which changes the Morsel to accept the new samesite key under older Python versions

While the 1st approach seems cleaner, it may lead to users thinking they have enabled SameSite unless we give some kind of failure or warning to developers using this feature on older Python versions.

The 2nd approach kinda solves it but it does change the Morsel object which I’m not sure if it is a risk we are willing to take or if it brings any kind of race condition or security problems.

Follows some links regarding this problem found on other projects:

• https://github.com/bottlepy/bottle/issues/982#issuecomment-315064376
• https://github.com/django/django/pull/8380
• https://github.com/pallets/werkzeug/pull/1550/files (maybe relevant for creating tests, although they don’t use http.cookies)
• https://github.com/encode/starlette/pull/732/files
• https://github.com/python/cpython/pull/6413/files

[survtur]

@ygbr, could you please explain how to add it to cookie from my own code without making any changes in existing cherrypy modules?