summaryrefslogtreecommitdiff
path: root/docs/topics/http
diff options
context:
space:
mode:
authorAlex Gaynor <alex.gaynor@gmail.com>2013-11-24 21:05:59 -0600
committerAlex Gaynor <alex.gaynor@gmail.com>2013-11-24 21:05:59 -0600
commit4e07d93325b3989073b181e4505f2e6ed707743b (patch)
tree3d903b4026b4f851d169ad09478c7a7fdce0b795 /docs/topics/http
parenteb38257e5199ca06b8b32f82dd50f64fd6b0d98d (diff)
Fixed some unnescesarily gendered language in the docs
Diffstat (limited to 'docs/topics/http')
-rw-r--r--docs/topics/http/sessions.txt6
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index abc99800dd..d39b8344c6 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -330,7 +330,7 @@ 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 (there isn't an inherent vulnerability in Django that
-would cause it to leak), the attacker could insert a string into his session
+would cause it to leak), the attacker could insert a string into their 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
@@ -659,8 +659,8 @@ domain. This makes session fixation possible if all subdomains are not
controlled by trusted users (or, are at least unable to set cookies).
For example, an attacker could log into ``good.example.com`` and get a valid
-session for his account. If the attacker has control over ``bad.example.com``,
-he can use it to send his session key to you since a subdomain is permitted
+session for their account. If the attacker has control over ``bad.example.com``,
+they can use it to send their session key to you since a subdomain is permitted
to set cookies on ``*.example.com``. When you visit ``good.example.com``,
you'll be logged in as the attacker and might inadvertently enter your
sensitive personal data (e.g. credit card info) into the attackers account.