Django 中的 Web 安全手段

今天我们来简单聊一下在 Django 中针对常见的 Web 攻击手段做了哪些必要的防护措施，以及接下来我们在 Django 项目开发中需要注意哪些安全知识，避免给项目挖坑。

1. 深入 Django 中 CSRF 校验过程

上一节中提到了，针对 CSRF 攻击有效的解决方案是在网页上添加一个随机的校验 token 值，我们前面的登录的模板页面中添加的 {% csrf_token %}，这里正好对应着一个随机值。我们拿之前的登录表单来进行观察，会发现这样几个现象：

网页上隐藏的 csrf_token 值会在每次刷新时变化；
对应在请求和响应头部的 cookie 中的 csrftoken值却一直不变；

图片描述

这样子我们对应会产生几个思考问题：

为什么网页上的 token 值会变，而 cookie 中的 token 则一直不变？
整个 token 的校验过程是怎样的，有密码？如果有密码，密码存在哪里？

今天我们会带着这两个问题，查看下 Django 内部源码，找到这些问题的代码位置。我可能不会很完整的描述整个代码运行的逻辑，因为篇幅不够，而且细节太多，容易迷失在代码的海洋里。首先毋庸置疑的第一步是找我们在 settings.py 中设置的 CSRF 中间件：

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

我们在上一讲中提到过中间件类的两个函数：process_request() 和 process_response()。而在 CSRF 中间件文件中还有一个方法：process_view()。中间类比较完整的处理流程示意图如下所示，可以看到中间件的 process_view() 方法如果返回 None，则会执行下一个中间件的 process_view() 方法。一旦它返回 HttpResponse 实例，则直接跳过视图函数到达最后一个中间件的 process_response() 方法中。

图片描述

我们来关注下 django.middleware 目录下的 csrf.py 文件，所有的答案都在这里可以找到。首先看最核心的中间件类：

# 源码位置：django/middleware/csrf.py

# ...

class CsrfViewMiddleware(MiddlewareMixin):
    def \_accept(self, request):
        # Avoid checking the request twice by adding a custom attribute to
        # request. This will be relevant when both decorator and middleware
        # are used.
        request.csrf_processing_done = True
        return None
    
    def \_reject(self, request, reason):
        response = _get_failure_view()(request, reason=reason)
        log_response(
            'Forbidden (%s): %s', reason, request.path,
            response=response,
            request=request,
            logger=logger,
        )
        return response
    
    def \_get\_token(self, request):
        # ...
        
    def \_set\_token(self, request, response):
        # ...
    
    def process\_request(self, request):
        csrf_token = self._get_token(request)
        if csrf_token is not None:
            # Use same token next time.
            request.META['CSRF\_COOKIE'] = csrf_token
    
    def process\_view(self, request, callback, callback_args, callback_kwargs):
        if getattr(request, 'csrf\_processing\_done', False):
            return None

        # Wait until request.META["CSRF\_COOKIE"] has been manipulated before
        # bailing out, so that get\_token still works
        if getattr(callback, 'csrf\_exempt', False):
            return None

        # Assume that anything not defined as 'safe' by RFC7231 needs protection
        if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
            if getattr(request, '\_dont\_enforce\_csrf\_checks', False):
                # Mechanism to turn off CSRF checks for test suite.
                # It comes after the creation of CSRF cookies, so that
                # everything else continues to work exactly the same
                # (e.g. cookies are sent, etc.), but before any
                # branches that call reject().
                return self._accept(request)

            # 判断是不是 https 协议，不然不用执行这里
            if request.is_secure():
                # ...

            csrf_token = request.META.get('CSRF\_COOKIE')
            if csrf_token is None:
                # No CSRF cookie. For POST requests, we insist on a CSRF cookie,
                # and in this way we can avoid all CSRF attacks, including login
                # CSRF.
                return self._reject(request, REASON_NO_CSRF_COOKIE)

            # Check non-cookie token for match.
            request_csrf_token = ""
            if request.method == "POST":
                try:
                    request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
                except IOError:
                    # Handle a broken connection before we've completed reading
                    # the POST data. process\_view shouldn't raise any
                    # exceptions, so we'll ignore and serve the user a 403
                    # (assuming they're still listening, which they probably
                    # aren't because of the error).
                    pass

            if request_csrf_token == "":
                # Fall back to X-CSRFToken, to make things easier for AJAX,
                # and possible for PUT/DELETE.
                request_csrf_token = request.META.get(settings.CSRF_HEADER_NAME, '')

            request_csrf_token = _sanitize_token(request_csrf_token)
            if not _compare_salted_tokens(request_csrf_token, csrf_token):
                return self._reject(request, REASON_BAD_TOKEN)

        return self._accept(request)
        
    def process\_response(self, request, response):
        if not getattr(request, 'csrf\_cookie\_needs\_reset', False):
            if getattr(response, 'csrf\_cookie\_set', False):
                return response

        if not request.META.get("CSRF\_COOKIE\_USED", False):
            return response

        # Set the CSRF cookie even if it's already set, so we renew
        # the expiry timer.
        self._set_token(request, response)
        response.csrf_cookie_set = True
        return response

这里比较复杂的部分就是 process_view() 方法。process_request() 方法只是从请求头中取出 csrftoken 值或者生成一个 csrftoken 值放到 request.META 属性中去；process_response() 会设置对应的 csrftoken 值到 cookie 或者 session 中去。这里获取 csrftoken 和设置 csrftoken 调用的正是 _get_token() 和 set_token()方法：

class CsrfViewMiddleware(MiddlewareMixin):
    # ...
    def \_get\_token(self, request):
        if settings.CSRF_USE_SESSIONS:
            try:
                return request.session.get(CSRF_SESSION_KEY)
            except AttributeError:
                raise ImproperlyConfigured(
                    'CSRF\_USE\_SESSIONS is enabled, but request.session is not '
                    'set. SessionMiddleware must appear before CsrfViewMiddleware '
                    'in MIDDLEWARE%s.' % ('\_CLASSES' if settings.MIDDLEWARE is None else '')
                )
        else:
            try:
                cookie_token = request.COOKIES[settings.CSRF_COOKIE_NAME]
            except KeyError:
                return None

            csrf_token = _sanitize_token(cookie_token)
            if csrf_token != cookie_token:
                # Cookie token needed to be replaced;
                # the cookie needs to be reset.
                request.csrf_cookie_needs_reset = True
            return csrf_token

    def \_set\_token(self, request, response):
        if settings.CSRF_USE_SESSIONS:
            if request.session.get(CSRF_SESSION_KEY) != request.META['CSRF\_COOKIE']:
                request.session[CSRF_SESSION_KEY] = request.META['CSRF\_COOKIE']
        else:
            response.set_cookie(
                settings.CSRF_COOKIE_NAME,
                request.META['CSRF\_COOKIE'],
                max_age=settings.CSRF_COOKIE_AGE,
                domain=settings.CSRF_COOKIE_DOMAIN,
                path=settings.CSRF_COOKIE_PATH,
                secure=settings.CSRF_COOKIE_SECURE,
                httponly=settings.CSRF_COOKIE_HTTPONLY,
                samesite=settings.CSRF_COOKIE_SAMESITE,
            )
            # Set the Vary header since content varies with the CSRF cookie.
            patch_vary _headers(response, ('Cookie',))
    # ...

如果我们没在 settings.py 中设置 CSRF_USE_SESSIONS 值时，在 django/conf/global_settings.py 默认设置为 False，那么我们就是调用前面熟悉的 response.set_cookie() 方法取设置 cookie 中的 key-value 值，也是我们在上面第二张图片所看到的 Set-Cookie 里面的值。

我们来看最核心的处理方法：process_view()。它的执行流程如下所列，略有删减，请仔细研读和对照代码：

判断视图方法是否有 csrf_exempt 属性。相当于该视图方法添加了 @csrf_exempt 装饰器，这样不用检验 csrf_token 值，直接返回 None，进入下面的中间件执行，直到视图函数去处理 HTTP 请求；
对于 GET、HEAD、 OPTIONS、 TRACE 这四种请求不用检查 csrf_token，会直接跳到最后执行 self._accept(request) 方法。但是我们常用的如 POST、PUT 以及 DELETE 等请求会进行特别的处理；

来看针对 POST、PUT 以及 DELETE 的特殊处理，要注意两处代码：

request_csrf_token 值的获取：对于 POST 请求，我们要从请求参数中获取，这个值正是表单中隐藏的随机 csrf_token，也是我们在第一张图中看到的值，每次请求都会刷新该值；而且对于其它的请求，该值则是从 request.META 中获取；
校验 csrf_token 值是否正确。如果是不正确的 csrf_token 值，则会直接返回 403 错误；

if not _compare_salted_tokens(request_csrf_token, csrf_token):
    return self._reject(request, REASON_BAD_TOKEN)

可以看到，这里校验的是两个值：一个是我们从 cookie 中获取的，另一个是前端表单中隐藏的那个随机数。

现在我们大致心里有个数了，Django 的校验方法竟然是用 cookie 中的值和页面上的随机值进行校验，这两个值都是64位的，你必须同时拿到这两个正确 token 值才能通过 Django 的 csrf 中间件校验。

比较原理，2个 token，一个放到 cookie 中，另一个放到表单中，会一直变得那种。接下来就是对这两个 token 进行对比。我们继续追踪 _compare_salted_tokens() 方法，可以在 csrf.py 中找到如下两个方法，它们分别对应着 csrf_token 值的生成和解码：

# 源码位置：django/middleware/csrf.py
# ...

def \_salt\_cipher\_secret(secret):
    """
 Given a secret (assumed to be a string of CSRF\_ALLOWED\_CHARS), generate a
 token by adding a salt and using it to encrypt the secret.
 """
    salt = _get_new_csrf_string()
    chars = CSRF_ALLOWED_CHARS
    pairs = zip((chars.index(x) for x in secret), (chars.index(x) for x in salt))
    cipher = ''.join(chars[(x + y) % len(chars)] for x, y in pairs)
    return salt + cipher


def \_unsalt\_cipher\_token(token):
    """
 Given a token (assumed to be a string of CSRF\_ALLOWED\_CHARS, of length
 CSRF\_TOKEN\_LENGTH, and that its first half is a salt), use it to decrypt
 the second half to produce the original secret.
 """
    salt = token[:CSRF_SECRET_LENGTH]
    token = token[CSRF_SECRET_LENGTH:]
    chars = CSRF_ALLOWED_CHARS
    pairs = zip((chars.index(x) for x in token), (chars.index(x) for x in salt))
    secret = ''.join(chars[x - y] for x, y in pairs)  # Note negative values are ok
    return secret

# ...

来看这两个函数，首先是 _salt_cipher_secret() 方法，需要传入一个长度为 32 的 secret，就可以得到一个64位的随机字符。这个 secret 值在使用时也是随机生成的32个字符：

# 源码位置：django/middleware/csrf.py
def \_get\_new\_csrf\_string():
    return get_random_string(CSRF_SECRET_LENGTH, allowed_chars=CSRF_ALLOWED_CHARS)

# 源码位置：django/utils/crypto.py
def get\_random\_string(length=12,
                      allowed_chars='abcdefghijklmnopqrstuvwxyz'
                                    'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'):
    """
 Return a securely generated random string.

 The default length of 12 with the a-z, A-Z, 0-9 character set returns
 a 71-bit value. log\_2((26+26+10)^12) =~ 71 bits
 """
    if not using_sysrandom:
        # This is ugly, and a hack, but it makes things better than
        # the alternative of predictability. This re-seeds the PRNG
        # using a value that is hard for an attacker to predict, every
        # time a random string is required. This may change the
        # properties of the chosen random sequence slightly, but this
        # is better than absolute predictability.
        random.seed(
            hashlib.sha256(
                ('%s%s%s' % (random.getstate(), time.time(), settings.SECRET_KEY)).encode()
            ).digest()
        )
    return ''.join(random.choice(allowed_chars) for i in range(length))

在 _salt_cipher_secret() 方法中我们可以看到，传入32位的密钥 secret，最后的 csrf_token 的生成是 salt + cipher，前32位是 salt，后32位是加密字符串。解密的过程差不多就是 _salt_cipher_secret() 的逆过程了，最后得到 secret。我们可以在 Django 的 shell 模式下使用下这两个函数：

(django-manual) [root@server first_django_app]# python manage.py shell
Python 3.8.1 (default, Dec 24 2019, 17:04:00) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.middleware.csrf import _get_new_csrf_token, _unsalt_cipher_token
>>> x1 = _get_new_csrf_token()
>>> x2 = _get_new_csrf_token()
>>> x3 = _get_new_csrf_token()
>>> print('x1={}\nx2={}\nx3={}'.format(x1, x2, x3))
x1=dvK3CRLiyHJ6Xgt0B6eZ7kUjxXgZ5CKkhl8HbHq8CKR0ZXMOxYnigzDTIZIdk3xZ
x2=TMazqRDst3BSiyxIAI1XDiFKdbmxu8nKRVvMogERiZi6IG6KNhDSxcgEOPTqU0qF
x3=gy998wPOCZJiXHo7HYQtY3dfwaevPHKAs2YXPAeJmWUaA5vV2xdXqvlidLR4XM1T
>>> _unsalt_cipher_token(x1)
'e0yOJ0P0edi4cRtY62jtjpTKlcCopBXP'
>>> _unsalt_cipher_token(x2)
'8jvn8zbzZ6RoAiJcnJM544L4LOH3A2d5'
>>> _unsalt_cipher_token(x3)
'mEZYRez5U7l2NyhYvJxECCidRLNJifrt'
>>> 

了解了上述这些方法后，现在来思考前面提出的问题：为什么每次刷新表单中的 csrf_token 值会一直变化，而 cookie 中的 csrf_token 值却一直不变呢？首先我们看在页面上生成随机 token 值的代码，也就是将标签 {{ csrf_token }} 转成 64位随机码的地方：

# 源码位置： django/template/defaulttags.py

@register.tag
def csrf\_token(parser, token):
    return CsrfTokenNode()

class CsrfTokenNode(Node):
    def render(self, context):
        csrf_token = context.get('csrf\_token')
        if csrf_token:
            if csrf_token == 'NOTPROVIDED':
                return format_html("")
            else:
                return format_html('<input type="hidden" name="csrfmiddlewaretoken" value="{}">', csrf_token)
        else:
            # It's very probable that the token is missing because of
            # misconfiguration, so we raise a warning
            if settings.DEBUG:
                warnings.warn(
                    "A {% csrf\_token %} was used in a template, but the context "
                    "did not provide the value. This is usually caused by not "
                    "using RequestContext."
                )
            return ''

可以看到 csrf_token 值是从 context 中取出来的，而在 context 中的 csrf_token 值又是由如下代码生成的：

# 源码位置：django/template/context\_processors.py

from django.middleware.csrf import get_token

# ...

def csrf(request):
    """
 Context processor that provides a CSRF token, or the string 'NOTPROVIDED' if
 it has not been provided by either a view decorator or the middleware
 """
    def \_get\_val():
        token = get_token(request)
        if token is None:
            # In order to be able to provide debugging info in the
            # case of misconfiguration, we use a sentinel value
            # instead of returning an empty dict.
            return 'NOTPROVIDED'
        else:
            return token

    return {'csrf\_token': SimpleLazyObject(_get_val)}

可以看到，最后 csrf_token 值还是由 csrf.py 文件中的 get_token() 方法生成的。来继续看这个 get_token() 方法的代码：

# 源码位置：django/middleware/csrf.py

def get\_token(request):
    """
 Return the CSRF token required for a POST form. The token is an
 alphanumeric value. A new token is created if one is not already set.

 A side effect of calling this function is to make the csrf\_protect
 decorator and the CsrfViewMiddleware add a CSRF cookie and a 'Vary: Cookie'
 header to the outgoing response. For this reason, you may need to use this
 function lazily, as is done by the csrf context processor.
 """
    if "CSRF\_COOKIE" not in request.META:
        csrf_secret = _get_new_csrf_string()
        request.META["CSRF\_COOKIE"] = _salt_cipher_secret(csrf_secret)
    else:
        csrf_secret = _unsalt_cipher_token(request.META["CSRF\_COOKIE"])
    request.META["CSRF\_COOKIE\_USED"] = True
    return _salt_cipher_secret(csrf_secret)

注意！注意！最关键的地方来了，这个加密的 secret 的值是从哪里来的？正是从请求头中的 cookie 信息中来的，如果没有将生成一个新的密钥，接着把该密钥生成的 token 放到 cookie 中。最后使用 _salt_cipher_secret() 方法生成的 csrf_token 和 cookie 中的 csrf_token 具有相同的密钥。同时拿到了这两个值，就可以进行校验和判断，下面我们在 `\_salt\_cipher\_secret()方法中加上一个print() 语句，然后执行下看看是否如我们所说。

Django 中的 Web 安全手段

1. 深入 Django 中 CSRF 校验过程​

1. 深入 Django 中 CSRF 校验过程