Python 开发者们在应用规范库和通用框架时,都认为本人的程序具备牢靠的安全性。然而,在 Python 中,就像在任何其它编程语言中一样,有一些个性可能会被开发者们误会或误用。通常而言,只有极少的奥妙之处或细节会使开发者们疏忽大意,从而在代码中引入重大的安全漏洞。
在这篇博文中,咱们将分享在理论 Python 我的项目中遇到的 10 个平安陷阱。咱们抉择了一些在技术圈中不太为人所知的陷阱。通过介绍每个问题及其造成的影响,咱们心愿进步人们对这些问题的感知,并进步大家的安全意识。如果你正在应用这些个性,请肯定要排查你的 Python 代码!
1. 被优化掉的断言
Python 反对以优化的形式执行代码。这使代码运行得更快,内存用得更少。当程序被大规模应用,或者可用的资源很少时,这种办法尤其无效。一些预打包的 Python 程序提供了优化的字节码。
然而,当代码被优化时,所有的 assert 语句都会被疏忽。开发者有时会应用它们来判断代码中的某些条件。例如,如果应用断言来作身份验证查看,则可能导致平安绕过。
def superuser_action(request, user):
assert user.is_super_user
# execute action as super user
在这个例子中,第 2 行中的 assert 语句将被疏忽,导致非超级用户也能够运行到下一行代码。不举荐应用 assert 语句进行平安相干的查看,但咱们的确在理论的我的项目中看到过它们。
2. MakeDirs 权限
os.makdirs
函数能够在操作系统中创立一个或多个文件夹。它的第二个参数 mode 用于指定创立的文件夹的默认权限。在上面代码的第 2 行中,文件夹 A/B/C 是用 rwx—— (0o700) 权限创立的。这意味着只有以后用户(所有者)领有这些文件夹的读、写和执行权限。
def init_directories(request):
os.makedirs("A/B/C", mode=0o700)
return HttpResponse("Done!")
在 Python < 3.6 版本中,创立出的文件夹 A、B 和 C 的权限都是 700。然而,在 Python > 3.6 版本中,只有最初一个文件夹 C 的权限为 700,其它文件夹 A 和 B 的权限为默认的 755。
因而,在 Python > 3.6 中,os.makdirs
函数等价于 Linux 的这条命令:mkdir -m 700 -p A/B/C
。有些开发者没有意识到版本之间的差别,这曾经在 Django 中造成了一个权限越级破绽(cve – 2022 -24583),独一无二,这在 WordPress 中也造成了一个加固绕过问题。
3. 绝对路径拼接
os.path.join(path, *paths)
函数用于将多个文件门路连接成一个组合的门路。第一个参数通常蕴含了根底门路,而之后的每个参数都被当做组件拼接到根底门路后。
然而,这个函数有一个少有人知的个性。如果拼接的某个门路以 / 结尾,那么包含根底门路在内的所有前缀门路都将被删除,该门路将被视为绝对路径。上面的示例揭示了开发者可能遇到的这个陷阱。
def read_file(request):
filename = request.POST['filename']
file_path = os.path.join("var", "lib", filename)
if file_path.find(".") != -1:
return HttpResponse("Failed!")
with open(file_path) as f:
return HttpResponse(f.read(), content_type='text/plain')
在第 3 行中,咱们应用 os.path.join 函数将用户输出的文件名结构出指标门路。在第 4 行中,查看生成的门路是否蕴含”.“,防止出现门路遍历破绽。
然而,如果攻击者传入的文件名参数为”/a/b/c.txt“,那么第 3 行失去的变量 file_path 会是一个绝对路径(/a/b/c.txt)。即 os.path.join 会疏忽掉”var/lib“局部,攻击者能够不应用“.”字符就读取到任何文件。只管 os.path.join 的文档中形容了这种行为,但这还是导致了许多破绽(Cuckoo Sandbox Evasion,CVE-2020-35736)。
4. 任意的临时文件
tempfile.NamedTemporaryFile
函数用于创立具备特定名称的临时文件。然而,prefix(前缀)和 suffix(后缀)参数很容易受到门路遍历攻打(Issue 35278)。如果攻击者管制了这些参数之一,他就能够在文件系统中的任意地位创立出一个临时文件。上面的示例揭示了开发者可能遇到的一个陷阱。
def touch_tmp_file(request):
id = request.GET['id']
tmp_file = tempfile.NamedTemporaryFile(prefix=id)
return HttpResponse(f"tmp file: {tmp_file} created!", content_type='text/plain')
在第 3 行中,用户输出的 id 被当作临时文件的前缀。如果攻击者传入的 id 参数是“/../var/www/test”,则会创立出这样的临时文件:/var/www/test_zdllj17。粗看起来,这可能是有害的,但它会为攻击者发明出开掘更简单的破绽的根底。
5. 扩大的 Zip Slip
在 Web 利用中,通常须要解压上传后的压缩文件。在 Python 中,很多人都晓得 TarFile.extractall 与 TarFile.extract 函数容易受到 Zip Slip 攻打。攻击者通过篡改压缩包中的文件名,使其蕴含门路遍历(../)字符,从而发动攻打。
这就是为什么压缩文件应该始终被视为不受信起源的起因。zipfile.extractall 与 zipfile.extract 函数能够对 zip 内容进行荡涤,从而避免这类门路遍历破绽。
然而,这并不意味着在 ZipFile 库中不会呈现门路遍历破绽。上面是一段解压缩文件的代码。
def extract_html(request):
filename = request.FILES['filename']
zf = zipfile.ZipFile(filename.temporary_file_path(), "r")
for entry in zf.namelist():
if entry.endswith(".html"):
file_content = zf.read(entry)
with open(entry, "wb") as fp:
fp.write(file_content)
zf.close()
return HttpResponse("HTML files extracted!")
第 3 行代码依据用户上传文件的长期门路,创立出一个 ZipFile 处理器。第 4 – 8 行代码将所有以“.html”结尾的压缩项提取进去。第 4 行中的 zf.namelist 函数会取到 zip 内压缩项的名称。留神,只有 zipfile.extract 与 zipfile.extractall 函数会对压缩项进行荡涤,其它任何函数都不会。
在这种状况下,攻击者能够创立一个文件名,例如“../../../var/www/html”,内容随便填。该歹意文件的内容会在第 6 行被读取,并在第 7-8 行写入被攻击者管制的门路。因而,攻击者能够在整个服务器上创立任意的 HTML 文件。
如上所述,压缩包中的文件应该被看作是不受信赖的。如果你不应用 zipfile.extractall 或者 zipfile.extract,你就必须对 zip 内文件的名称进行“消毒”,例如应用 os.path.basename。否则,它可能导致重大的安全漏洞,就像在 NLTK Downloader(CVE-2019-14751)中发现的那样。
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
<!DOCTYPE html>
<html lang="en">
<body>
{{my_input | safe}}
</body>
</html>
在模板 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.', 'from@example.com', [email], fail_silently=False)
return HttpResponse("Password reset email send!")
第 6 行代码获取了用户输出的 email,第 7-9 行代码查看这个 email 值,查找是否存在具备该 email 的用户。如果用户存在,则第 10 行代码根据第 6 行中输出的 email 地址,给用户发送邮件。须要指出的是,第 7-9 行中对邮件地址的查看是不辨别大小写的,应用了 upper 函数。
至于攻打,咱们假如数据库中存在一个邮箱地址为 foo@mix.com 的用户。那么,攻击者能够简略地传入 foo@mıx.com 作为第 6 行中的 email,其中 i 被替换为土耳其语 ı。第 7 行代码将邮箱转换成大写,后果是 FOO@MIX.COM。这意味着找到了一个用户,因而会发送一封重置明码的邮件。
然而,邮件被发送到第 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 中,咱们正在钻研这些缺点,以便未来不断改进咱们的代码分析器。
如果你感觉文章还不错,欢送关注公众号:Python 编程学习圈 ,或是返回编程学习网,理解更多编程技术常识,还有大量干货学习材料能够支付!