Python中的十个安全陷阱(二)

6. 不完整的正则表达式匹配

正则表达式（regex）是大多数 Web 程序不可或缺的一部分。我们经常能看到它被自定义的 Web 应用防火墙（WAF，Web Application Firewalls）用来作输入验证，例如检测恶意字符串。在 Python 中，re.match 和 re.search 之间有着细微的区别，我们将在下面的代码片段中演示。

def is_sql_injection(request):
    pattern = re.compile(r".*(union)|(select).*")
    name_to_test = request.GET['name']
    if re.search(pattern, name_to_test):
        return True
    return False

在第 2 行中，我们定义了一个匹配 union 或者 select 的模式，以检测可能的 SQL 注入。这是一个糟糕的写法，因为你可以轻易地绕过这些黑名单，但我们已经在线上的程序中见过它。在第 4 行中，函数 re.match 使用前面定义好的模式，检查第 3 行中的用户输入内容是否包含这些恶意的值。

然而，与 re.search 函数不同的是，re.match 函数不匹配新行。例如，如果攻击者提交了值 aaaaaa \n union select，这个输入就匹配不上正则表达式。因此，检查可以被绕过，失去保护作用。

总而言之，我们不建议使用正则表达式黑名单进行任何安全检查。

7. Unicode 清洗器绕过

Unicode 支持用多种形式来表示字符，并将这些字符映射到码点。在 Unicode 标准中，不同的 Unicode 字符有四种归一化方案。程序可以使用这些归一化方法，以独立于人类语言的标准方式来存储数据，例如用户名。

然而，攻击者可以利用这些归一化，这已经导致了 Python 的 urllib 出现漏洞（CVE-2019-9636）。下面的代码片段演示了一个基于 NFKC 归一化的跨站点脚本漏洞（XSS,Cross-Site Scripting）。

import unicodedata
from django.shortcuts import render
from django.utils.html import escape

def render_input(request):
    user_input = escape(request.GET['p'])
    normalized_user_input = unicodedata.normalize("NFKC", user_input)
    context = {'my_input': normalized_user_input}
    return render(request, 'test.html', context)

在第 6 行中，用户输入的内容被 Django 的 escape 函数处理了，以防止 XSS 漏洞。在第 7 行中，经过清洗的输入被 NFKC 算法归一化，以便在第 8-9 行中通过 test.html 模板正确地渲染。

templates/test.html

{{ my_input | safe}}

在模板 test.html 中，第 4 行的变量 my_input 被标记为安全的，因为开发人员预期有特殊字符，并且认为该变量已经被 escape 函数清洗了。通过标记关键字 safe, Django 不会再次对变量进行清洗。

但是，由于第 7 行（view.py）的归一化，字符“%EF%B9%A4”会被转换为“<”，“%EF%B9%A5”被转换为“>”。这导致攻击者可以注入任意的 HTML 标记，进而触发 XSS 漏洞。为了防止这个漏洞，就应该在把用户输入做完归一化之后，再进行清洗。

8. Unicode 编码碰撞

前文说过，Unicode 字符会被映射成码点。然而，有许多不同的人类语言，Unicode 试图将它们统一起来。这就意味着不同的字符很有可能拥有相同的“layout”。例如，小写的土耳其语 ı（没有点）的字符是英语中大写的 I。在拉丁字母中，字符 i 也是用大写的 I 表示。在 Unicode 标准中，这两个不同的字符都以大写形式映射到同一个码点。

这种行为是可以被利用的，实际上已经在 Django 中导致了一个严重的漏洞（CVE-2019-19844）。下面的代码是一个重置密码的示例。

from django.core.mail import send_mail
from django.http import HttpResponse
from vuln.models import User

def reset_pw(request):
    email = request.GET['email']
    result = User.objects.filter(email__exact=email.upper()).first()
    if not result:
        return HttpResponse("User not found!")
    send_mail('Reset Password','Your new pw: 123456.', '[e-mail]', [email], fail_silently=False)
    return HttpResponse("Password reset email send!")

第 6 行代码获取了用户输入的 email，第 7-9 行代码检查这个 email 值，查找是否存在具有该 email 的用户。如果用户存在，则第 10 行代码依据第 6 行中输入的 email 地址，给用户发送邮件。需要指出的是，第 7-9 行中对邮件地址的检查是不区分大小写的，使用了 upper 函数。

至于攻击，我们假设数据库中存在一个邮箱地址为 [e-mail] 的用户。那么，攻击者可以简单地传入 foo@mıx.com 作为第 6 行中的 email，其中 i 被替换为土耳其语 ı。第 7 行代码将邮箱转换成大写，结果是 [e-mail]。这意味着找到了一个用户，因此会发送一封重置密码的邮件。

然而，邮件被发送到第 6 行未转换的邮件地址，也就是包含了土耳其语的 ı。换句话说，其他用户的密码被发送到了攻击者控制的邮件地址。为了防止这个漏洞，可以将第 10 行替换成使用数据库中的用户邮箱。即使发生编码冲突，攻击者在这种情况下也得不到任何好处。

9. IP 地址归一化

在 Python < 3.8 中，IP 地址会被 ipaddress 库归一化，因此前缀的零会被删除。这种行为乍一看可能是无害的，但它已经在 Django 中导致了一个高严重性的漏洞（CVE-2021-33571）。攻击者可以利用归一化绕过校验程序，发起服务端请求伪造攻击（SSRF，Server-Side Request Forgery）。

下面的代码展示了如何绕过这样的校验器。

import requests
import ipaddress

def send_request(request):
    ip = request.GET['ip']
    try:
        if ip in ["127.0.0.1", "0.0.0.0"]:
            return HttpResponse("Not allowed!")
        ip = str(ipaddress.IPv4Address(ip))
    except ipaddress.AddressValueError:
        return HttpResponse("Error at validation!")
    requests.get('https://' + ip)
    return HttpResponse("Request send!")

第 5 行代码获取用户传入的一个 IP 地址，第 7 行代码使用一个黑名单来检查该 IP 是否为本地地址，以防止可能的 SSRF 漏洞。这份黑名单并不完整，仅作为示例。

第 9 行代码检查该 IP 是否为 IPv4 地址，同时将 IP 归一化。在完成验证后，第 12 行代码会对该 IP 发起实际的请求。

但是，攻击者可以传入 127.0.001 这样的 IP 地址，在第 7 行的黑名单列表中找不到。然后，第 9 行代码使用 ipaddress.IPv4Address 将 IP 归一化为 127.0.0.1。因此，攻击者就能够绕过 SSRF 校验器，并向本地网络地址发送请求。

10. URL 查询参数解析

在 Python < 3.7 中，urllib.parse.parse_qsl 函数允许使用“;”和“&”字符作为 URL 的查询变量的分隔符。有趣的是“;”字符不能被其它语言识别为分隔符。

在下面的例子中，我们将展示为什么这种行为会导致漏洞。假设我们正在运行一个基础设施，其中前端是一个 PHP 程序，后端则是一个 Python 程序。

攻击者向 PHP 前端发送以下的 GET 请求:

GET https://victim.com/?a=1;b=2

PHP 前端只识别出一个查询参数“a”，其内容为“1;b=2”。PHP 不把“;”字符作为查询参数的分隔符。现在，前端会将攻击者的请求直接转发给内部的 Python 程序:

GET https://internal.backend/?a=1;b=2

如果使用了 urllib.parse.parse_qsl，Python 程序会处理成两个查询参数，即“a=1”和“b=2”。这种查询参数解析的差异可能会导致致命的安全漏洞，比如 Django 中的 Web 缓存投毒漏洞（CVE-2021-23336）。

总结

我们介绍了 10 个 Python 安全陷阱，我们认为开发者不太了解它们。每个细微的陷阱都很容易被忽视，并在过去导致了线上程序的安全漏洞。

正如前文所述，安全陷阱可能出现在各种操作中，从处理文件、目录、压缩文件、URL、IP 到简单的字符串。一种常见的情况是库函数的使用，这些函数可能有意想不到的行为。这提醒我们一定要升级到最新版本，并仔细阅读文档。在 SonarSource 中，我们正在研究这些缺陷，以便将来不断改进我们的代码分析器。

审核编辑：汤梓红