mirror of
				https://github.com/django/django.git
				synced 2025-10-31 09:41:08 +00:00 
			
		
		
		
	Fixed #21002 -- Documented JSON session serialization requires string keys
Thanks jeroen.pulles at redslider.net for the report.
This commit is contained in:
		| @@ -745,7 +745,8 @@ Default session serialization switched to JSON | ||||
| Historically, :mod:`django.contrib.sessions` used :mod:`pickle` to serialize | ||||
| session data before storing it in the backend. If you're using the :ref:`signed | ||||
| cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is | ||||
| known by an attacker, the attacker could insert a string into his session | ||||
| known by an attacker (there isn't an inherent vulnerability in Django that | ||||
| would cause it to leak), the attacker could insert a string into his session | ||||
| which, when unpickled, executes arbitrary code on the server. The technique for | ||||
| doing so is simple and easily available on the internet. Although the cookie | ||||
| session storage signs the cookie-stored data to prevent tampering, a | ||||
| @@ -759,7 +760,9 @@ For backwards compatibility, this setting defaulted to using :mod:`pickle` | ||||
| in Django 1.5.3, but we've changed the default to JSON in 1.6. If you upgrade | ||||
| and switch from pickle to JSON, sessions created before the upgrade will be | ||||
| lost. While JSON serialization does not support all Python objects like | ||||
| :mod:`pickle` does, we highly recommend using JSON-serialized sessions. See the | ||||
| :mod:`pickle` does, we highly recommend using JSON-serialized sessions. Also, | ||||
| as JSON requires string keys, you will likely run into problems if you are | ||||
| using non-string keys in ``request.session``. See the | ||||
| :ref:`session_serialization` documentation for more details. | ||||
|  | ||||
| Miscellaneous | ||||
|   | ||||
| @@ -314,7 +314,8 @@ Session serialization | ||||
| Before version 1.6, Django defaulted to using :mod:`pickle` to serialize | ||||
| session data before storing it in the backend. If you're using the :ref:`signed | ||||
| cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is | ||||
| known by an attacker, the attacker could insert a string into his session | ||||
| known by an attacker (there isn't an inherent vulnerability in Django that | ||||
| would cause it to leak), the attacker could insert a string into his session | ||||
| which, when unpickled, executes arbitrary code on the server. The technique for | ||||
| doing so is simple and easily available on the internet. Although the cookie | ||||
| session storage signs the cookie-stored data to prevent tampering, a | ||||
| @@ -338,8 +339,21 @@ Bundled Serializers | ||||
| .. class:: serializers.JSONSerializer | ||||
|  | ||||
|     A wrapper around the JSON serializer from :mod:`django.core.signing`. Can | ||||
|     only serialize basic data types. See the :ref:`custom-serializers` section | ||||
|     for more details. | ||||
|     only serialize basic data types. | ||||
|  | ||||
|     In addition, as JSON supports only string keys, note that using non-string | ||||
|     keys in ``request.session`` won't work as expected:: | ||||
|  | ||||
|         >>> # initial assignment | ||||
|         >>> request.session[0] = 'bar' | ||||
|         >>> # subsequent requests following serialization & deserialization | ||||
|         >>> # of session data | ||||
|         >>> request.session[0]  # KeyError | ||||
|         >>> request.session['0'] | ||||
|         'bar' | ||||
|  | ||||
|     See the :ref:`custom-serializers` section for more details on limitations | ||||
|     of JSON serialization. | ||||
|  | ||||
| .. class:: serializers.PickleSerializer | ||||
|  | ||||
|   | ||||
		Reference in New Issue
	
	Block a user