Merge pull request #3340 from stloma/pickle_warning

clarify session factory warnings

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..2d80b1a63 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 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.
 
 .. index::
    single: session object