系列第 2 篇。上篇講業(yè)務(wù)、版本、架構(gòu)本篇講安全與隱式耦合下篇講協(xié)作與一致性。開場最危險(xiǎn)的不是“報(bào)錯”讓 Trae 寫一個文件上傳接口Prompt 是寫一個 FastAPI 文件上傳接口把文件保存到 uploads 目錄。它給出fromfastapiimportFastAPI,UploadFileimportos appFastAPI()app.post(/upload)asyncdefupload(file:UploadFile):contentawaitfile.read()save_pathos.path.join(./uploads,file.filename)withopen(save_path,wb)asf:f.write(content)return{ok:True,path:save_path}跑得通。上傳個小圖片返回{ok: true}一切正常。這就是最危險(xiǎn)的地方——它“能用”所以你會直接上生產(chǎn)。下面三個漏洞全部可復(fù)現(xiàn)。漏洞一路徑穿越file.filename是客戶端可控的。構(gòu)造一個請求curl-XPOST http://localhost:8000/upload\-Ffiletest.txt;filename../../etc/cron.d/evilos.path.join(./uploads, ../../etc/cron.d/evil)會拼成os.path.join(./uploads,../../etc/cron.d/evil)uploads/../../etc/cron.d/evilos.path.join不會清理..實(shí)際寫到/etc/cron.d/evil。配合定時(shí)任務(wù)直接 RCE。漏洞二類型偽造curl-XPOST http://localhost:8000/upload\-Ffileshell.php;filenameshell.php上傳一個.php如果 uploads 目錄被 Web 服務(wù)器當(dāng)靜態(tài)目錄暴露就是 webshell。Trae 的原始代碼完全不看文件類型。漏洞三內(nèi)存 DoSddif/dev/urandomofbig.binbs1Mcount10240curl-XPOST http://localhost:8000/upload-Ffilebig.binawait file.read()把整個文件讀進(jìn)內(nèi)存。10GB 文件直接打爆進(jìn)程服務(wù)掛掉——一個極低成本的 DoS。修復(fù)版可運(yùn)行fromfastapiimportFastAPI,UploadFile,HTTPExceptionfrompathlibimportPurePosixPathimportos,uuid appFastAPI()UPLOAD_DIR./uploadsMAX_SIZE10*1024*1024# 10MBALLOWED_EXT{.png,.jpg,.jpeg,.gif,.pdf}os.makedirs(UPLOAD_DIR,exist_okTrue)app.post(/upload)asyncdefupload(file:UploadFile):# 1. 類型校驗(yàn)擴(kuò)展名白名單extPurePosixPath(file.filenameor).suffix.lower()ifextnotinALLOWED_EXT:raiseHTTPException(400,不支持的文件類型)# 2. 重命名徹底杜絕路徑穿越safe_namef{uuid.uuid4().hex}{ext}save_pathos.path.join(UPLOAD_DIR,safe_name)# 3. 分塊讀取超限中斷size0withopen(save_path,wb)asf:whilechunk:awaitfile.read(1024*1024):sizelen(chunk)ifsizeMAX_SIZE:f.close()os.remove(save_path)raiseHTTPException(413,文件過大)f.write(chunk)return{ok:True,path:save_path}修復(fù)點(diǎn)對照漏洞修復(fù)手段路徑穿越不用原始文件名uuid重命名 擴(kuò)展名單獨(dú)校驗(yàn)類型偽造擴(kuò)展名白名單后續(xù)可加 MIME / 文件頭校驗(yàn)內(nèi)存 DoS分塊讀取超限中斷并刪除殘留文件安全追問必須由你發(fā)起Trae 默認(rèn)只回答“怎么實(shí)現(xiàn)”不回答“怎么防人”。所以正確的用法是讓它先寫然后你明確追問——這段代碼存在哪些安全問題請逐一列出 1. 輸入校驗(yàn) 2. 路徑/權(quán)限 3. 資源耗盡 4. 注入 每一類都給出攻擊方式與修復(fù)代碼。它會補(bǔ)得不錯。但觸發(fā)這個追問的必須是你不能是它。安全的責(zé)任AI 不會主動接。延伸坑跨文件隱式耦合安全之外還有一類更隱蔽的漏洞# 直接調(diào)用Trae 能看到utils.format_price(x)# 通過字符串反射調(diào)用Trae 看不到handlergetattr(utils,format_price)handler(x)讓 Trae 改format_price的簽名它會改掉可見的直接調(diào)用卻漏掉getattr這種字符串引用。上線后反射調(diào)用報(bào)錯。根因Trae 按靜態(tài)調(diào)用關(guān)系判斷影響面對字符串、反射、事件回調(diào)注冊、配置里的類名識別不可靠。改進(jìn)方法改公共 API 前自己 grep 全倉庫grep-rnformat_price--include*.py.再確認(rèn)有沒有字符串、反射、配置用法。把 AI 的“影響面分析”當(dāng)線索不當(dāng)結(jié)論。小結(jié)Trae 寫的上傳接口邏輯“無懈可擊”安全“千瘡百孔”安全追問必須由你發(fā)起改公共 API全倉 grep 不能省—上篇業(yè)務(wù)、版本、架構(gòu)見系列上篇。下篇為什么 AI 寫的 review 沒人信以及怎么讓 AI 長期保持一致。收藏 關(guān)注系列不丟。