警惕！Python 中少為人知的 10 個安全陷阱！

作者：Dennis Brinkrolf

譯者：豌豆花下貓@Python貓

原題：10 Unknown Security Pitfalls for Python

英文：https://blog.sonarsource.com/10-unknown-security-pitfalls-for-python

Python 開發(fā)者們在使用標準庫和通用框架時，都以為自己的程序具有可靠的安全性。然而，在 Python 中，就像在任何其它編程語言中一樣，有一些特性可能會被開發(fā)者們誤解或誤用。通常而言，只有極少的微妙之處或細節(jié)會使開發(fā)者們疏忽大意，從而在代碼中引入嚴重的安全漏洞。

在這篇博文中，我們將分享在實際 Python 項目中遇到的 10 個安全陷阱。我們選擇了一些在技術(shù)圈中不太為人所知的陷阱。通過介紹每個問題及其造成的影響，我們希望提高人們對這些問題的感知，并提高大家的安全意識。如果你正在使用這些特性，請一定要排查你的 Python 代碼！

1.被優(yōu)化掉的斷言

Python 支持以優(yōu)化的方式執(zhí)行代碼。這使代碼運行得更快，內(nèi)存用得更少。當程序被大規(guī)模使用，或者可用的資源很少時，這種方法尤其有效。一些預(yù)打包的 Python 程序提供了優(yōu)化的字節(jié)碼。

然而，當代碼被優(yōu)化時，所有的 assert 語句都會被忽略。開發(fā)者有時會使用它們來判斷代碼中的某些條件。例如，如果使用斷言來作身份驗證檢查，則可能導(dǎo)致安全繞過。

def?superuser_action(request,?user):
????assert?user.is_super_user
????#?execute?action?as?super?user

在這個例子中，第 2 行中的 assert 語句將被忽略，導(dǎo)致非超級用戶也可以運行到下一行代碼。不推薦使用 assert 語句進行安全相關(guān)的檢查，但我們確實在實際的項目中看到過它們。

2. MakeDirs 權(quán)限

os.makdirs 函數(shù)可以在操作系統(tǒng)中創(chuàng)建一個或多個文件夾。它的第二個參數(shù) mode 用于指定創(chuàng)建的文件夾的默認權(quán)限。在下面代碼的第 2 行中，文件夾 A/B/C 是用 rwx------ (0o700) 權(quán)限創(chuàng)建的。這意味著只有當前用戶（所有者）擁有這些文件夾的讀、寫和執(zhí)行權(quán)限。

def?init_directories(request):
????os.makedirs("A/B/C",?mode=0o700)
????return?HttpResponse("Done!")

在 Python < 3.6 版本中，創(chuàng)建出的文件夾 A、B 和 C 的權(quán)限都是 700。但是，在 Python > 3.6 版本中，只有最后一個文件夾 C 的權(quán)限為 700，其它文件夾 A 和 B 的權(quán)限為默認的 755。

因此，在 Python > 3.6 中，os.makdirs 函數(shù)等價于 Linux 的這條命令：mkdir -m 700 -p A/B/C。有些開發(fā)者沒有意識到版本之間的差異，這已經(jīng)在 Django 中造成了一個權(quán)限越級漏洞（cve - 2022 -24583），無獨有偶，這在 WordPress 中也造成了一個加固繞過問題。

3.絕對路徑拼接

os.path.join(path, *paths) 函數(shù)用于將多個文件路徑連接成一個組合的路徑。第一個參數(shù)通常包含了基礎(chǔ)路徑，而之后的每個參數(shù)都被當做組件拼接到基礎(chǔ)路徑后。

然而，這個函數(shù)有一個少有人知的特性。如果拼接的某個路徑以 / 開頭，那么包括基礎(chǔ)路徑在內(nèi)的所有前綴路徑都將被刪除，該路徑將被視為絕對路徑。下面的示例揭示了開發(fā)者可能遇到的這個陷阱。

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 函數(shù)將用戶輸入的文件名構(gòu)造出目標路徑。在第 4 行中，檢查生成的路徑是否包含”.“，防止出現(xiàn)路徑遍歷漏洞。

但是，如果攻擊者傳入的文件名參數(shù)為”/a/b/c.txt“，那么第 3 行得到的變量 file_path 會是一個絕對路徑（/a/b/c.txt）。即 os.path.join 會忽略掉”var/lib“部分，攻擊者可以不使用“.”字符就讀取到任何文件。盡管 os.path.join 的文檔中描述了這種行為，但這還是導(dǎo)致了許多漏洞（Cuckoo Sandbox Evasion， CVE-2020-35736）。

4. 任意的臨時文件

tempfile.NamedTemporaryFile 函數(shù)用于創(chuàng)建具有特定名稱的臨時文件。但是，prefix（前綴）和 suffix（后綴）參數(shù)很容易受到路徑遍歷攻擊（Issue 35278）。如果攻擊者控制了這些參數(shù)之一，他就可以在文件系統(tǒng)中的任意位置創(chuàng)建出一個臨時文件。下面的示例揭示了開發(fā)者可能遇到的一個陷阱。

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 參數(shù)是“/../var/www/test”，則會創(chuàng)建出這樣的臨時文件：/var/www/test_zdllj17。粗看起來，這可能是無害的，但它會為攻擊者創(chuàng)造出挖掘更復(fù)雜的漏洞的基礎(chǔ)。

5.擴展的 Zip Slip

在 Web 應(yīng)用中，通常需要解壓上傳后的壓縮文件。在 Python 中，很多人都知道 TarFile.extractall 與 TarFile.extract 函數(shù)容易受到 Zip Slip 攻擊。攻擊者通過篡改壓縮包中的文件名，使其包含路徑遍歷（../）字符，從而發(fā)起攻擊。

這就是為什么壓縮文件應(yīng)該始終被視為不受信來源的原因。zipfile.extractall 與 zipfile.extract 函數(shù)可以對 zip 內(nèi)容進行清洗，從而防止這類路徑遍歷漏洞。

但是，這并不意味著在 ZipFile 庫中不會出現(xiàn)路徑遍歷漏洞。下面是一段解壓縮文件的代碼。

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 行代碼根據(jù)用戶上傳文件的臨時路徑，創(chuàng)建出一個 ZipFile 處理器。第 4 - 8 行代碼將所有以“.html”結(jié)尾的壓縮項提取出來。第 4 行中的 zf.namelist 函數(shù)會取到 zip 內(nèi)壓縮項的名稱。注意，只有 zipfile.extract 與 zipfile.extractall 函數(shù)會對壓縮項進行清洗，其它任何函數(shù)都不會。

在這種情況下，攻擊者可以創(chuàng)建一個文件名，例如“../../../var/www/html”，內(nèi)容隨意填。該惡意文件的內(nèi)容會在第 6 行被讀取，并在第 7-8 行寫入被攻擊者控制的路徑。因此，攻擊者可以在整個服務(wù)器上創(chuàng)建任意的 HTML 文件。

如上所述，壓縮包中的文件應(yīng)該被看作是不受信任的。如果你不使用 zipfile.extractall 或者 zipfile.extract，你就必須對 zip 內(nèi)文件的名稱進行“消毒”，例如使用 os.path.basename。否則，它可能導(dǎo)致嚴重的安全漏洞，就像在 NLTK Downloader （CVE-2019-14751）中發(fā)現(xiàn)的那樣。

6. 不完整的正則表達式匹配

正則表達式（regex）是大多數(shù) Web 程序不可或缺的一部分。我們經(jīng)常能看到它被自定義的 Web 應(yīng)用防火墻（WAF，Web Application Firewalls）用來作輸入驗證，例如檢測惡意字符串。在 Python 中，re.match 和 re.search 之間有著細微的區(qū)別，我們將在下面的代碼片段中演示。

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 注入。這是一個糟糕的寫法，因為你可以輕易地繞過這些黑名單，但我們已經(jīng)在線上的程序中見過它。在第 4 行中，函數(shù) re.match 使用前面定義好的模式，檢查第 3 行中的用戶輸入內(nèi)容是否包含這些惡意的值。

然而，與 re.search 函數(shù)不同的是，re.match 函數(shù)不匹配新行。例如，如果攻擊者提交了值 aaaaaa \n union select，這個輸入就匹配不上正則表達式。因此，檢查可以被繞過，失去保護作用。

總而言之，我們不建議使用正則表達式黑名單進行任何安全檢查。

7. Unicode 清洗器繞過

Unicode 支持用多種形式來表示字符，并將這些字符映射到碼點。在 Unicode 標準中，不同的 Unicode 字符有四種歸一化方案。程序可以使用這些歸一化方法，以獨立于人類語言的標準方式來存儲數(shù)據(jù)，例如用戶名。

然而，攻擊者可以利用這些歸一化，這已經(jīng)導(dǎo)致了 Python 的 urllib 出現(xiàn)漏洞（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 行中，用戶輸入的內(nèi)容被 Django 的 escape 函數(shù)處理了，以防止 XSS 漏洞。在第 7 行中，經(jīng)過清洗的輸入被 NFKC 算法歸一化，以便在第 8-9 行中通過 test.html 模板正確地渲染。

templates/test.html

html>
<html?lang="en">
<body>
{{?my_input?|?safe}}
body>
html>

在模板 test.html 中，第 4 行的變量 my_input 被標記為安全的，因為開發(fā)人員預(yù)期有特殊字符，并且認為該變量已經(jīng)被 escape 函數(shù)清洗了。通過標記關(guān)鍵字 safe, Django 不會再次對變量進行清洗。

但是，由于第 7 行（view.py）的歸一化，字符“%EF%B9%A4”會被轉(zhuǎn)換為“<”，“%EF%B9%A5”被轉(zhuǎn)換為“>”。這導(dǎo)致攻擊者可以注入任意的 HTML 標記，進而觸發(fā) XSS 漏洞。為了防止這個漏洞，就應(yīng)該在把用戶輸入做完歸一化之后，再進行清洗。

8. Unicode 編碼碰撞

前文說過，Unicode 字符會被映射成碼點。然而，有許多不同的人類語言，Unicode 試圖將它們統(tǒng)一起來。這就意味著不同的字符很有可能擁有相同的“l(fā)ayout”。例如，小寫的土耳其語 ?（沒有點）的字符是英語中大寫的 I。在拉丁字母中，字符 i 也是用大寫的 I 表示。在 Unicode 標準中，這兩個不同的字符都以大寫形式映射到同一個碼點。

這種行為是可以被利用的，實際上已經(jīng)在 Django 中導(dǎo)致了一個嚴重的漏洞（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.',?'[email protected]',?[email],?fail_silently=False)
????return?HttpResponse("Password?reset?email?send!")

第 6 行代碼獲取了用戶輸入的 email，第 7-9 行代碼檢查這個 email 值，查找是否存在具有該 email 的用戶。如果用戶存在，則第 10 行代碼依據(jù)第 6 行中輸入的 email 地址，給用戶發(fā)送郵件。需要指出的是，第 7-9 行中對郵件地址的檢查是不區(qū)分大小寫的，使用了 upper 函數(shù)。

至于攻擊，我們假設(shè)數(shù)據(jù)庫中存在一個郵箱地址為 [email protected] 的用戶。那么，攻擊者可以簡單地傳入 foo@m?x.com 作為第 6 行中的 email，其中 i 被替換為土耳其語 ?。第 7 行代碼將郵箱轉(zhuǎn)換成大寫，結(jié)果是 [email protected]。這意味著找到了一個用戶，因此會發(fā)送一封重置密碼的郵件。

然而，郵件被發(fā)送到第 6 行未轉(zhuǎn)換的郵件地址，也就是包含了土耳其語的 ?。換句話說，其他用戶的密碼被發(fā)送到了攻擊者控制的郵件地址。為了防止這個漏洞，可以將第 10 行替換成使用數(shù)據(jù)庫中的用戶郵箱。即使發(fā)生編碼沖突，攻擊者在這種情況下也得不到任何好處。

9. IP 地址歸一化

在 Python < 3.8 中，IP 地址會被 ipaddress 庫歸一化，因此前綴的零會被刪除。這種行為乍一看可能是無害的，但它已經(jīng)在 Django 中導(dǎo)致了一個高嚴重性的漏洞（CVE-2021-33571）。攻擊者可以利用歸一化繞過校驗程序，發(fā)起服務(wù)端請求偽造攻擊（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 發(fā)起實際的請求。

但是，攻擊者可以傳入 127.0.001 這樣的 IP 地址，在第 7 行的黑名單列表中找不到。然后，第 9 行代碼使用 ipaddress.IPv4Address 將 IP 歸一化為 127.0.0.1。因此，攻擊者就能夠繞過 SSRF 校驗器，并向本地網(wǎng)絡(luò)地址發(fā)送請求。

10. URL 查詢參數(shù)解析

在 Python < 3.7 中，urllib.parse.parse_qsl 函數(shù)允許使用“;”和“&”字符作為 URL 的查詢變量的分隔符。有趣的是“;”字符不能被其它語言識別為分隔符。

在下面的例子中，我們將展示為什么這種行為會導(dǎo)致漏洞。假設(shè)我們正在運行一個基礎(chǔ)設(shè)施，其中前端是一個 PHP 程序，后端則是一個 Python 程序。

攻擊者向 PHP 前端發(fā)送以下的 GET 請求:

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

PHP 前端只識別出一個查詢參數(shù)“a”，其內(nèi)容為“1;b=2”。PHP 不把“;”字符作為查詢參數(shù)的分隔符?，F(xiàn)在，前端會將攻擊者的請求直接轉(zhuǎn)發(fā)給內(nèi)部的 Python 程序:

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

如果使用了 urllib.parse.parse_qsl，Python 程序會處理成兩個查詢參數(shù)，即“a=1”和“b=2”。這種查詢參數(shù)解析的差異可能會導(dǎo)致致命的安全漏洞，比如 Django 中的 Web 緩存投毒漏洞（CVE-2021-23336）。

總結(jié)

在這篇博文中，我們介紹了 10 個 Python 安全陷阱，我們認為開發(fā)者不太了解它們。每個細微的陷阱都很容易被忽視，并在過去導(dǎo)致了線上程序的安全漏洞。

覺得不錯，請點個在看