diff options
| -rw-r--r-- | CONTRIBUTORS.txt | 2 | ||||
| -rw-r--r-- | docs/narr/sessions.rst | 33 |
2 files changed, 23 insertions, 12 deletions
diff --git a/CONTRIBUTORS.txt b/CONTRIBUTORS.txt index a56821e74..593a078f2 100644 --- a/CONTRIBUTORS.txt +++ b/CONTRIBUTORS.txt @@ -326,3 +326,5 @@ Contributors - Jason Williams, 2018/06/11 - Benjamin Gmurczyk, 2018/06/14 + +- Stephen Martin, 2018/09/04 diff --git a/docs/narr/sessions.rst b/docs/narr/sessions.rst index 6c88dcec5..6f826fe23 100644 --- a/docs/narr/sessions.rst +++ b/docs/narr/sessions.rst @@ -57,18 +57,27 @@ using the :meth:`pyramid.config.Configurator.set_session_factory` method. .. warning:: By default the :func:`~pyramid.session.SignedCookieSessionFactory` - implementation is *unencrypted*. You should not use it when you keep - sensitive information in the session object, as the information can be - easily read by both users of your application and third parties who have - access to your users' network traffic. And, 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. 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", and you are sure your application has no - cross-site scripting vulnerabilities. + implementation contains the following security concerns: + + - Session data is *unencrypted*. You should not use it when you keep + sensitive information in the session object, as the information can be + 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. + + - The default serialization method, while replacable 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. .. index:: single: session object |