Python中的十個(gè)安全陷阱(一)

Python 開(kāi)發(fā)者們?cè)谑褂脴?biāo)準(zhǔn)庫(kù)和通用框架時(shí)，都以為自己的程序具有可靠的安全性。然而，在 Python 中，就像在任何其它編程語(yǔ)言中一樣，有一些特性可能會(huì)被開(kāi)發(fā)者們誤解或誤用。通常而言，只有極少的微妙之處或細(xì)節(jié)會(huì)使開(kāi)發(fā)者們疏忽大意，從而在代碼中引入嚴(yán)重的安全漏洞。

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

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

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

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

defsuperuser_action(request,user):
assertuser.is_super_user
#executeactionassuperuser

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

2. MakeDirs 權(quán)限

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

definit_directories(request):
os.makedirs("A/B/C",mode=0o700)
returnHttpResponse("Done!")

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

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

3.絕對(duì)路徑拼接

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

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

defread_file(request):
filename=request.POST['filename']
file_path=os.path.join("var","lib",filename)
iffile_path.find(".")!=-1:
    returnHttpResponse("Failed!")
withopen(file_path)asf:
    returnHttpResponse(f.read(),content_type='text/plain')

在第 3 行中，我們使用 os.path.join 函數(shù)將用戶輸入的文件名構(gòu)造出目標(biāo)路徑。在第 4 行中，檢查生成的路徑是否包含”.“，防止出現(xiàn)路徑遍歷漏洞。

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

4. 任意的臨時(shí)文件

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

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 被當(dāng)作臨時(shí)文件的前綴。如果攻擊者傳入的 id 參數(shù)是“/../var/www/test”，則會(huì)創(chuàng)建出這樣的臨時(shí)文件：/var/www/test_zdllj17。粗看起來(lái)，這可能是無(wú)害的，但它會(huì)為攻擊者創(chuàng)造出挖掘更復(fù)雜的漏洞的基礎(chǔ)。

5.擴(kuò)展的 Zip Slip

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

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

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

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

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