Skip to content
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

Another rewrite of security concerns with SignedCookieSessionFactory #3341

Closed
wants to merge 1 commit into from
Closed
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
17 changes: 13 additions & 4 deletions docs/narr/sessions.rst
Original file line number Diff line number Diff line change
Expand Up @@ -64,20 +64,29 @@ using the :meth:`pyramid.config.Configurator.set_session_factory` method.
easily read by both users of your application and third parties who have
access to your users' network traffic.

- If you use this sessioning implementation, and you inadvertently create a
cross-site scripting vulnerability in your application, because the
session data is stored unencrypted in a cookie, it will also be easier for
evildoers to obtain the current user's cross-site scripting token.
To avoid this vulnerability, use TLS to encrypt the network traffic, making it unreadable by third parties.

- If you use this session implementation and you inadvertently create a
cross-site scripting vulnerability in your application, it will be easier for
evildoers to obtain the current user's cross-site scripting token, because the
session data is stored unencrypted in a cookie.

To avoid this vulnerability, set the argument ``httponly=True`` in the function :func:`~pyramid.session.SignedCookieSessionFactory`, which will hide the cookie from JavaScript.

In general cross-site scripting will have full access to the page in question.
If there is a form with a CSRF token as a form component on the page, then the token can already be stolen and stealing the cookie is unnecessary.

- The default serialization method, while replaceable with something like
JSON, is implemented using pickle which can lead to remote code execution
if your secret key is compromised.


In short, use a different session factory implementation (preferably one
which keeps session data on the server) for anything but the most basic of
applications where "session security doesn't matter", you are sure your
application has no cross-site scripting vulnerabilities, and you are confident
your secret key will not be exposed.
Most importantly, always use TLS to encrypt network traffic.

.. index::
single: session object
Expand Down