1. 從一次接口被拖庫(kù)說(shuō)起Python 后端為什么必須防 SQL 注入SQL 注入這件事很多同學(xué)覺得是老生常談直到自己寫的接口被人用 OR 11把整張用戶表?yè)谱卟藕蠡?。它的本質(zhì)其實(shí)很樸素你把用戶輸入當(dāng)成 SQL 語(yǔ)句的一部分去拼接數(shù)據(jù)庫(kù)就分不清哪段是代碼、哪段是數(shù)據(jù)。比如登錄接口里寫fSELECT * FROM user WHERE name{name}攻擊者傳個(gè)admin --后面的密碼校驗(yàn)直接被注釋掉登錄邏輯瞬間失效。我見過(guò)最典型的翻車場(chǎng)景是后端接了統(tǒng)一模型網(wǎng)關(guān)之后把對(duì)話內(nèi)容、用戶 ID、會(huì)話標(biāo)簽一股腦塞進(jìn)數(shù)據(jù)庫(kù)圖省事用字符串拼接寫 INSERT。平時(shí)測(cè)試沒問(wèn)題一旦有人構(gòu)造惡意 payload輕則數(shù)據(jù)泄露重則整庫(kù)被刪。所以防注入不是加分項(xiàng)而是 Python 后端接入任何外部通道包括 TaoToken 這類統(tǒng)一 Key 網(wǎng)關(guān)時(shí)的底線要求。這篇聚焦三件事參數(shù)化查詢、ORM 綁定變量、輸入校驗(yàn)三層防線疊起來(lái)用。同時(shí)我會(huì)把數(shù)據(jù)庫(kù)連接配置、可復(fù)制的代碼片段、以及怎么自己造注入用例驗(yàn)證防護(hù)是否生效全部走一遍。適合正在寫 Flask/FastAPI/Django 接口、又想把安全加固落到實(shí)處的開發(fā)者。核心檢索詞就一句話Python 防止 SQL 注入的有效方法下面所有內(nèi)容都圍繞它展開不講空理論只講能直接抄進(jìn)項(xiàng)目的做法。先說(shuō)清楚一個(gè)前提參數(shù)化查詢不是把變量塞進(jìn) SQL 字符串再轉(zhuǎn)義而是把 SQL 模板和參數(shù)分兩次發(fā)給數(shù)據(jù)庫(kù)讓數(shù)據(jù)庫(kù)自己完成綁定。這是它和手動(dòng)轉(zhuǎn)義的本質(zhì)區(qū)別也是為什么它幾乎能擋住所有經(jīng)典注入。理解了這一點(diǎn)后面的 pymysql、SQLAlchemy、Django ORM 寫法就都是同一套思想的變體。2. TaoToken 統(tǒng)一 Key 前置把模型通道和數(shù)據(jù)庫(kù)通道分開管在講數(shù)據(jù)庫(kù)之前先花點(diǎn)篇幅說(shuō)清楚 TaoToken 在這套架構(gòu)里的位置避免概念混淆。TaoToken 是一個(gè)統(tǒng)一 API 通道官網(wǎng)入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。它的作用是讓你用一個(gè) Key調(diào)用多家模型省去到處申請(qǐng)、到處配環(huán)境變量的麻煩。關(guān)鍵點(diǎn)來(lái)了TaoToken 管的是模型調(diào)用這條通道數(shù)據(jù)庫(kù)連接是另一條獨(dú)立通道。很多新手會(huì)把兩者混在一起覺得我接了統(tǒng)一 Key 就安全了這是誤解。模型通道負(fù)責(zé)把 prompt 發(fā)給大模型拿回復(fù)數(shù)據(jù)庫(kù)通道負(fù)責(zé)把你的業(yè)務(wù)數(shù)據(jù)落庫(kù)。防 SQL 注入要防的是數(shù)據(jù)庫(kù)通道而 TaoToken 的 Key 要保護(hù)的是模型通道不被盜刷。兩條線各管各的但都遵循同一個(gè)原則不要把外部輸入直接拼進(jìn)敏感操作。那 TaoToken 和防注入有什么實(shí)際關(guān)聯(lián)關(guān)聯(lián)在于當(dāng)你用統(tǒng)一 Key 做 AI 應(yīng)用時(shí)用戶輸入比如對(duì)話內(nèi)容、生成的 SQL 建議、Agent 產(chǎn)出的查詢語(yǔ)句經(jīng)常會(huì)流轉(zhuǎn)到數(shù)據(jù)庫(kù)層。如果這些內(nèi)容被直接拼接執(zhí)行注入風(fēng)險(xiǎn)就來(lái)了。所以正確姿勢(shì)是——模型通道用 TaoToken 統(tǒng)一管理數(shù)據(jù)庫(kù)通道用參數(shù)化 ORM 嚴(yán)格隔離兩者在代碼里涇渭分明。配置上建議把 TaoToken 的 Key 和數(shù)據(jù)庫(kù)密碼都放進(jìn)環(huán)境變量別硬編碼。模型調(diào)用走h(yuǎn)ttps://taotoken.net/api數(shù)據(jù)庫(kù)走本地或云上的 MySQL/PostgreSQL。下面給一個(gè)環(huán)境變量模板你可以直接抄# .env 文件別提交到 git TAOTOKEN_API_KEYsk-你的統(tǒng)一Key TAOTOKEN_BASE_URLhttps://taotoken.net/api DB_HOST127.0.0.1 DB_USERapp_user DB_PASSWORD你的數(shù)據(jù)庫(kù)密碼 DB_NAMEapp_db拿到 Key 的入口在控制臺(tái)的 API Keys 頁(yè)面模型對(duì)話調(diào)試可以用模型對(duì)話頁(yè)長(zhǎng)期跑編碼或 Agent 任務(wù)建議看 Coding Plan。這些都屬于模型通道的準(zhǔn)備工作和后面的數(shù)據(jù)庫(kù)加固互不干擾。記住一句話統(tǒng)一 Key 讓模型調(diào)用省心參數(shù)化查詢讓數(shù)據(jù)庫(kù)調(diào)用安全兩者缺一不可。3. 可復(fù)制配置pymysql 參數(shù)化查詢與 SQLAlchemy ORM 綁定變量這一節(jié)是全文的技術(shù)核心直接上可復(fù)制的代碼。先看最基礎(chǔ)的 pymysql 參數(shù)化寫法這是理解一切 ORM 綁定的地基。3.1 pymysql 參數(shù)化占位符 元組傳參import os import pymysql # 從環(huán)境變量讀取避免硬編碼 conn pymysql.connect( hostos.getenv(DB_HOST, 127.0.0.1), useros.getenv(DB_USER, app_user), passwordos.getenv(DB_PASSWORD, ), databaseos.getenv(DB_NAME, app_db), charsetutf8mb4, cursorclasspymysql.cursors.DictCursor, ) try: with conn.cursor() as cur: # 正確SQL 模板用 %s 占位參數(shù)單獨(dú)傳 sql INSERT INTO user(name, password) VALUES(%s, %s) cur.execute(sql, (test, 888888)) conn.commit() print(insert ok, rowid, cur.lastrowid) finally: conn.close()注意幾個(gè)細(xì)節(jié)。第一%s是 pymysql 的占位符不要加引號(hào)寫成%s就退化成字符串拼接了。第二參數(shù)用元組或列表傳pymysql 會(huì)自動(dòng)做類型綁定和轉(zhuǎn)義。第三commit()必須主動(dòng)調(diào)用否則增刪改不生效——這是新手最常踩的坑和注入無(wú)關(guān)但同樣致命。再看查詢場(chǎng)景同樣用占位符with conn.cursor() as cur: sql SELECT id, name FROM user WHERE name %s AND status %s cur.execute(sql, (alice, 1)) rows cur.fetchall() for r in rows: print(r[id], r[name])如果這里你寫成f... WHERE name {name}攻擊者傳alice OR 11整表就被查出來(lái)了。參數(shù)化之后數(shù)據(jù)庫(kù)把a(bǔ)lice OR 11當(dāng)成一個(gè)普通字符串值去匹配匹配不到就返回空注入失效。3.2 SQLAlchemy ORM綁定變量藏在 filter 里ORM 的價(jià)值在于它從 API 層面就不給你拼接字符串的機(jī)會(huì)?？聪旅孢@段from sqlalchemy import create_engine, Column, Integer, String from sqlalchemy.orm import declarative_base, sessionmaker engine create_engine( mysqlpymysql://app_user:password127.0.0.1/app_db?charsetutf8mb4, pool_pre_pingTrue, ) Base declarative_base() Session sessionmaker(bindengine) class User(Base): __tablename__ user id Column(Integer, primary_keyTrue) name Column(String(64), nullableFalse) password Column(String(128), nullableFalse) session Session() # 正確filter 傳參SQLAlchemy 內(nèi)部用綁定變量 user session.query(User).filter(User.name alice).first() print(user.id if user else not found)User.name alice看起來(lái)像 Python 表達(dá)式實(shí)際被 SQLAlchemy 編譯成WHERE name %(name_1)s參數(shù)單獨(dú)綁定。哪怕你傳alice OR 11它也只是個(gè)字符串值。3.3 一個(gè)容易忽略的坑text() 里別拼字符串SQLAlchemy 的text()允許寫原生 SQL但必須用綁定參數(shù)from sqlalchemy import text # 正確 session.execute( text(SELECT * FROM user WHERE name :name), {name: alice}, ) # 錯(cuò)誤示范別這么寫 # session.execute(text(fSELECT * FROM user WHERE name {name}))冒號(hào):name是綁定參數(shù)語(yǔ)法和 pymysql 的%s一個(gè)道理。很多人用 ORM 用得好好的一到復(fù)雜查詢就退回text()拼字符串防線瞬間破功。3.4 輸入校驗(yàn)第三層防線參數(shù)化能擋住絕大多數(shù)注入但輸入校驗(yàn)仍然值得做因?yàn)樗軗踝I(yè)務(wù)層面的異常比如超長(zhǎng)字符串、非法字符、類型不符。用 Pydantic 做一層from pydantic import BaseModel, Field, field_validator import re class UserCreate(BaseModel): name: str Field(min_length1, max_length32) password: str Field(min_length6, max_length64) field_validator(name) classmethod def name_must_be_safe(cls, v: str) - str: if not re.fullmatch(r[A-Za-z0-9_], v): raise ValueError(name 只允許字母數(shù)字下劃線) return v校驗(yàn)放在參數(shù)化之前形成校驗(yàn) → 綁定 → 執(zhí)行的流水線。注意校驗(yàn)不能替代參數(shù)化因?yàn)樾ｒ?yàn)規(guī)則總有疏漏而參數(shù)化是數(shù)據(jù)庫(kù)層面的硬隔離。4. 驗(yàn)證請(qǐng)求與成功結(jié)果自己造注入用例看防護(hù)是否生效寫完代碼不驗(yàn)證等于沒寫。這一節(jié)教你造幾個(gè)經(jīng)典注入 payload對(duì)比拼接寫法和參數(shù)化寫法的結(jié)果差異親眼看到防護(hù)生效。4.1 準(zhǔn)備測(cè)試表和測(cè)試數(shù)據(jù)CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, password VARCHAR(128) NOT NULL, status TINYINT DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO user(name, password, status) VALUES (alice, hashed_pwd_1, 1), (bob, hashed_pwd_2, 1), (carol, hashed_pwd_3, 0);4.2 對(duì)比實(shí)驗(yàn)拼接 vs 參數(shù)化import pymysql conn pymysql.connect( host127.0.0.1, userapp_user, passwordpassword, databaseapp_db, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor, ) payload alice OR 11 # 危險(xiǎn)寫法字符串拼接 with conn.cursor() as cur: bad_sql fSELECT id, name FROM user WHERE name {payload} print(拼接 SQL:, bad_sql) cur.execute(bad_sql) print(拼接結(jié)果條數(shù):, len(cur.fetchall())) # 會(huì)返回全部 3 條 # 安全寫法參數(shù)化 with conn.cursor() as cur: good_sql SELECT id, name FROM user WHERE name %s cur.execute(good_sql, (payload,)) print(參數(shù)化結(jié)果條數(shù):, len(cur.fetchall())) # 返回 0 條 conn.close()實(shí)測(cè)下來(lái)拼接寫法會(huì)返回全部 3 條記錄因?yàn)镺R 11恒真參數(shù)化寫法返回 0 條因?yàn)閿?shù)據(jù)庫(kù)把整個(gè) payload 當(dāng)成一個(gè)名字去匹配匹配不到。這就是最直觀的驗(yàn)證。4.3 用 FastAPI 接口做端到端驗(yàn)證把上面的邏輯包成一個(gè)接口用 curl 打請(qǐng)求from fastapi import FastAPI, HTTPException from pydantic import BaseModel import pymysql, os app FastAPI() class LoginReq(BaseModel): name: str password: str app.post(/login) def login(req: LoginReq): conn pymysql.connect( hostos.getenv(DB_HOST), useros.getenv(DB_USER), passwordos.getenv(DB_PASSWORD), databaseos.getenv(DB_NAME), charsetutf8mb4, cursorclasspymysql.cursors.DictCursor, ) try: with conn.cursor() as cur: cur.execute( SELECT id, name FROM user WHERE name %s AND password %s, (req.name, req.password), ) row cur.fetchone() if not row: raise HTTPException(status_code401, detail賬號(hào)或密碼錯(cuò)誤) return {user_id: row[id], name: row[name]} finally: conn.close()啟動(dòng)后用 curl 驗(yàn)證# 正常請(qǐng)求 curl -X POST http://127.0.0.1:8000/login \ -H Content-Type: application/json \ -d {name:alice,password:hashed_pwd_1} # 返回 {user_id:1,name:alice} # 注入請(qǐng)求 curl -X POST http://127.0.0.1:8000/login \ -H Content-Type: application/json \ -d {name:alice OR 11,password:x} # 返回 401注入失敗看到 401 就說(shuō)明防線生效了。如果這里返回了用戶信息說(shuō)明你的代碼某處還在拼接趕緊回去查。4.4 結(jié)合 TaoToken 通道的驗(yàn)證思路如果你的接口里還調(diào)用了模型比如讓模型生成查詢建議記得把模型返回的內(nèi)容也當(dāng)不可信輸入處理。驗(yàn)證方法是讓模型返回一段帶 OR 11的文本看它進(jìn)入數(shù)據(jù)庫(kù)層時(shí)是否被參數(shù)化攔住。模型通道走h(yuǎn)ttps://taotoken.net/api數(shù)據(jù)庫(kù)通道走參數(shù)化兩條線都驗(yàn)證一遍才算完整。5. 本篇常見錯(cuò)排查401、local proxy failed、reading choices 與 OAuth 報(bào)錯(cuò)這一節(jié)把實(shí)際開發(fā)中最容易撞上的報(bào)錯(cuò)列出來(lái)對(duì)照排查。注意區(qū)分有些是模型通道的錯(cuò)有些是數(shù)據(jù)庫(kù)通道的錯(cuò)別混為一談。5.1 數(shù)據(jù)庫(kù)側(cè)401 與連接失敗如果你看到pymysql.err.OperationalError: (1045, Access denied for user ...)這是數(shù)據(jù)庫(kù)賬號(hào)密碼錯(cuò)不是注入問(wèn)題。檢查.env里的DB_USER、DB_PASSWORD是否和 MySQL 里創(chuàng)建的一致。另一種(2003, Cant connect to MySQL server)是網(wǎng)絡(luò)或端口不通確認(rèn) MySQL 在跑、端口 3306 開放。還有一種隱蔽的參數(shù)化寫對(duì)了但commit()忘了調(diào)導(dǎo)致 INSERT 看似成功實(shí)際沒落庫(kù)。表現(xiàn)是接口返回 200數(shù)據(jù)庫(kù)里查不到數(shù)據(jù)。排查方法是在cur.execute后打印cur.rowcount再確認(rèn)conn.commit()執(zhí)行了。5.2 模型通道側(cè)local proxy failed 與 reading choices這兩個(gè)報(bào)錯(cuò)通常出現(xiàn)在調(diào)用模型 API 時(shí)。local proxy failed一般是本地網(wǎng)絡(luò)配置或環(huán)境變量指向了錯(cuò)誤的地址檢查你的TAOTOKEN_BASE_URL是否寫成https://taotoken.net/api別多寫斜杠或少寫路徑。reading choices報(bào)錯(cuò)多半是響應(yīng)體解析失敗常見原因是 Key 無(wú)效或額度不足去控制臺(tái)確認(rèn) Key 狀態(tài)。這里要強(qiáng)調(diào)模型通道的報(bào)錯(cuò)和 SQL 注入無(wú)關(guān)別看到報(bào)錯(cuò)就懷疑參數(shù)化寫錯(cuò)了。分清楚報(bào)錯(cuò)來(lái)源能省大量排查時(shí)間。5.3 OAuth 報(bào)錯(cuò)與 Codex auth.json 三件套如果你在用 Codex 類工具可能會(huì)遇到 OAuth 相關(guān)報(bào)錯(cuò)。這類工具通常需要三件套配置齊全Base URL Key Model ID。缺任何一個(gè)都會(huì)報(bào)鑒權(quán)失敗。以auth.json為例結(jié)構(gòu)大致如下{ base_url: https://taotoken.net/api, api_key: sk-你的統(tǒng)一Key, model: claude-sonnet-4-5 }注意base_url用 API 基址不要帶 UTM 參數(shù)api_key從控制臺(tái) API Keys 頁(yè)獲取model填你要用的模型 ID。三件套對(duì)齊后OAuth 報(bào)錯(cuò)基本能消。同理如果你用 Cline MCP 或 CC Switch也是這三件套的邏輯配置項(xiàng)名稱可能不同但本質(zhì)一樣。5.4 參數(shù)化寫法的三個(gè)高頻錯(cuò)誤第一占位符加引號(hào)VALUES(%s)是錯(cuò)的應(yīng)該是VALUES(%s)。第二用%格式化字符串sql % (name,)是拼接不是參數(shù)化。第三execute只傳 SQL 不傳參數(shù)cur.execute(... WHERE name %s)會(huì)報(bào)參數(shù)數(shù)量不匹配。這三個(gè)錯(cuò)誤我都踩過(guò)改起來(lái)很快但不知道就會(huì)卡很久。排查順序建議先看報(bào)錯(cuò)類型數(shù)據(jù)庫(kù)錯(cuò)還是模型錯(cuò)→ 再看 SQL 是否用了占位符 → 最后看參數(shù)是否單獨(dú)傳。按這個(gè)順序走90% 的問(wèn)題能定位。6. 把防線固化進(jìn)項(xiàng)目從今天起這樣寫數(shù)據(jù)庫(kù)代碼聊了這么多最后落到怎么長(zhǎng)期堅(jiān)持上。防注入不是一次性任務(wù)而是編碼習(xí)慣。給你幾條能直接落地的規(guī)矩。第一條項(xiàng)目里禁止出現(xiàn) f-string 拼 SQL。可以在 CI 里加一條 grep 檢查搜execute(f或execute(.*%s.* %這類模式命中就報(bào)錯(cuò)。團(tuán)隊(duì)里定這條規(guī)矩比事后補(bǔ)救有效得多。第二條優(yōu)先用 ORM復(fù)雜查詢用 text() 綁定參數(shù)。SQLAlchemy 的filter、filter_by天然安全實(shí)在要寫原生 SQL 就用:param綁定。別為了性能退回字符串拼接那點(diǎn)性能差異遠(yuǎn)不如一次數(shù)據(jù)泄露的代價(jià)大。第三條輸入校驗(yàn)和參數(shù)化分層。Pydantic 做業(yè)務(wù)校驗(yàn)參數(shù)化做安全隔離兩層各司其職。校驗(yàn)規(guī)則可以隨業(yè)務(wù)調(diào)整參數(shù)化寫法永遠(yuǎn)不變。第四條模型通道和數(shù)據(jù)庫(kù)通道分開配。TaoToken 的 Key 管模型調(diào)用數(shù)據(jù)庫(kù)密碼管數(shù)據(jù)落庫(kù)環(huán)境變量分開命名別混用。模型返回的內(nèi)容進(jìn)數(shù)據(jù)庫(kù)前一律當(dāng)不可信輸入走參數(shù)化。如果你還沒配好模型通道可以從 API Keys 頁(yè)拿 Key接入文檔里有各語(yǔ)言的示例想先試試模型效果就去模型對(duì)話頁(yè)長(zhǎng)期跑編碼或 Agent 任務(wù)Coding Plan 更劃算。數(shù)據(jù)庫(kù)這邊把本文第 3 節(jié)的代碼抄進(jìn)項(xiàng)目第 4 節(jié)的驗(yàn)證用例跑一遍基本就穩(wěn)了。最后說(shuō)個(gè)真實(shí)體會(huì)安全加固最怕我覺得沒問(wèn)題。我見過(guò)太多項(xiàng)目參數(shù)化寫了一半某個(gè)復(fù)雜查詢圖省事拼了字符串結(jié)果就那一處被攻破。所以別偷懶每一處execute都過(guò)一遍眼睛確認(rèn)參數(shù)是單獨(dú)傳的。這件事沒有捷徑但養(yǎng)成習(xí)慣之后寫代碼時(shí)手會(huì)自動(dòng)避開拼接那時(shí)候你就真的把防線固化下來(lái)了。