Django的date过滤器与SQL时间注入

Django的date过滤器本身是安全的，但错误使用可能导致SQL时间注入漏洞。问题的核心在于开发者将未经处理的用户输入直接传递给date过滤器的format参数，而该参数支持strftime格式字符串。如果攻击者能够控制format参数，他们可以注入带有百分号（%）的格式代码，这些代码在数据库层面可能被解释为SQL通配符或操作符，结合时间延迟函数，就能构造出基于时间的盲注攻击。

理解date过滤器的工作原理与潜在风险

Django模板系统中的date过滤器用于格式化datetime对象，其语法为{{ value|date:"Y-m-d" }}。这里的format字符串遵循Python的strftime规范。在底层，Django会调用datetime对象的strftime方法进行格式化，这个过程通常在Python层面完成，与数据库无关。风险出现在一种特殊场景：当开发者将数据库查询结果（例如使用extra或RawSQL进行原始查询）直接传递给模板，并且允许用户控制format字符串时。例如，一个视图函数从GET请求中获取format参数，然后将其传递给模板上下文。

# 危险示例：用户输入直接传递给date过滤器
from django.shortcuts import render
import datetime

def my_view(request):
    user_format = request.GET.get('format', 'Y-m-d')  # 用户可控
    current_time = datetime.datetime.now()
    return render(request, 'template.html', {
        'current_time': current_time,
        'format_string': user_format  # 直接将用户输入作为格式字符串
    })

在模板中：{{ current_time|date:format_string }}。如果攻击者提交format=%Y-%m-%d' AND (SELECT 1 FROM pg_sleep(10))--，虽然date过滤器会因无效字符抛出异常，但真正的漏洞在于开发者可能错误地使用用户输入的format来构建原始SQL查询，而不是直接用于date过滤器。更常见的情况是，开发者混淆了模板格式化和数据库查询，将用户提供的strftime格式字符错误地拼接进使用extra()、RawSQL或直接执行cursor.execute()的SQL语句中，意图实现动态日期格式化。

SQL时间注入的攻击原理与构造

SQL时间注入是盲注的一种，攻击者通过观察数据库响应时间的差异来推断数据。假设一个存在漏洞的Django ORM查询如下：

# 错误地将用户输入用于原始SQL片段
format_input = request.GET.get('order_by', 'created_at')
# 本意可能是想按格式化后的日期排序，但错误地使用了原始SQL
query = MyModel.objects.extra(select={
    'formatted_date': "strftime('%%Y-%%m-%%d', created_at)"  # 注意：这里直接拼接了用户输入
})

如果开发者错误地将用户输入的format_input（例如%Y-%m-%d）直接替换到SQL字符串的strftime函数中，攻击者就可以注入恶意payload。例如，在SQLite中，攻击者可以提交：%Y-%m-%d') AND (SELECT CASE WHEN (1=1) THEN randomblob(100000000) ELSE NULL END)--。这将导致SQL语句变为：strftime('%Y-%m-%d') AND (SELECT CASE WHEN (1=1) THEN randomblob(100000000) ELSE NULL END)--', created_at)。如果条件为真，数据库会执行耗时的randomblob操作，导致响应延迟，从而验证漏洞存在。通过不断调整条件，攻击者可以逐位提取数据库信息。

安全使用date过滤器的核心准则

首要原则是：永远不要将用户输入直接作为date过滤器的format参数，除非经过严格的白名单验证。正确的做法是预先定义一组安全的格式字符串供用户选择。

# 安全做法：使用白名单
SAFE_DATE_FORMATS = {
    'short': 'Y-m-d',
    'long': 'Y年m月d日',
    'iso': 'Y-m-d H:i:s',
}

def safe_view(request):
    format_key = request.GET.get('format', 'short')
    format_string = SAFE_DATE_FORMATS.get(format_key, 'Y-m-d')  # 默认值
    # 然后将format_string传递给模板

其次，严格区分数据展示层（模板）和数据查询层（ORM/SQL）。所有数据库查询操作都应使用Django ORM的标准方法，或使用参数化查询。如果需要根据用户选择动态格式化日期，应在Python层面使用datetime.strftime处理后再传递给模板，或者将原始datetime对象和用户选择的格式键分别传递给模板，在模板中使用安全的date:format_key映射。

修复与防御：参数化查询与ORM的正确使用

如果业务逻辑确实需要在数据库层面进行日期格式化（例如为了排序或分组），必须使用参数化查询，而不是字符串拼接。Django的ORM对于大多数查询都是安全的，但使用extra()、raw()或cursor.execute()时需要格外小心。

# 使用Django ORM的注解功能，避免原始SQL
from django.db.models.functions import TruncDate
query = MyModel.objects.annotate(
    formatted_date=TruncDate('created_at')  # 使用数据库函数，但由ORM安全处理
).order_by('formatted_date')

# 如果必须使用原始SQL，务必使用参数化
from django.db import connection
user_format = '%Y-%m'  # 假设来自白名单
with connection.cursor() as cursor:
    cursor.execute("""
        SELECT id, strftime(%s, created_at) as fmt_date FROM myapp_mymodel
    """, [user_format])  # 参数化传递，%s会被安全转义

注意，即使使用参数化查询，传递给数据库strftime函数的格式字符串也应是来自白名单的常量，而不是用户自由输入。因为参数化查询只能防止SQL指令注入，不能防止函数参数本身的语义错误或潜在滥用（尽管通过时间函数进行攻击的可能性已大大降低）。

深入排查：代码审计与自动化测试

在现有项目中排查此类漏洞，应重点审查所有使用extra()、RawSQL、cursor.execute()的地方，以及任何将request.GET、request.POST参数直接传递给模板date过滤器或SQL字符串拼接的地方。可以搜索代码中的以下模式：".*date.*%s"、"strftime"、"DATE_FORMAT"（MySQL函数）。自动化安全测试工具如Bandit（针对Python代码）可以辅助发现一些简单的字符串拼接问题，但逻辑漏洞仍需人工复核。

编写针对性的单元测试也至关重要。模拟攻击者输入包含百分号和SQL片段的格式字符串，检查应用响应是否异常延迟，或是否返回了数据库错误信息。同时，确保在开发流程中集成安全代码审查。

总结：安全思维与最佳实践

Django的date过滤器不是SQL注入的根源，它只是一个模板工具。漏洞的根源是开发者在数据流控制上的疏忽，混淆了用户输入、业务逻辑和数据库操作的边界。安全开发的核心在于：输入验证（白名单优于黑名单）、查询参数化、最小权限原则（数据库连接使用低权限账户）和分层防御。记住，任何来自用户的数据，无论是用于日期格式、排序字段还是查询值，在进入数据库查询或敏感函数参数前，都必须经过严格的验证或映射。将展示格式的控制限制在应用层，尽可能避免在数据库查询中使用动态的、用户控制的格式字符串，是从根本上杜绝此类“时间注入”风险的最佳方法。

Django的date过滤器与SQL时间注入

服务指南

帮助中心